220 11893 <3baba983-4d62-4887-a969-020ecf027a45@isocpp.org> 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: Sat, 12 Jul 2014 05:57:13 -0700 (PDT) Lines: 417 Approved: news@gmane.org Message-ID: <3baba983-4d62-4887-a969-020ecf027a45@isocpp.org> 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> <35873CE5-ED8C-4C03-A6A1-E4132DECD91F@gmail.com> <335948E6-8140-4673-B958-930356A52070@gmail.com> <76ACA175-5A44-4BE8-B49F-BAC6DA65E6B1@gmail.com> <4D3852AD-1AEB-44BA-941C-D645BAD19405@gmail.com> <6a4b6425-1167-40c1-acd8-3945c8cd4c74@isocpp.org> <13DD0D7A-A146-4667-9F30-6FB3739CDBE0@gmail.com> <6B925FF7-2940-44C7-BF1D-13209A703BA2@gmail.com> <944C9C01-865B-4215-8C91-95F01AEA256E@gmail.com> <8DC3E474-3957-40B2-B492-D4AF2FDDD451@gmail.com> <0ACAE525-4FB2-4932-BBD2-F0623C4EBBFB@gmail.com> <52187852-ff8e-4e59-a8cf-7a29fd0a405b@isocpp.org> <8209A2E9-D947-4C00-A1F3-38F5676A4E52@gmail.com> <4c42f7c9-0588-4ab9-9af5-b2e692513993@isocpp.org> <225BBAAC-B3FA-4014-9FB6-64C48DF4208E@gmail.com> <1b70888c-eb6a-49e5-b254-a475ef015570@isocpp.org> <6CFC366C-D196-4A2E-B4EE-D1E6B26AE6C0@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27_187718.1405169833294" X-Trace: ger.gmane.org 1405169842 28230 80.91.229.3 (12 Jul 2014 12:57:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 12:57:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBKXBQSPAKGQEDFAYJZY@isocpp.org Sat Jul 12 14:57:17 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f69.google.com ([209.85.192.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5wrc-00068Z-IP for gclcip-std-proposals@m.gmane.org; Sat, 12 Jul 2014 14:57:16 +0200 Original-Received: by mail-qg0-f69.google.com with SMTP id j107sf5775712qga.0 for ; Sat, 12 Jul 2014 05:57:15 -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=c+XXArJyBGlTltu5g0F4vnw/61Tqzhf2ttgQeNndazw=; b=atiQJJjufFT5hE/rZDxtXDUeKx82U9wDueRf6XyUfJFOrzp7WUvFtxPoBT4DD0IooP a99O02bSGu3seTE0pjclH5j+KMDOSo2w4WuJiDV08yZxMYbFRzyMone/d6wImaNxWqN1 y0/J3jKR+LIDkSrQM/tqHwLIPDrBnQTE0lAqwbmRQMcZo4uKDZLy3viW3nC++8IUjKr3 D9XwrazZA36hpzUoBSPJFaMnb6qBGfpnAuJt+EpU6n4Bk5Dd72xSf0Xpl/AOy9YixJKf mNuIxWyyjNfYwXjRQ/oeye3bYED43Ot6LcFg0ebBDHOgiXw+qUjkhmGpLy+7QrY4XuYP G9Zw== 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=c+XXArJyBGlTltu5g0F4vnw/61Tqzhf2ttgQeNndazw=; b=OqJddob8gDsA05eYZIye7rKODBo7X9FmqYStk4FPZ/+6wvafQ/UJQ9rRTeAwsrWWlJ 0/YDzLiZYJpKf0WM9V6JbRFJbAYQl+4Uw19ei2d4ohL7MXYPN2FQvuzePi3NXCCQsw9+ cJNfX287i7gX6HjMRWx5fwNX7nmNu/gEDTBeAVBvAXTXbd/sDt+8PabCGM4QntVNnkGG ZPNtcAoIiy/OzIDZZqVARM00AYp+5G+UdGzGJ7lGE13yg3oo/BOBHHYRU/2w85njITsv MHh9MypjxkS7rKJqtIfvPZHbtPpjv05zMqbCfYgssmmsuB1jx2d5rNLUxLbJI5S0imwL HmGA== X-Gm-Message-State: ALoCoQmTbQdLaJbMtPUnmLMKF9/PRBuzt+gvP0CAavmaUAzLevLbF1sPzrRmeUypYRBc0EJGfolo X-Received: by 10.58.69.232 with SMTP id h8mr2599246veu.36.1405169835365; Sat, 12 Jul 2014 05:57:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.81.196 with SMTP id c4ls652726oby.63.gmail; Sat, 12 Jul 2014 05:57:14 -0700 (PDT) X-Received: by 10.182.176.37 with SMTP id cf5mr10053obc.22.1405169834195; Sat, 12 Jul 2014 05:57:14 -0700 (PDT) In-Reply-To: <6CFC366C-D196-4A2E-B4EE-D1E6B26AE6C0@gmail.com> 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:11893 Archived-At: ------=_Part_27_187718.1405169833294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu sobota, 12 lipca 2014 13:14:57 UTC+2 u=C5=BCytkownik David Krauss na= pisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9312, at 5:10 PM, toma...@gmail.com wrote: > > 3. Value r-value overload for operator[]: In the decltype(auto)=20 > get_fifth_thing(container_handle && ch) theauto && fifth_thing =3D=3D ( *= =20 > std::forward< container_handle >( ch ) )[ 5 ]; will cause fifth_thing to= =20 > be type of > T&&, meaning the return type of function will be reference and that= =20 > will cause auto && fifth_thing =3Dget_fifth_thing(std::forward<=20 > container_handle >( ch)) to be a dangling reference. The code will be=20 > broken by this transormation. > > > Actually, the program is ill-formed because the name fifth_thing is an=20 > lvalue and it will not bind to the returned rvalue reference. If it were= =20 > changed to std::forward< decltype( fifth_thing ) >( fifth_thing ), then= =20 > your argument holds, but that=E2=80=99s not realistically intuitive. If t= he problem=20 > is instead fixed by changing the return type to auto (since only special= =20 > move and forward functions should return xvalues) then my argument holds,= =20 > but then the user gets one or two copies (only zero or one if they think = to std::move(=20 > fifth_thing )). > > To be clear, I understand you are proposing:=20 template< typename container_handle > auto get_fifth_thing(container_handle && ch) { // Get only the fifth element. We don=E2=80=99t need the rest; OK to free= those=20 resources. // However, if not assuming ownership, there=E2=80=99s no need to make a = copy. auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )[ = 5 ]; //Some loging log_value_of_fifth_thing(fifth_thing); return fifth_thing; }=20 But then invocation of get_fifth_thing will always introduce an temporary= =20 even if proper lvalue of container_handle is passed as argument (and this= =20 time it must be an copy). Until now we were discussing only additional=20 temporaries in the case of rvalue passed to such function. I think that=20 adding additional temporary in any case is not acceptable in generic=20 context. Also it disallows modification of return if lvalue is passed. This= =20 lets us to desing when we have two separate functions get_fifth_thing for= =20 lvalue and rvalues with kills the idea of forwarding (or we will have the= =20 changes mentonied by you below, but they will have further consequences). I agree with you that return should be std::forward< decltype( fifth_thing= =20 ) >( fifth_thing ). But when I checked it with gcc-4.9.0 the return type is= =20 deduced to be T&, see http://goo.gl/ARPOix. I am not sure if it is a bug (I= =20 think it should be) or rule has been changed. =20 > This interaction between decltype(auto) and a named rvalue reference=20 > sounds like fodder for a core DR. It=E2=80=99s nasty regardless of librar= y=20 > policies, and considering that a diagnostic is already required, it=E2=80= =99s=20 > fixable. The safe solution, considering the possibility of a bound=20 > temporary, is to deduce a non-reference type (return a prvalue), and if t= he=20 > user wants to return an xvalue, they should write return std::forward(=E2= =80=A6).=20 > I=E2=80=99m also tempted to say that returning the name of an rvalue refe= rence=20 > should be a copy elision case, but this needs further study. (I=E2=80=99m= out on a=20 > limb, but given these two resolutions, then the code would work perfectly= ..) > > =20 This will introduce a lot of temporaries in the code. Let assume we have: struct A { struct B { std::vector members;=20 } b; }; =20 And have following getter functions that uses delctype(auto): template decltype(auto) get_B(T&& t) { return std::forward(t).b; } template decltype(auto) get_members(T&& t) { return=20 get_b(std::forward(t)).members; } template decltype(auto) get_front(T&& t) { return=20 get_members(std::forward(T)).front(); } The following code: auto cs =3D get_front(A()); May copy members of vector 2 times. Because get_B will return by value (and= =20 copy members), then get_members will return by value. This may be stacked= =20 as many times as you want. I think it not acceptable performance loss to only get auto&& cs; Aside from named rvalue references, a policy of prvalue accessors will=20 > induce decltype(auto) to return by prvalue as well. > So with current language the prvalue policy will work only if you dont use= =20 auto&& cs in function and then return cs, and the prvalue policy was=20 introduced to make this auto&& cs actually work. Seems you found=20 contradicting arguments.=20 > > Breaking the connection between lifetime of object and lifetime of=20 > expression that should reference for subobject is not good think. > > > The question is whether or not to reference a subobject of an xvalue at= =20 > all. An xvalue is usually assumed to be invalidated by the first thing to= =20 > happen to it, usually any time between getting bound to a parameter and t= he=20 > semicolon. Once it=E2=80=99s passed, we don=E2=80=99t care what happens t= o it.=20 > Subobjects/components of xvalues devolving to prvalues preserves this rul= e,=20 > because there is never an actual reference to a subobject in the first=20 > place. > > "Once it=E2=80=99s passed, we don=E2=80=99t care what happens to it." And= propably this=20 argument let to desing that makes: auto&& cs =3D f().member; Work be extending liftime of whole object. But there is a think with the=20 RAII idom it is important to know when the object is actually destroyed.=20 The some think let to broken move-by-swap iimplemenation=20 (http://scottmeyers.blogspot.com/2014/06/the-drawbacks-of-implementing-move= ..html),=20 copy-and-swap is still valid, because it destroy previous values at the=20 point of assigment. The resultion that makes auto&& cs =3D f().member; work, has simliar=20 conseuqence: struct Result { unique_lock m; std::string member; }; Result f(); Lets assume you have found a following code block causing deadlock. { auto&& s =3D f().member; unique_lock lock(same_mutex_as_f_uses); } I think that every programmer will check the defintion of the member type= =20 (hold by s) to check if the any lock is held here, but I think would never= =20 expect that it is hold bu the result of f() being held under the hood by reference s, even if not explicitly=20 mentonied. This whole behavior is really more counter-intuitive than having= =20 the line auto&& s =3D f().member; create a dangling reference, which may be detected by simple memory sanitizing=20 tool. The lock would not be. Actually I think that this behaviour is insane in light of resource=20 handlers. And this is the reason I perceive this whole "make auto&& cs =3D expr"=20 movement work, even if it kills performance, introduce more=20 counter-intutive behavior as bad direction. My personal opinion: > > The only argument for T value()&& presented in this tread was that it= =20 > will make auto&& cs =3D f().value() work, but will cause performance=20 > downgrade in other parts of code,=20 > > > Maybe this is what came through the presentation of examples, but the cor= e=20 > argument is the principle that an xvalue is dead (and reusable) once it= =20 > goes into any function. I don=E2=80=99t think libraries scale well with a= ny other=20 > rule, although functions that =E2=80=9Conly=E2=80=9D perform access do in= tuitively seem=20 > special. > But in the generic code (as my before example) we are not knowing if we=20 have handling rvalue/lvalue, this is whole idea behind it. And in may=20 examples the container goes into the get_fifth_element and it no longer=20 used, so I think this example fits the argument.=20 --=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_27_187718.1405169833294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

On 2014=E2=80=930= 7=E2=80=9312, at 5:10 PM, toma...@gmai= l.com wrote:

  3. Value r-value overload for operator[]: In the=  decltype(a= uto) get_fifth_thing(container_handle && ch) = ;theauto &&a= mp; fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )[ = 5 ]; will cause fifth_thing to be type of
 = ;     T&&, meaning the return type of function = will be reference and that will cause auto && fifth_thing =3Dget_fifth_thing(std::forward< container_handle >( ch)) to be a dangling reference. The code will be broken by this t= ransormation.

Actuall= y, the program is ill-formed because the name f= ifth_thing is an lvalue and it will not bind to the returned rvalue = reference. If it were changed to std::forward< de= cltype( fifth_thing ) >( fifth_thing ), then your argument holds,= but that=E2=80=99s not realistically intuitive. If the problem is instead = fixed by changing the return type to auto (since only special move and=  forward functions should retu= rn xvalues) then my argument holds, but then the user gets one or two copie= s (only zero or one if they think to std::move( fift= h_thing )).

To be = clear, I understand you are proposing:
template< typename container_handle &g= t;
auto get_f= ifth_thing(container_handle && ch)
{
&nb= sp; // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr= ee those resources.
  // However, if not assuming ownership, there=E2=80=99s n= o need to make a copy.
  auto && fifth_thing =3D=3D ( * std= ::forward< container_handle >( ch ) )[ 5 ];
  //Some loging  log_value_of_fifth_thing(fifth_thing);
  return fifth_thing;
}
But then invocation of get_fifth_thing will always introduce an temporary even= if proper lvalue of=20 container_handle is passed as argument (and this time it must be an copy). = Until now we were discussing=20 only additional temporaries in the case of rvalue passed to such=20 function. I think that adding additional temporary in any case is not accep= table in generic context. Also it disallows modification of return if lvalu= e is passed. This lets us to desing when we have two separate functions get_fifth_thing for l= value and rvalues with kills the idea of forwarding (or we will have the ch= anges mentonied by you below, but they will have further consequences).
=
I agree with you that return should be std::forw= ard< decltype( fifth_thing ) >( fifth_thing ). But when I chec= ked it with gcc-4.9.0 the return type is deduced to be T&, see http://g= oo.gl/ARPOix. I am not sure if it is a bug (I think it should be) or rule h= as been changed.
 
This intera= ction between decltype(auto) and a named rval= ue reference sounds like fodder for a core DR. It=E2=80=99s nasty regardles= s of library policies, and considering that a diagnostic is already require= d, it=E2=80=99s fixable. The safe solution, considering the possibility of = a bound temporary, is to deduce a non-reference type (return a prvalue), an= d if the user wants to return an xvalue, they should write return std::forward(=E2=80=A6). I=E2=80=99m also tempted to s= ay that returning the name of an rvalue reference should be a copy elision = case, but this needs further study. (I=E2=80=99m out on a limb, but given t= hese two resolutions, then the code would work perfectly.)

 
This will introduce a lot of t= emporaries in the code. Let assume we have:
  struct A
  {<= br>     struct B
     {
 = ;         std::vector<only-copya= ble> members;
     } b;
  };
  <= br>And have following getter functions that uses delctype(auto):
  = template<typename T>
  decltype(auto) get_B(T&& t) { = return std::forward<T>(t).b; }

  template<typename T&g= t;
  decltype(auto) get_members(T&& t) { return get_b(std::= forward<T>(t)).members; }

  template<typename T>  decltype(auto) get_front(T&& t) { return get_members(std::f= orward<T>(T)).front(); }

The following code:
  auto cs=   =3D get_front(A());
May copy members of vector 2 times. Because g= et_B will return by value (and copy members), then get_members will return = by value. This may be stacked as many times as you want.
I think it not = acceptable performance loss to only get auto&& cs;

Aside from named rvalue references, a policy of prv= alue accessors will induce decltype(auto) to = return by prvalue as well.

So with c= urrent language the prvalue policy will work only if you dont use auto&= & cs in function and then return cs, and the prvalue policy was introdu= ced to make this auto&& cs actually work. Seems you found contradic= ting arguments.

Breaking the connection between life= time of object and lifetime of expression that should reference for subobje= ct is not good think.

The question is whether or not to reference a subobject of an xvalue at al= l. An xvalue is usually assumed to be invalidated by the first thing to hap= pen to it, usually any time between getting bound to a parameter and the se= micolon. Once it=E2=80=99s passed, we don=E2=80=99t care what happens to it= .. Subobjects/components of xvalues devolving to prvalues preserves this rul= e, because there is never an actual reference to a subobject in the first p= lace.

"Once it=E2=80=99s = passed, we don=E2=80=99t care what happens to it." And propably this argume= nt let to desing that makes:
   auto&& cs =3D f().memb= er;
Work be extending liftime of whole object. But there is a think with= the RAII idom it is important to know when the object is actually destroye= d. The some think let to broken move-by-swap iimplemenation (http://scottme= yers.blogspot.com/2014/06/the-drawbacks-of-implementing-move.html), copy-an= d-swap is still valid, because it destroy previous values at the point of a= ssigment.

The resultion that makes auto&& cs =3D f().member;= work, has simliar conseuqence:
struct Result
{
  unique_lock= <std::mutex> m;
  std::string member;
};
Result f();
Lets assume you have found a following code block causing deadlock.{
   auto&& s =3D f().member;
   unique_= lock<std::mutex> lock(same_mutex_as_f_uses);
 }
I think th= at every programmer will check the defintion of the member type (hold by s)= to check if the any lock is held here, but I think would never expect that= it is hold bu the result
of f() being held under the hood by reference = s, even if not explicitly mentonied. This whole behavior is really more cou= nter-intuitive than having the line auto&& s =3D f().member; create=
a dangling reference, which may be detected by simple memory sanitizing= tool. The lock would not be.
Actually I think that this behaviour is in= sane in light of resource handlers.

And this is the reason I perceiv= e this whole "make auto&& cs =3D expr" movement work, even if it ki= lls performance, introduce more counter-intutive behavior as bad direction.=

My personal opinion:

  The only argument= for T value()&& presented in this tread was that it will make auto= && cs =3D f().value() work, but will cause performance downgrade in= other parts of code,

Ma= ybe this is what came through the presentation of examples, but the core ar= gument is the principle that an xvalue is dead (and reusable) once it goes = into any function. I don=E2=80=99t think libraries scale well with any othe= r rule, although functions that =E2=80=9Conly=E2=80=9D perform access do in= tuitively seem special.

But in the g= eneric code (as my before example) we are not knowing if we have handling r= value/lvalue, this is whole idea behind it. And in may examples the contain= er goes into the get_fifth_element and it no longer used, so I think this e= xample fits the argument.

--

---
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_27_187718.1405169833294-- .