220 31121 <2bde698e-c5be-4e20-bca0-d9fa0f90af12@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0577: No lifetime extension for xvalue . Date: Fri, 24 Feb 2017 14:04:34 -0800 (PST) Lines: 300 Approved: news@gmane.org Message-ID: <2bde698e-c5be-4e20-bca0-d9fa0f90af12@isocpp.org> References: <0f4944b0-11a6-4220-9d48-38086babc97a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1688_646112558.1487973874948" X-Trace: blaine.gmane.org 1487973881 4831 195.159.176.226 (24 Feb 2017 22:04:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 22:04:41 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB463YLCQKGQE4YBX2XI@isocpp.org Fri Feb 24 23:04:35 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chNyY-0000Gz-UH for gclcip-std-proposals@m.gmane.org; Fri, 24 Feb 2017 23:04:31 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id g30sf19164623uac.5 for ; Fri, 24 Feb 2017 14:04:37 -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:in-reply-to:references: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=zY4afjDPVay86OIhc4nQ1V6yyO7024rFO1KhZxKMFWE=; b=O7jiprFQShN7fkQylglA32/voJvD/xULTcOXW+uXIuGI5CWFq4grRtId76U2UGvw32 YSTOMa36JU10MLrsd1xGhVrpHnT5R9I0dZCnMjczvGsDZXLHk5I4/cOIYbrsTuz2/LSu Y1LrFqY2QotgtAdjq2FjlUbwCjPsVHXxDKJBXK7X/CKqvwc9sd48/2oW0kPId3C5Tu01 5CsCXGKYrYAUg6hX6y4r2Z6wwZauOM0xScFsl8VNXZgZfijtGn0QscYeRwZ+1aheR9yl DIYfptTYkcwXH5+0zg9+sqaG+4woQN9HwqbNeaFtIfrFvWY/8OrzWWstw2K89BRGcZ4Y ojIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references: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=zY4afjDPVay86OIhc4nQ1V6yyO7024rFO1KhZxKMFWE=; b=EW4+AXj1zCvXgH0PI5JVVZ9dWyt2BFyEJbWuweE6u2FcWPYwsmu8d4HyI+cdXM2A4W 8M7i5j14/OTCBGtdyrRQcDqIK+kWcoeBiv1y57DVQCqCK/zEnR3RnmZU/l6gIr1XMwcT I3ICyxEHVNT7UXZWdj6d0bFzzZStUgrJ96Pl5yAk+K9cUS0omAUJ59d08U01PyVoQ9Jn a/fgl6uzGMs99jHkvlU7xyT1jhacQQEW+9Ty2czPLeQUjiUmCEIlv22Md2lr3mcIDxHB j0F9RaS9VnfPa3R09ptHfqI1YBpmceGGvQZO2rbi/A8Gh8i361KIunG6+sGltt2jNMd5 NhVw== 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:in-reply-to:references :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=zY4afjDPVay86OIhc4nQ1V6yyO7024rFO1KhZxKMFWE=; b=fOI2HUkAGPswT23vpVzdmotzEXAvSaeQcctgKtISjBNRvCZhbvf+OHaBPNzxkwJKO/ LqVyRRAbwMk/9fHtGo9BNIMAq9aQk/9QNPLJZu6+S/TbiCVkMAI+0bz710webW58h8kx yQWrPdD8MOCnWxClO320QXGXrx7IuoZc8sBEP0jMhFDzBg2ZR53Orb+kRiPuYBJVoVhS X2pxWCqdh4TOuJQQ+C5NG6NuN8o+qy3p3T8sh69QIC4ylG3AXVSHJ8QKjbnahf0whPrQ IFNaGgd/eTDedeBh+ho0HhgkTCOm4pK1OkROzS6/QEqPVxrD/1PFj/ue+sCS6KsD/2je yRuQ== X-Gm-Message-State: AMke39mDHv0eLeRFYq0kKbzJJ8u0o08MYvxEAM+XLz+AuUu7ebFEyDraSrXa1aQkkycpuA== X-Received: by 10.176.3.11 with SMTP id 11mr1379649uat.29.1487973876510; Fri, 24 Feb 2017 14:04:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.45.170 with SMTP id g39ls8836480otb.49.gmail; Fri, 24 Feb 2017 14:04:35 -0800 (PST) X-Received: by 10.157.37.70 with SMTP id j6mr413094otd.0.1487973875813; Fri, 24 Feb 2017 14:04:35 -0800 (PST) In-Reply-To: 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:31121 Archived-At: ------=_Part_1688_646112558.1487973874948 Content-Type: multipart/alternative; boundary="----=_Part_1689_1664304744.1487973874949" ------=_Part_1689_1664304744.1487973874949 Content-Type: text/plain; charset=UTF-8 On Friday, February 24, 2017 at 3:29:43 PM UTC-5, Zhihao Yuan wrote: > > On Feb 24, 2017 12:53 PM, "Nicol Bolas" > > wrote: > > > Now, I do recognize that this could potentially be problematic in template > cases. > > > We don't change value category nor ill-formed the program for exactly that > reason. > > But, at the same time, I would say that it is very rare that you encounter > a function that returns an rvalue reference when you didn't *expect* this. > > > It's very possible that in a template, in some instantiations a dependent > function call returns prvalue and in some other instantiations the same > code returns xvalue. We don't want to break your instantiations when they > are valid, so we modeled __extend_me in a way giving pure gain without hard > errors. > "Very possible" does not mean "likely", "common", or even "useful". What would template code be doing where a dependent function call could return either a prvalue or an xvalue, *and* you have a need to extend the lifetime of the returned temporary? Indeed, just think about that situation for a minute. You *don't know* if the function returns a temporary or not, so why are you extending its lifetime? I do not understand why I would ever write that code. I just can't see how it makes sense to want to extend the lifetime of something that you don't even know has a lifetime to be extended. Can you give an example where such code actually makes sense? Where it is actually valid and reasonable code, in both the prvalue and xvalue case? And not an artificial, "this could work" example. I can write code where it would technically compile and technically do something. I mean code where it genuinely makes sense. It should also be noted that, by not making `register X().s` an lvalue, you *are* losing something: consistency. auto &&x1 = X().s; //This works. auto &&x2 = X(); //This works. auto &&x3 = register X().s; //This works. auto &&x4 = register X(); //This doesn't work. `x4` fails because the result of applying `register` to a prvalue is an lvalue. But applying `register` to an xvalue, which *also extends a temporary*, results in an xvalue. How does that make sense? Also, by making it explicitly illegal to use it in such cases, we also make > it so that users don't screw up like this: > > //Given a Type::getFoo() which returns a `T&&` member of that type, when > given a `this` &&. > Type().getFoo(); //Returns a dangling reference. > register Type().getFoo(); //Still returns a dangling reference, but > silently compiles. > > By making that last statement explicitly il-formed, we can prevent people > from screwing that up. So while they may be confused why `register > Type().x` works when `register Type().getX()` fails, at least the compiler > tells them it won't do what they *think* it does. > > > Compiler can choose to warn it anyway. > You could use this same reasoning about lots of things we don't allow, like casting away `const`-ness with `static_cast`, requiring people to use `std::move` in order to move from lvalues, and so forth. Compilers could have warned about those things, but we explicitly made them errors. Why *shouldn't* we make this code an error? It seems to me that this code is clearly not what the user wanted and will only end in tears. Undefined behavior tears. Is there a legitimate use for `register` when applied to an xvalue that is not a temporary-subobject? If you can't come up with a reason why it should be allowed, then it ought to be forbidden. After all, it's easier to allow something later if it's forbidden than it is to forbid a bad idea after we've proven it causes lots of problems. Also, I thought of an interesting feature related to span: being able to > qualify function members such that, if a user uses a temporary with that > overload, then the temporary will automatically have its lifetime extended > properly. And if they use something that isn't lifetime extendable (or is > not an lvalue), then they get an error. This could be applied to `const&` > parameters just like `&&` ones. > > > We considered various "smart" approaches, and we chose to propose the > dumbest one -- pure manual control. Explained in the paper. > That's not what I get from reading the paper. The first paragraph of the Motivation section talks about N4221. But it only mentions its deficiencies in terms of the fact that the *only* way to benefit from that feature is to edit the function definitions. Nowhere does your paper discuss why providing *only* manual control is better. It seems to me that having either mechanism alone is overall less effective than having *both*. And your paper doesn't really address this. Also, the idea I suggested is not particularly "smart". It makes no attempt to follow variables through to return values and so forth. It only extends parameters. -- 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 email 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/2bde698e-c5be-4e20-bca0-d9fa0f90af12%40isocpp.org. ------=_Part_1689_1664304744.1487973874949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, February 24, 2017 at 3:29:43 PM UTC-5, Zhihao Y= uan wrote:
On Feb 24, 2017 12:53 PM, "Nicol Bo= las" <jmck...@gmail.com> wrote:
Now, I do recognize that this could potentially be problematic in template= cases.

We don't change value category nor ill-formed the = program for exactly that reason.

Bu= t, at the same time, I would say that it is very rare that you encounter a = function that returns an rvalue reference when you didn't expect= this.

=
It's very possible that in a template, in some = instantiations a dependent function call returns prvalue and in some other = instantiations the same code returns xvalue.=C2=A0 We don't want to bre= ak your instantiations when they are valid, so we modeled __extend_me in a = way giving pure gain without hard errors.

= "Very possible" does not mean "likely", "common&qu= ot;, or even "useful". What would template code be doing where a = dependent function call could return either a prvalue or an xvalue, and<= /i> you have a need to extend the lifetime of the returned temporary?
Indeed, just think about that situation for a minute. You don't kn= ow if the function returns a temporary or not, so why are you extending= its lifetime? I do not understand why I would ever write that code. I just= can't see how it makes sense to want to extend the lifetime of somethi= ng that you don't even know has a lifetime to be extended.

Can y= ou give an example where such code actually makes sense? Where it is actual= ly valid and reasonable code, in both the prvalue and xvalue case? And not = an artificial, "this could work" example. I can write code where = it would technically compile and technically do something. I mean code wher= e it genuinely makes sense.

It should also be noted that, by not mak= ing `register X().s` an lvalue, you are losing something: consistenc= y.

auto &= amp;&x= 1 =3D X().s; //This works.
auto &&x2 =3D X(); //This works.<= span style=3D"color: #000;" class=3D"styled-by-prettify">

auto &&x3 =3D register X().= s;<= span style=3D"color: #000;" class=3D"styled-by-prettify"> //This works.
= auto &&x4 =3D register X(); //This doesn't work.

`x4` fails because= the result of applying `register` to a prvalue is an lvalue. But applying = `register` to an xvalue, which also extends a temporary, results in = an xvalue. How does that make sense?

Also, by making it explicitly i= llegal to use it in such cases, we also make it so that users don't scr= ew up like this:

= //Given a Type::getFoo() which returns a `T&= &` member of that type, when given a `this` &&.
Type().getFoo(); //Returns a dangling reference.
register Type().getFoo(); //Still returns a dangling reference, but silently compiles.

By making that last statement explicitly il-formed= , we can prevent people from screwing that up. So while they may be confuse= d why `register Type().x` works when `register Type().getX()` fails, at lea= st the compiler tells them it won't do what they think it does.<= br>

<= div dir=3D"auto">Compiler can choose to warn it anyway.

You could use this same reasoning about lots of things we don= 't allow, like casting away `const`-ness with `static_cast`, requiring = people to use `std::move` in order to move from lvalues, and so forth. Comp= ilers could have warned about those things, but we explicitly made them err= ors.

Why shouldn't we make this code an error? It seems t= o me that this code is clearly not what the user wanted and will only end i= n tears. Undefined behavior tears.

Is there a legitimate use for `re= gister` when applied to an xvalue that is not a temporary-subobject? If you= can't come up with a reason why it should be allowed, then it ought to= be forbidden. After all, it's easier to allow something later if it= 9;s forbidden than it is to forbid a bad idea after we've proven it cau= ses lots of problems.

<= blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex">
Also, I thought of an interesting feature rel= ated to span: being able to qualify function members such that, if a user u= ses a temporary with that overload, then the temporary will automatically h= ave its lifetime extended properly. And if they use something that isn'= t lifetime extendable (or is not an lvalue), then they get an error. This c= ould be applied to `const&` parameters just like `&&` ones.
=

We considered various "smart" approaches, and we ch= ose to propose the dumbest one -- pure manual control.=C2=A0 Explained in t= he paper.

That's not what I get from r= eading the paper. The first paragraph of the Motivation section talks about= N4221. But it only mentions its deficiencies in terms of the fact that the= only way to benefit from that feature is to edit the function defin= itions. Nowhere does your paper discuss why providing only manual co= ntrol is better.

It seems to me that having either mechanism alone i= s overall less effective than having both. And your paper doesn'= t really address this.

Also, the idea I suggested is not particularl= y "smart". It makes no attempt to follow variables through to ret= urn values and so forth. It only extends parameters.

--
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/2bde698e-c5be-4e20-bca0-d9fa0f90af12= %40isocpp.org.
------=_Part_1689_1664304744.1487973874949-- ------=_Part_1688_646112558.1487973874948-- .