220 31114 <0f4944b0-11a6-4220-9d48-38086babc97a@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 10:53:25 -0800 (PST) Lines: 248 Approved: news@gmane.org Message-ID: <0f4944b0-11a6-4220-9d48-38086babc97a@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_307_21947750.1487962405198" X-Trace: blaine.gmane.org 1487962405 27556 195.159.176.226 (24 Feb 2017 18:53:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 18:53:25 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJMCYLCQKGQE7AQOA2A@isocpp.org Fri Feb 24 19:53:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f198.google.com ([209.85.216.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chKzY-0006cK-M2 for gclcip-std-proposals@m.gmane.org; Fri, 24 Feb 2017 19:53:20 +0100 Original-Received: by mail-qt0-f198.google.com with SMTP id b51sf8204474qta.4 for ; Fri, 24 Feb 2017 10:53:27 -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=YCWMX5jZe2vS9J0UvE07OrNE9eXGR5Xgd6j29Ri1tEA=; b=nemIAV6HTcD4yFmSsg3ZBZb/PhQ5h/v9M/jEYiXiwCsTF5Vq6N9HinIAvom8xCgOjS fFqOzvuN2BzZTxzJ1eydZDfm28jTuzAi+blMEadrLhKZBcWDEXSNj1udnzlbwanWZ8Uo YXrY/FogFY0ZzaSLjxxty0IvTfghLn0ql4+nkl9mXtWM96x3Xnk1Cjl0fmtw6JuRYUB+ ecaA6hKJPHXsDcQI3AmpyhBkup7q1EiRmITZKyHfm3PL3CjqQY9YVwpw/9BXi0AuvYLF BLfZHC1x6ewyiZQM6rM9f/FdQo0GT1da2hcqjyHxHcS4leS2mqesIfemrGGOq5h4yvAL 6QKA== 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=YCWMX5jZe2vS9J0UvE07OrNE9eXGR5Xgd6j29Ri1tEA=; b=jl8CS6sX04eSR0XLZQgKVi5S/e5UK3AxHeGmY6ijeIj29FdA7bqIQR+rVWsb71SGF0 +OiawBozrTfb0Ep/i4+pC1AXYY3PbAMORcMtZnPUfwpXNOfZ830YlMog9PdF+1UGu9GW yHWYEx/Ulfj5+jEV5nKYV2eXNQyPmTuk9+VLppKfMqPcLiSKP6zL/d/m/awuRKy+cu07 PioPLNystPBm+RQyhhQSYq4MNNAmk57mB27ZHHKf17P98xDa4eTN6obJmZjUa7FlRSe7 eyc1iiCCjjtSb1b5fYGJCVMm9oT1KVCQYW4nxaUkX0pahsS9twpA1OH4MCuuT1e/zDVe a8fg== 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=YCWMX5jZe2vS9J0UvE07OrNE9eXGR5Xgd6j29Ri1tEA=; b=W7x/CjbkuDEl6Taw9tUOM374VXnC4yFU0taKBPA58jIFZWeSD7XvrikhDQKXbOaPr2 8ouUGIJcNPlA8kIcIu7QL7uL2sq3qM2RVpsINiTfxdgMWdWP0IzPYtcjZKy4niwM0BKw gDScZ2Ky5ItLa2cXnKQegfbYYy6BDpYsgmnDOPq1H46hTd2goQNc97SRpJHi/AVbTFtF 6z+VXyjYMPKXS/9Uc2Uia+2LxBU+pBN5eb9zheDjJM8DV6KwGn4Eyf9EQZwYCQg1yIzn t38MQq7VH8A5OnRSOW3TQqLnY0zp2FP6skCtls/jetepaYXSpaOuaa9/qySDVNhTloTI /MSg== X-Gm-Message-State: AMke39nwdZ1oWh2inoFkbVFW2MOqGrlN7myEGSwgeq0hRFgj3ZQY9EUAVXa75ZVocemOCw== X-Received: by 10.200.43.17 with SMTP id 17mr1225661qtu.11.1487962406482; Fri, 24 Feb 2017 10:53:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.61.70 with SMTP id a64ls7232298otc.35.gmail; Fri, 24 Feb 2017 10:53:25 -0800 (PST) X-Received: by 10.157.89.144 with SMTP id u16mr323375oth.16.1487962405708; Fri, 24 Feb 2017 10:53:25 -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:31114 Archived-At: ------=_Part_307_21947750.1487962405198 Content-Type: multipart/alternative; boundary="----=_Part_308_436960159.1487962405199" ------=_Part_308_436960159.1487962405199 Content-Type: text/plain; charset=UTF-8 On Friday, February 24, 2017 at 12:46:07 PM UTC-5, Zhihao Yuan wrote: > > On Fri, Feb 24, 2017 at 8:48 AM, Nicol Bolas > wrote: > > auto &&r2 = X().n; > > > > For `r1`, if `f` returns an rvalue reference that refers to its > parameter or > > a subobject thereof, this will be a dangling reference. > > > > 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 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 for any expression for which lifetime extension is currently > > valid. It should behave exactly as if you had created a reference > variable > > with that expression. > > I think we can find some compromise here, that is to extend > lifetime for certain xvalues that we can, but not change any > xvalue's value category, making it useful to interfaces > which do not care about value categories, and still safe in > general. Example: > > struct X { std::string s; }; > string_view x = __extend_me X().s; // fine, extending s > I'm not sure why changing the value category would be problematic here. Consider `span`; it explicitly deletes rvalue reference constructors (and for good-yet-debatable reasons). But there should never be a case where `as_span(register )` would *not* work. Or at least, if `register ` works, then `as_span` of that should also work (assuming it's a `span`-able type). I would say that if `register ` is applied to an expression which *both* is not an lvalue expression and doesn't extend the lifetime of a temporary, then it should be flat-out ill-formed. And therefore, the resulting expression from a valid instance of `register` is *always* an lvalue. Including `X().s`. The idea needs to be that I can rewrite the expression as though I bound it to a reference: auto &&temp = X().s; string_span x = temp; //Assuming template deduction guides and so forth. And the result will be exactly the same. Now, I do recognize that this could potentially be problematic in template cases. 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. When it isn't explicitly part of the function's purpose. 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. 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. Note that I recognize that this could lead to temporaries that last longer than strictly necessary. But I think it's good to have a way for a function to enforce its rules and explicitly forbid the use of objects which cannot live beyond the lifetime of the function call. Of course, we'd want to use the same keyword in the parameter list as we do in expressions for lifetime extension. Unfortunately, that takes `register` off the table. But on the plus side, the standards committee seems willing to add keywords for less useful features like control structures for `for`, so maybe they'd add one for this too. -- 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/0f4944b0-11a6-4220-9d48-38086babc97a%40isocpp.org. ------=_Part_308_436960159.1487962405199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, February 24, 2017 at 12:46:07 PM UTC-5, Zhihao = Yuan wrote:
On Fri, Feb 24, 201= 7 at 8:48 AM, Nicol Bolas <jmck...@gmail.com> wrote:
> auto &&r2 =3D X().n;
>
> For `r1`, if `f` returns an rvalue reference that refers to its pa= rameter or
> a subobject thereof, this will be a dangling reference.
>
> 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 idea of lifetime extension should not be that you provide life= time
> extension for all xvalues. But it also shouldn't be that you p= rovide
> lifetime extension for prvalues. It should be that you provide lif= etime
> extension for any expression for which lifetime extension is curre= ntly
> valid. It should behave exactly as if you had created a reference = variable
> with that expression.

I think we can find some compromise here, that is to extend
lifetime for certain xvalues that we can, but not change any
xvalue's value category, making it useful to interfaces
which do not care about value categories, and still safe in
general. =C2=A0Example:

=C2=A0 struct X { std::string s; };
=C2=A0 string_view x =3D __extend_me X().s; =C2=A0// fine, extending s

I'm not sure why changing the value category = would be problematic here. Consider `span`; it explicitly deletes rvalue re= ference constructors (and for good-yet-debatable reasons). But there should= never be a case where `as_span(register <expr>)` would not wo= rk. Or at least, if `register <expr>` works, then `as_span<T>` = of that should also work (assuming it's a `span`-able type).

I w= ould say that if `register <expr>` is applied to an expression which = both is not an lvalue expression and doesn't extend the lifetime= of a temporary, then it should be flat-out ill-formed.

And therefor= e, the resulting expression from a valid instance of `register` is alway= s an lvalue. Including `X().s`.

The idea needs to be that I can = rewrite the expression as though I bound it to a reference:

auto &&temp =3D X().s;<= br>string_span x =3D= temp; //Assuming template ded= uction guides and so forth.

And the result wil= l be exactly the same.

Now, I do recognize that this could potential= ly be problematic in template cases. But, at the same time, I would say tha= t it is very rare that you encounter a function that returns an rvalue refe= rence when you didn't expect this. When it isn't explicitly = part of the function's purpose.

Also, by making it explicitly il= legal to use it in such cases, we also make it so that users don't scre= w up like this:

//Given a Type::getFoo() which returns a `T&&` membe= r of that type, when given a `this` &&.
Type().getFoo(); //= Returns a dangling reference.
register Type().<= /span>getFoo(); //Still returns a dangling refe= rence, but silently compiles.

By making that l= ast statement explicitly il-formed, we can prevent people from screwing tha= t up. So while they may be confused why `register Type().x` works when `reg= ister Type().getX()` fails, at least the compiler tells them it won't d= o what they think it does.

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 auto= matically have its lifetime extended properly. And if they use something th= at isn't lifetime extendable (or is not an lvalue), then they get an er= ror. This could be applied to `const&` parameters just like `&&= ` ones.

Note that I recognize that this could lead to temporaries th= at last longer than strictly necessary. But I think it's good to have a= way for a function to enforce its rules and explicitly forbid the use of o= bjects which cannot live beyond the lifetime of the function call.

O= f course, we'd want to use the same keyword in the parameter list as we= do in expressions for lifetime extension. Unfortunately, that takes `regis= ter` off the table. But on the plus side, the standards committee seems wil= ling to add keywords for less useful features like control structures for `= for`, so maybe they'd add one for this too.

--
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/0f4944b0-11a6-4220-9d48-38086babc97a= %40isocpp.org.
------=_Part_308_436960159.1487962405199-- ------=_Part_307_21947750.1487962405198-- .