220 11804 article Path: news.gmane.org!not-for-mail From: tomaszkam@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Thu, 10 Jul 2014 04:42:48 -0700 (PDT) Lines: 275 Approved: news@gmane.org Message-ID: References: <4DA018C3-2327-4F55-B7F8-7988EC7B789A@gmail.com> <1a858a77-310b-4591-aaf5-960c40d9f5fc@isocpp.org> <66AF41C1-CB37-4311-98EA-D47DBC6068DC@gmail.com> <66c38b61-7a95-4ace-b34f-2346bb334fb9@isocpp.org> <6F4B3C72-9962-48DC-8527-0C89EA1B9710@gmail.com> <072cf8b4-4c74-438e-9999-0aab13bf3182@isocpp.org> <74CEDDAC-1B1B-4F06-9E58-2F025921FE55@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7_7260802.1404992569033" X-Trace: ger.gmane.org 1404992582 28583 80.91.229.3 (10 Jul 2014 11:43:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 11:43:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBOPY7GOQKGQEQ53VEUA@isocpp.org Thu Jul 10 13:42:53 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5CkW-0004eX-7M for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 13:42:52 +0200 Original-Received: by mail-yk0-f199.google.com with SMTP id 200sf20471455ykr.2 for ; Thu, 10 Jul 2014 04:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=F7idTT1urrX020O684DfUMFhGXewKlK0SktMWZELmUQ=; b=vZ1XIdS74+PN+FiTldyJGqcqcs4ge6XniTU/V2L/1ca9pe5Gs06q8hVybYhHHeQsOI 2Jfjeq2JcIkRrtM1F2MGRWQGTodqP7Lo1HdcwgtkUplkC5zwR7b4G1SnFeGZmIGzD2qi 37ffYn2+TjIaE/+MTJHZtk9E7kEVPqRJnKOQVxOSKa/xapD674F0LsshW/OfJEls3l5e S63gsKfSinFKXqVSVFHRh+yDsogKrKt5akp0gWjs2hU5BkRqoA0UjmozoCwcWxzzjWIF 2qpnCm+zADzsi9MfnNReqO2BBTKq0CywmAK1GAjoOMUPq1OUS1nlBblzfTrmdvtPQz2/ MloA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=F7idTT1urrX020O684DfUMFhGXewKlK0SktMWZELmUQ=; b=IJqxnuuzytlnjD1nCeOcVYe7p7u7Ro/Ne7VO2N6qEkZffFDsgLYnUXY+SjVu1EBz4G B6EcyJlxZ1Q0lzHg4dqzRh9dgaZOtEWd5WjGGytXyL7ixdb400OtsDdGUXWs+CIUL3W2 N9rplJtr5QoEc/fQpkTsF0QkAc2P4SSoMhFA34BT3tTIYTQ2+Vgs4CeA6aZLmMyxQ903 7W+LNEF8lYjsL3iEFcO1BQ0E93xA0k1b3nc/ICgekBXb6rgEPPYdWk5TREH7p1XFC0Iv L/Xxxk8ez3Wxo9YRNHoA6Chg8PgEyBi7MIKbBf04qJ6bfrRlofAIr+4qNSDchTzkBjh5 IkFA== X-Gm-Message-State: ALoCoQmyHJYYhvmWbM5xRsmpX+5djgod9FbB0qhOGFOzn6IET7Ei7rqdwVrD3txCyWjVNrKAIPUp X-Received: by 10.58.93.162 with SMTP id cv2mr20521619veb.11.1404992570912; Thu, 10 Jul 2014 04:42:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.135.228 with SMTP id pv4ls28865obb.57.gmail; Thu, 10 Jul 2014 04:42:49 -0700 (PDT) X-Received: by 10.182.153.200 with SMTP id vi8mr59670obb.23.1404992569628; Thu, 10 Jul 2014 04:42:49 -0700 (PDT) In-Reply-To: X-Original-Sender: tomaszkam@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11804 Archived-At: ------=_Part_7_7260802.1404992569033 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu czwartek, 10 lipca 2014 13:12:57 UTC+2 u=C5=BCytkownik David Krauss= =20 napisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9310, at 6:24 PM, toma...@gmail.com wrote: > > W dniu czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Kraus= s=20 > napisa=C5=82: > >> >> forward_component trusts the user that the function argument is owned by= =20 >> an object of the template argument type. It handles vector::front and=20 >> unique_ptr::operator* with equal aplomb, and we don=E2=80=99t even have = to add=20 >> rvalue reference overloads to anything. (Although doing so may still be = a=20 >> good idea.) >> > > And this wis actually break every use of forward with non-owning=20 > semenatics (shared_ptr). Please remember that forward function was=20 > designed to perfectly forward value of any type in generic context withou= t=20 > introspection, but introducing separate forward_compoent kills the idea,= =20 > because we me differentiate between shared_ptr and unique_ptr. > > > Shared ownership fails to satisfy the stated requirement. No suitable=20 > forwarding semantics exist for shared_ptr, and the value category of the= =20 > pointer carries no information about the shared object. You just have to= =20 > assume that it=E2=80=99s not-owned, unless shared_ptr::unique returns tru= e, in=20 > which case forward_component works. > > No =E2=80=9Cgeneric context=E2=80=9D can handle different pointer types. = unique_ptr always=20 > owns its referent but T* never does. You seem to suggest I=E2=80=99ve =E2= =80=9Ckilled=E2=80=9D an=20 > alternative that never existed in the first place. > > Yes, it=E2=80=99s impossible to call make_shared, destroy the sharing poo= l, and=20 > still safely bind the erstwhile-shared value to a universal reference all= =20 > in one declaration. This sounds pretty contrived, though. Use of=20 > shared_ptr at all implies that the object existed before the line in=20 > question, and if you want to continue using a subobject after the line,= =20 > don=E2=80=99t move() the shared_pointer. > > Acutally defininig the rvalue reference overload for member getters=20 > returning rvalue reference (T&& meber() &&) is the way a type can=20 > signialize to forward that it owning this member. That means we could hav= e: > T&& operator*() &&; //for unique_ptr, bot not for shared_ptr > Or for vector: > T&& front() &&; > T&& back() &&; > Or even for begin/end members that will allows us to have better=20 > traversable constructor:=20 > https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-propo= sals/sOw68ogy6BM > > > Yes, I mentioned that hypothetically to Ville. Considering the=20 > implementation effort and added compilation complexity of that strategy,= =20 > you might as well use forward_component() with no adjustment to the=20 > container (or plain-old move() when not forwarding). > > Now const&& should have the same semenantics as the const& so the additio= n=20 > overload is not necessary. > > > Strange, I didn=E2=80=99t realize that const& is preferred over && for a = const=20 > rvalue implicit argument, but so it is. GCC even fails to prefer const&&= =20 > over const&. > My point is that with the montions that will begin with having T&&=20 value()&& method we can start a montion to make following code: template void f(Nullable&& n) { foo(*std::forward(n)); }; To pass an T&& if Nullable&& is optional&& and pass reference=20 (optionally) const for shared_ptr, unique_ptr, T*. If we add then T&&= =20 operator*() &&; for unique_ptr to represent ownership. Then we will have at least one case handled in the forward correclty.=20 In think that the class should definie if it have ownership over member *by= =20 definining r-value overload) and this should not be handled on the invoker= =20 side, by requring using forward_component or move. This also brakes=20 encapsulation.=20 If we have methods (T&& operator*() && for unique_ptr and optional,= =20 but not for shared_ptr and of course T&&) metonied above the expression= =20 *std::forward(n) will do the right thing and not forward_compoent= =20 being necessary. If we go with the T value()&& in the current sementic of= =20 value() method (giving acces to stored value, not returning value) we will= =20 close this way. I think that library should be make easier to use at cost of it complexlity= =20 and having *std::forward(n) do the right think (at least for=20 optional) instead of requirng separte handling of owning/non-owning=20 nullables. Also the r-value overloaded method/function approach is more=20 extensible for user defined classes, because we need some kind of way to=20 determine user-definied class owns specific member (they may be many of=20 them) and forward or forward_component should be used. I think that=20 overloading is a think simplest way. Meybe we need some king od language mechanism to define following set of=20 members: T&& mem() &&; T& mem()&; T const& mem() const&; --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_7_7260802.1404992569033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


W dniu czwartek, 10 lipca 2014 13:12:57 UTC+2 u=C5= =BCytkownik David Krauss napisa=C5=82:

On 2014=E2=80=930= 7=E2=80=9310, at 6:24 PM, toma...@gmai= l.com wrote:

W dniu= czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Krauss napisa= =C5=82:

forward_component trusts the user that the= function argument is owned by an object of the template argument type. It = handles vector::front and unique_ptr::operator* with equal aplomb, and we don=E2=80= =99t even have to add rvalue reference overloads to anything. (Although doi= ng so may still be a good idea.)

And= this wis actually break every use of forward with non-owning semenatics (s= hared_ptr<T>). Please remember that forward function was designed to = perfectly forward value of any type in generic context without introspectio= n, but introducing separate forward_compoent kills the idea, because we me = differentiate between shared_ptr and unique_ptr.

Shared ownership fails to satisfy the stated requirem= ent. No suitable forwarding semantics exist for shar= ed_ptr, and the value category of the pointer carries no information= about the shared object. You just have to assume that it=E2=80=99s not-own= ed, unless shared_ptr::unique returns true, i= n which case forward_component works.

No =E2=80=9Cgeneric context=E2=80=9D can handle diff= erent pointer types. unique_ptr<T>=  always owns its referent but T*&nb= sp;never does. You seem to suggest I=E2=80=99ve =E2=80=9Ckilled=E2=80=9D an= alternative that never existed in the first place.

Yes, it=E2=80=99s impossible to call make_sh= ared, destroy the sharing pool, and still safely bind the erstwhile-= shared value to a universal reference all in one declaration. This sounds p= retty contrived, though. Use of shared_ptr at= all implies that the object existed before the line in question, and if yo= u want to continue using a subobject after the line, don=E2=80=99t move() the shared_pointer.

Acu= tally defininig the rvalue reference overload for member getters returning = rvalue reference (T&& meber() &&) is the way a type can sig= nialize to forward that it owning this member. That means we could have:T&& operator*() &&; //for unique_ptr, bot not for shared_p= tr
Or for vector<T>:
T&& front() &&;
T&&= amp; back() &&;
Or even for begin/end members that will allows u= s to have better traversable constructor: https://groups.google.com/= a/isocpp.org/forum/?fromgroups#!topic/std-proposals/sOw68ogy= 6BM

Yes, I mentioned th= at hypothetically to Ville. Considering the implementation effort and added= compilation complexity of that strategy, you might as well use forward_component() with no adjustment to the cont= ainer (or plain-old move() when not forw= arding).

Now const= && should have the same semenantics as the const& so the additi= on overload is not necessary.

S= trange, I didn=E2=80=99t realize that const& is preferred over && for a const rvalue implicit argument, but so it is. GCC e= ven fails to prefer const&& over const&.

My point is that with the montions that will begin with having T&= & value()&& method we can start a montion to make following cod= e:
template<typename Nullable>
void f(Nullable&& n)
= {
   foo(*std::forward<Nullable>(n));
};
To pass a= n T&& if Nullable&& is optional<T>&& and pass= reference (optionally) const for shared_ptr<T>, unique_ptr<T>,= T*. If we add then T&& operator*() &&; for unique_ptr<T= > to represent ownership.
Then we will have at least one case handled= in the forward correclty.

In think t= hat the class should definie if it have ownership over member *by defininin= g r-value overload) and this should not be handled on the invoker side, by = requring using forward_component or move. This also brakes encapsulation. <= br>
If we have methods (T&& operator*() && for unique_pt= r<T> and optional<T>, but not for shared_ptr<T> and of co= urse T&&) metonied above the expression *std::forward<Nullable&g= t;(n) will do the right thing and not forward_compoent being necessary. If = we go with the T value()&& in the current sementic of value() metho= d (giving acces to stored value, not returning value)=20 we will close this way.

I think that library should be make easier t= o use at cost of it complexlity and having *std::forward<Nullable>(n)= do the right think (at least for optional) instead of requirng separte han= dling of owning/non-owning nullables. Also the r-value overloaded method/fu= nction approach is more extensible for user defined classes, because we nee= d some kind of way to determine user-definied class owns specific member (t= hey may be many of them) and forward or forward_component should be used. I= think that overloading is a think simplest way.

Meybe we need some = king od language mechanism to define following set of members:
  T&= amp;& mem() &&;
  T& mem()&;
  T const&= amp; mem() const&;

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_7_7260802.1404992569033-- .