220 11750 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: Wed, 9 Jul 2014 12:21:54 -0700 (PDT) Lines: 355 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_335_18890479.1404933714826" X-Trace: ger.gmane.org 1404933727 22653 80.91.229.3 (9 Jul 2014 19:22:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jul 2014 19:22:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBU5M62OQKGQEFSS3AWI@isocpp.org Wed Jul 09 21:22:00 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X4xRF-0007mL-QG for gclcip-std-proposals@m.gmane.org; Wed, 09 Jul 2014 21:21:58 +0200 Original-Received: by mail-pa0-f71.google.com with SMTP id eu11sf53243376pac.2 for ; Wed, 09 Jul 2014 12:21:56 -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=aTiL91qAhwJZ+2PLbYmB1XatN01xVQ6sY1+nLo1VZ7Q=; b=dZVRwcemcFU0qAYpaTRqhxYJFLiRuJgadJwUwHwJA3IA7uY9BVU+e1dolg28hqyUW9 QlYKeGbZWyvkaoYmHoG4brDQBBkzh3p0dd4y2eeOn8q1Zpk6C+swzbk8W0pHmcOdoCtC tOnUb1l7NKO8vw6DIeA3Rwyr3BXtL8OBsuXSXkSWUvTCPPmWJD2bjWwLNPmcMAlneDAn MH/136bM5/Ca4Jk6lEoSzIwtzad6lu8Ov+vL3vPi7+9xxy6zqRNUxik/G1T199cY69Vj +BF8Rmq49sdfLG3QpvxoJmocdCn3EsJYxb2px8tZywZwYpVHtpP93CE8gpSYUD4nn7vs lwHQ== 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=aTiL91qAhwJZ+2PLbYmB1XatN01xVQ6sY1+nLo1VZ7Q=; b=FqjsIq1TW5pzQUTT9Oow1BRCz5/LZxN2vzIk7ceOi5ggDOi0+JG1gBpTassQkXQp4B EiPssy/lKLALN0+mPrSta44z2h86XVUEVmFRfaEVqB++h31BxmF5+Ymrjy4abdsxAokv PhPScp9BYGACAxXhOWYt41bbwP251xY8U+1Vi9XFgDC6b8XRKfB17i4XIYMvbRY6WQNd Bns0JeoY6kCQpphAghJ1MNTpaZim5zSq/30zQAFpWk78VNr9bxQarmm3eH8JZ1EUklub xofd/KpCd8ECSH5Wrv+uHhu8/3SNJ2CYZqKx+ikFhd/mOU4NcqkJxirjRTU1ap+qNs6C hmJQ== X-Gm-Message-State: ALoCoQnppmklmNfVem76RFA71f+lDYnYrk/ZtZV7+t0ycUk/RXrei9LaAgR1G0rMViTmuk/vS84t X-Received: by 10.66.155.226 with SMTP id vz2mr4808838pab.47.1404933716722; Wed, 09 Jul 2014 12:21:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.129.164 with SMTP id nx4ls1323914obb.88.gmail; Wed, 09 Jul 2014 12:21:55 -0700 (PDT) X-Received: by 10.182.109.234 with SMTP id hv10mr236719obb.2.1404933715497; Wed, 09 Jul 2014 12:21:55 -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:11750 Archived-At: ------=_Part_335_18890479.1404933714826 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu =C5=9Broda, 9 lipca 2014 21:09:36 UTC+2 u=C5=BCytkownik Jeffrey Yass= kin=20 napisa=C5=82: > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651=20 > addresses: > > std::pair g(); > auto&& s =3D g().first; //will create a dangling reference > > It's in 'ready' status, meaning it's not in C++14, but it's likely to get= =20 > fixed immediately after, possibly as a "defect", which would mean that mo= st=20 > compilers would implement the fix in their C++14 modes. > But it does not still fix the following: std::pair g(); auto&& s =3D std::get<0>(g()); //will create a dangling reference And I don not think that it is even possible to change meaning of the get= =20 with lvalue because lot of code depends of that. Or: auto f =3D std::mem_fn(A::member); /* ........... */ auto&& s =3D f(g()); //will create a dangling reference Actually I think taht the problem lies in the usage of auto&&, not in the= =20 return types. I agree that I'd rather see the general issue fixed by a language change=20 > (probably involving a change to the library to use the new language=20 > feature). I'm ambivalent about the safety fix we have in optional<>. > =20 Actually just one other case from the library that come to my mind. Would= =20 we want to make the following to do not create dangling reference: std::vector f(); auto&& s =3D *f.begin(); //dangling reference This will require us the create a begin/end r-value overload that returns= =20 same kind of copy-iterator that return by value when *it is invoked. I am= =20 not sure what consequence will it have. =20 > On Jul 5, 2014 1:52 PM, > wrote: > >> 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 = we=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 i= f=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=20 >> code. 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. >> >> --=20 >> >> ---=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at=20 >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> >=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_335_18890479.1404933714826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


W dniu =C5=9Broda, 9 lipca 2014 21:09:36 UTC+2 u= =C5=BCytkownik Jeffrey Yasskin napisa=C5=82:

http://www.open-std.org= /jtc1/sc22/wg21/docs/cwg_active.html#1651 addresses:

  std::pair<= std::string, exception_ptr> g();
  auto&& s =3D g(= ).first; //will create a dangling reference

It's in 'ready= ' status, meaning it's not in C++14, but it's likely to get fixed immediate= ly after, possibly as a "defect", which would mean that most compilers woul= d implement the fix in their C++14 modes.

But it= does not still fix the following:
  std::pair<std::string, exception_ptr> g();
  auto&& s =3D st= d::get<0>(g()); //will create a dangling reference
And I do= n not think that it is even possible to change meaning of the get with lval= ue because lot of code depends of that.
Or:
  auto f =3D std::me= m_fn(A::member);
  /* ........... */
  auto&& s =3D f(g()); //will create a dangl= ing reference
Actually I think taht the problem lies in the usage= of auto&&, not in the return types.

I agree that I'd rather see the general issue fixed by a language change= (probably involving a change to the library to use the new language featur= e). I'm ambivalent about the safety fix we have in optional<>.

Actually just one = other case from the library that come to my mind. Would we want to make the= following to do not create dangling reference:
    std::= vector<std::string> f();
    auto&& s =3D *= f.begin(); //dangling reference
This will require us the create a begin/= end r-value overload that returns same kind of copy-iterator that return by= value when *it is invoked. I am not
sure what consequence will it have.=
 
On Jul 5, 2014 1:52 PM, <anna.s...@gmail.com> wrote:
In the paper = N4078 two Rvalue reference overloads was added to = the optional<T> class:
  constexpr T value= () &&;
  constexpr T value() const&&= ;
I think this overloads should = return by r-value reference instead.
  constexpr T&& value() &&a= mp;;

I am not aware of= any other motivation for this change, please post if other one exists.=
Lets begin with the motivation for current desing. As far as I know thi= s was introduced to make
following code well-behaved:
  optional<string> f();
 = ; auto&& s =3D f().value(); //this code creates a dangling referenc= e if we would return by reference
I don think making this well-behaved m= akes more harm that good. It adds single exceptional class
int the langugage for which such code is well behaved. For example if we wr= ite very similiar code
with a vector or std::tuple, this code wil still = create a dangling reference.
  std::vector<std::string> f();<= br>   auto&& s =3D f.front(); //dangling 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 library is not consistent with the behaviour, and even if w= e fix every getter method
in the standard by adding rvalue overload, the= problem still won't be fixed without changing language
in case of the m= embers:
  std= ::pair<std::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). This in my opinion mak= es language more complicated
and leave the programmer with two options:<= br>  - remember this special case and apply them when possible
&nbs= p; - ignore existence of this overloads

In addition the current desings introduces preformance impact on the co= de. Let assume following:
    optional<T> f();
&= nbsp;   void g(const T&);o
 
   vector&= lt;T> vt; vt.emplace_back(f.value());
   g(f().value());
   This following two lines will = now introduce additional move-construction o value of type T.
 &nbs= p; Someone may argue that this cost is not 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 course this
 &n= bsp; problem does not exists for tuple or pairs.
 
In my opinion= it would be better to delcaret this functions as returning reference becau= se it will make it consistent with rest of the language
and by doing it will make it easier to use and understand.

--

---
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-proposal...@isocpp.or= g.
To post to this group, send email to s= td-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposal= s/.

--

---
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_335_18890479.1404933714826-- .