220 11726 <764569c3-b26b-4938-970e-44a4681de132@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Wed, 9 Jul 2014 04:21:43 -0700 (PDT) Lines: 206 Approved: news@gmane.org Message-ID: <764569c3-b26b-4938-970e-44a4681de132@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_125_22173508.1404904903166" X-Trace: ger.gmane.org 1404904912 26964 80.91.229.3 (9 Jul 2014 11:21:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jul 2014 11:21:52 +0000 (UTC) Cc: anna.salwa.05@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBSGL6SOQKGQEU5ALBAA@isocpp.org Wed Jul 09 13:21:46 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X4pwX-0004Yz-Ol for gclcip-std-proposals@m.gmane.org; Wed, 09 Jul 2014 13:21:46 +0200 Original-Received: by mail-ie0-f198.google.com with SMTP id lx4sf29234604iec.9 for ; Wed, 09 Jul 2014 04:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=BZWFGZqdRy4ZE7Nl28/FrJWaTN3y5/W/ECd7req52eE=; b=jKPXLRWiEKjNOpRTuXGS9y4HW2EkKgu3FO2540e1TTyL7zk7nljUuePKHwRpBCqeNJ fnWGr+qi/lNIG3UfPp+hIVvT19u1huGCfbK+TcuJkE32yKopM9dFboOblirGJC4hDHqk cty5pFdxUWhU4Jc6j1vtU4sog8J54BdwGuSkSj1Va0LpKSKwvq36MlEhu+ljuIxgzugH P92NN7H/+MLktE8jVce/IpgiW35HWFpo+mC+Ra/2ERzImu3xEhfVzs11vWZUoegcv8zR Bu/A4ysLVmmOPGu/CEIWM1L+Bi6TdSKo7XAstpSixVegRsSbXpVu2lXLonEu1skGOdFG h8Yg== 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:cc: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=BZWFGZqdRy4ZE7Nl28/FrJWaTN3y5/W/ECd7req52eE=; b=Q3RROCAlY3s9Ad/9r3wVIgqeOV/tcIYNocBaIUoxu3fyjKkqi85qKcINWZamLWxJ6P gnfKBaK5oBruGQ6qza2gveMipdYDwh1i2VdBWVs5kE0Lj594vORK8t0gDfLKOAS5uMfo UiG9D5ZpUDMCJmW+9wZAOGaipcc/lWszZVLN4W3Fi8bVmJL2VZtTOJvdRkw1NJ6mzVc6 g+G7YQzr095VKoI5DYuO3uvCjS7329+TzMraRjoDrMJz5iUIa9KRc3+vRK45vdVEvhOU bGAdZkkpoTOrbdhAa1m2LE55Mkkb3IgKkx/AvRxLLNfPqVhpmvnG6clAgp1Wh833Ynss pF+g== X-Gm-Message-State: ALoCoQnmRdpMLwITtK72sOhHzr64npSO6NZvkzILUhu3hTwiRYWJGYZiG02fsYCvcwiFsMXIO3C0 X-Received: by 10.182.28.5 with SMTP id x5mr10135506obg.44.1404904904861; Wed, 09 Jul 2014 04:21:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.42.195 with SMTP id q3ls1180961obl.97.gmail; Wed, 09 Jul 2014 04:21:44 -0700 (PDT) X-Received: by 10.182.226.233 with SMTP id rv9mr209955obc.6.1404904904087; Wed, 09 Jul 2014 04:21:44 -0700 (PDT) In-Reply-To: X-Original-Sender: akrzemi1@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:11726 Archived-At: ------=_Part_125_22173508.1404904903166 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu sobota, 5 lipca 2014 22:52:06 UTC+2 u=C5=BCytkownik anna.s...@gmail.= com=20 napisa=C5=82: > > In the paper N4078 two=20 > Rvalue reference overloads was added to the optional class: > constexpr T value() &&; > constexpr T value() const&& > I think this overloads should return by r-value reference instead.=20 > constexpr T&& value() &&; > > *I am not aware of any other motivation for this change, please post if= =20 > other one exists.* > Lets begin with the motivation for current desing. As far as I know this= =20 > was introduced to make=20 > following code well-behaved: > optional f(); > auto&& s =3D f().value(); //this code creates a dangling reference if w= e=20 > would return by reference > I don think making this well-behaved makes more harm that good. It adds= =20 > single exceptional class > int the langugage for which such code is well behaved. For example if we= =20 > write very similiar code > with a vector or std::tuple, this code wil still create a dangling=20 > reference. > std::vector f(); > auto&& s =3D f.front(); //dangling reference > std::tuple g(); > auto&& s =3D get<0>(g()); //this is emulation of expected or=20 > optional with tuple > So the standard library is not consistent with the behaviour, and even if= =20 > we fix every getter method > in the standard by adding rvalue overload, the problem still won't be=20 > fixed without changing language > in case of the members: > std::pair g(); > auto&& s =3D g().first; //will create a dangling reference > > So to summarize: > Now we have single class in the standard that provides the rvalue=20 > reference overload for getter method > and make the auto&& s =3D f().value() well defined. But this is not and= =20 > cannot be uniformly applied to > the rest of the language (because of member access). This in my opinion= =20 > makes language more complicated > and leave the programmer with two options: > - remember this special case and apply them when possible > - ignore existence of this overloads > > In addition the current desings introduces preformance impact on the code= ..=20 > Let assume following: > optional f(); > void g(const T&);o > =20 > vector vt; vt.emplace_back(f.value());=20 > g(f().value()); > This following two lines will now introduce additional=20 > move-construction o value of type T. > Someone may argue that this cost is not large becase move are cheap=20 > (for example std::string). But in the working codebase that > is a lot of legacy classes that are not move-constructible and this=20 > will introduce additional unecessary cost. Of course this > problem does not exists for tuple or pairs. > =20 > In my opinion it would be better to delcaret this functions as returning= =20 > reference because it will make it consistent with rest of the language > and by doing it will make it easier to use and understand. > The only motivation for returning by value -- to the best of my knowledge= =20 -- is the avoidance of dangling references in certain cases. My=20 understanding is that LEWG preferred these to return by value, even at the= =20 expense of incurring run-time overhead. My personal motivation was to=20 minimize the controversy with LEWG and increasing the chances of getting=20 the proposal through. (Rvalue ref overloads returning by value are better= =20 than no rvalue ref overloads.) I hope LEWG members are reading this list and can shed some more light on= =20 this question. Regards, &rzej --=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_125_22173508.1404904903166 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


W dniu sobota, 5 lipca 2014 22:52:06 UTC+2 u=C5=BC= ytkownik anna.s...@gmail.com napisa=C5=82:
I= n the paper N4078 two Rvalue reference overloads w= as added to the optional<T> class:
  co= nstexpr T value() &&;
  constexpr T value()= const&&
I think this overloads should return by= r-value reference instead.
  constexpr T&& value() &&;

I am= not aware of any other motivation for this change, please post if other on= e exists.
Lets begin with the motivation for current desing. As far = as I know this was introduced to make
following code well-behaved:
&= nbsp; optional<string> f();
  auto&& s =3D f().value(= ); //this code creates a dangling reference if we would return by reference=
I don think making this well-behaved makes more harm that good. It adds= single exceptional class
int the langugage for which such code is well = behaved. For example if we write very similiar code
with a vector or std= ::tuple, this code wil still create a dangling reference.
  std::ve= ctor<std::string> f();
  auto&& s =3D f.front(); //da= ngling reference
  std::tuple<std::string, exception_ptr> g()= ;
  auto&& s =3D get<0>(g()); //this is emulation of = expected<T> or optional<T> with tuple
So the standard librar= y is not consistent with the behaviour, and even if we fix every getter met= hod
in the standard by adding rvalue overload, the problem still won't b= e fixed without changing language
in case of the members:
  std::pair<s= td::string, exception_ptr> g();
  auto&& s =3D g().first; //will create a dangling reference
So to summarize:
Now we have single class in the standard that pro= vides the rvalue reference overload for getter method
and make the auto&= amp;& s =3D f().value() well defined. But this is not and cannot be uni= formly applied to
the rest of the language (because of member access). T= his in my opinion makes language more complicated
and leave the programm= er with two options:
  - remember this special case and apply them = when possible
  - ignore existence of this overloads

In addi= tion the current desings introduces preformance impact on the code. Let ass= ume following:
    optional<T> f();
  =   void g(const T&);o
 
   vector<T> vt= ; vt.emplace_back(f.value());
   g(f().value());
 &nb= sp; This following two lines will now introduce additional move-constructio= n o value of type T.
   Someone may argue that this cost is no= t large becase move are cheap (for example std::string). But in the working= codebase that
   is a lot of legacy classes that are not move= -constructible and this will introduce additional unecessary cost. Of cours= e this
   problem does not exists for tuple or pairs.
 = ;
In my opinion it would be better to delcaret this functions as returni= ng reference because it will make it consistent with rest of the languageand by doing it will make it easier to use and understand.

The only motivation for returning by value -= - to the best of my knowledge -- is the avoidance of dangling references in= certain cases. My understanding is that LEWG preferred these to return by = value, even at the expense of incurring run-time overhead. My personal moti= vation was to minimize the controversy with LEWG and increasing the chances= of getting the proposal through. (Rvalue ref overloads returning by value = are better than no rvalue ref overloads.)

I hope LEWG members are re= ading this list and can shed some more light on this question.

Regar= ds,
&rzej

--

---
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_125_22173508.1404904903166-- .