220 31109 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: P0577: No lifetime extension for xvalue . Date: Fri, 24 Feb 2017 06:48:36 -0800 (PST) Lines: 142 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_230_236939765.1487947716905" X-Trace: blaine.gmane.org 1487947721 9641 195.159.176.226 (24 Feb 2017 14:48:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 14:48:41 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBRMPYHCQKGQEKT2SEUY@isocpp.org Fri Feb 24 15:48:36 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f198.google.com ([74.125.82.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chHAe-0001ho-IS for gclcip-std-proposals@m.gmane.org; Fri, 24 Feb 2017 15:48:32 +0100 Original-Received: by mail-ot0-f198.google.com with SMTP id 96sf40027260ota.7 for ; Fri, 24 Feb 2017 06:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=qCIc3yjvimVnRzktsJQ7yTtk21NwThjcliyf9QZOy+g=; b=juwRisxaoQrYaU8F8FJtuSPQftLCZvSzHAfK2hsEeMsb98y3DjJPo/cWnRHwUeIixR qJ//i6GvGpsxaasx3tJi679GDJsZXSzNRWJKq7mVKsbkJwpBhKnQprjNsSwJQriYxl5V /6W0vwD9ZWT4YY/Cc5M55YJ640YWoUEcNxL8A6MWryIGgThpproTB28K0AQnKbhz3NmT GpFqK+vNirhCUTyP7WI3+XL0YFH74NWaEJOGly5ZC4C2upQCzBBaaGPXJ0fsSClk0ymw 2IN/rmsyMk0OKSeR7EzKgbpuTsVsoKk05JcP+T/rjuX96UWrjhwROwAWVLb7DrLLBJWf AWZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=qCIc3yjvimVnRzktsJQ7yTtk21NwThjcliyf9QZOy+g=; b=Qwn7VZwnH0t5eoCoEpD2rhK/ymZqGp/67a34fE9kBcH62NFvSPcqx3TQbc+DPwNI6l VaaXrgiWMCkL6atxNVbJY7lF7k3rVQ1eG4NTF/otkeAtudjJ/fzTx0V3peFiMvikBmq+ VYl1O88S+Ynk7DJ4TmRxe38iVw5rkRclWM/BZW5ZlFsZN6czOtiQtGSbuW/RLasRo4en YOpKksu/JJJfRMVJsNuSpV4GTBGA3EKzM50yTmi09vvlXv/UMsnWdwMaBm/pqR2i2zel yV/xw2J3H6AOysf0kzW42biO+5MtdHdv37kEoT6phQ7A5EHeihbrgZGs+Hc3ONzJOO89 uZYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=qCIc3yjvimVnRzktsJQ7yTtk21NwThjcliyf9QZOy+g=; b=mPHXEjnMx6R754Ar7DiI5h+/5/CrAh9pK0IaSOcjMfyiXturkEHPXXf6qBGcd3QzG1 rsJUu+lfELpB5PwsQoh5bOwSgJU8inDC3NEqIGSXIyZ7oqlW6otwU7mELkWhX//Ffvjj YALw+5+AJbac5FCxMDyo5rpsSVcWvoIkwVBfh4F1X9qAweqw1P1lZyCNBptI1jZ2Kncy vt52UggNjpB4h+N6n2THUBgeSyERfCDes5FF2mDbz7u0/mJK7gW4jj5kyuUmPAaCHoTD yQzG7D17XMrJxwPXyCrp67s+QOtNXIAu6T9Y0iM27jJi0Tl9XVYIB6bAb3OMUz5wzaDy jgHA== X-Gm-Message-State: AMke39k+sOF2i2uf96ZfvwPMsNTBxe685BqG7r/6F2pk061YdNXx2n7GbLqa8edf1Frp1g== X-Received: by 10.157.17.149 with SMTP id v21mr951508otf.23.1487947718247; Fri, 24 Feb 2017 06:48:38 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.56.105 with SMTP id r38ls7433742otd.15.gmail; Fri, 24 Feb 2017 06:48:37 -0800 (PST) X-Received: by 10.157.84.15 with SMTP id j15mr150449oth.4.1487947717472; Fri, 24 Feb 2017 06:48:37 -0800 (PST) X-Original-Sender: jmckesson@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:31109 Archived-At: ------=_Part_230_236939765.1487947716905 Content-Type: multipart/alternative; boundary="----=_Part_231_1663272311.1487947716905" ------=_Part_231_1663272311.1487947716905 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P0577 (PDF) outlines a mechanism for extending the= =20 lifetime of a temporary. There is a part that I don't really understand: > *No lifetime extension for xvalue.* The authors evaluated each kind of=20 xvalue expressions, and concluded that there is no single efficient=20 mechanism to ensure all xvalues=E2=80=99 lifetimes, because xvalues are =E2= =80=9C(maybe)=20 eXpiring=E2=80=9D by nature. On the other hand, as shown in the following e= xamples,=20 [...] , prvalue lifetime extension can be more straightforward and more=20 efficient. The problem is the inconsistency with lifetime extension as it currently=20 exists. Consider the two cases explained in the paper, only here, we bind= =20 them to references: auto &&r1 =3D f(g()); auto &&r2 =3D X().n; For `r1`, if `f` returns an rvalue reference that refers to its parameter= =20 or a subobject thereof, this will be a dangling reference. But `r2` is *perfectly fine*. The lifetime of the prvalue temporary will be= =20 extended even though we are not actually referencing it directly.=20 [class.temporary]p6: > The temporary to which the reference is bound or the temporary that is=20 the complete object of a subobject to which the reference is bound =20 persists for the lifetime of the reference... P0577 cites 12.2 as reference for lifetime extension. The idea of lifetime extension should not be that you provide lifetime=20 extension for *all* xvalues. But it also shouldn't be that you provide=20 lifetime extension for prvalues. It should be that you provide lifetime=20 extension for any expression for which lifetime extension is *currently*=20 valid. It should behave *exactly* as if you had created a reference=20 variable with that expression. It seems neat being able to define lifetime extension as prvalue->lvalue=20 conversion, which allows you to think of temporary manifestation as=20 prvalue->xvalue conversion. But the inconsistency this definition creates= =20 is not a good thing. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/e1dd36c5-58c4-4f20-870f-d806158b1187%40isocpp.or= g. ------=_Part_231_1663272311.1487947716905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P0577 (PDF) outline= s a mechanism for extending the lifetime of a temporary.

There is a = part that I don't really understand:

> No lifetime extensi= on for xvalue. The authors evaluated each kind of xvalue expressions, a= nd concluded that there is no single efficient mechanism to ensure all xval= ues=E2=80=99 lifetimes, because xvalues are =E2=80=9C(maybe) eXpiring=E2=80= =9D by nature. On the other hand, as shown in the following examples, [...]= , prvalue lifetime extension can be more straightforward and more efficien= t.

The problem is the inconsistency with lifetime extension as it cu= rrently exists. Consider the two cases explained in the paper, only here, w= e bind them to references:

auto &&r1 =3D f<= /span>(g());
auto &&r2 =3D X()= ..n<= span style=3D"color: #660;" class=3D"styled-by-prettify">;

For `r1`, if `f` returns an rvalue reference that refers to it= s parameter or a subobject thereof, this will be a dangling reference.
<= br>But `r2` is perfectly fine. The lifetime of the prvalue temporary= will be extended even though we are not actually referencing it directly. = [class.temporary]p6:

> The temporary to which the reference is bo= und or the temporary that is the complete object of a subobject to which th= e reference is bound=C2=A0 persists for the lifetime of the reference...
P0577 cites 12.2 as reference for lifetime extension.

The idea = of lifetime extension should not be that you provide lifetime extension for= all xvalues. But it also shouldn't be that you provide lifetime= extension for prvalues. It should be that you provide lifetime extension f= or any expression for which lifetime extension is currently valid. I= t should behave exactly as if you had created a reference variable w= ith that expression.

It seems neat being able to define lifetime ext= ension as prvalue->lvalue conversion, which allows you to think of tempo= rary manifestation as prvalue->xvalue conversion. But the inconsistency = this definition creates is not a good thing.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/e1dd36c5-58c4-4f20-870f-d806158b1187= %40isocpp.org.
------=_Part_231_1663272311.1487947716905-- ------=_Part_230_236939765.1487947716905-- .