220 31118 article Path: news.gmane.org!.POSTED!not-for-mail From: Zhihao Yuan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0577: No lifetime extension for xvalue . Date: Fri, 24 Feb 2017 14:29:39 -0600 Lines: 154 Approved: news@gmane.org Message-ID: 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/alternative; boundary=001a114b4170ce8d5d05494c96af X-Trace: blaine.gmane.org 1487968188 21199 195.159.176.226 (24 Feb 2017 20:29:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 20:29:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCSKRWMD4EHBBNVPYLCQKGQEFKIE72Q@isocpp.org Fri Feb 24 21:29:42 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chMUj-0004Ve-8g for gclcip-std-proposals@m.gmane.org; Fri, 24 Feb 2017 21:29:37 +0100 Original-Received: by mail-oi0-f70.google.com with SMTP id q66sf8895849oib.0 for ; Fri, 24 Feb 2017 12:29:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:in-reply-to:references:from :date:message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Z7LxqI08Liw0howkC6vv76qDVduIhGsFtvpGysW5wgo=; b=CzQMpxvo50yOf7Uj8wwI9lHCkypu7TzhCd6My0j3aRfoLZDI9pLVnn04kHJ90VCP/q i/FdZ7dpKTseOAij8xt6gfFEsKf6i+8cMl1X5dVvjlS9G+zQBFd2BxA1o4G8R9IxQRTg ZfbgfqLCNDg9Uxc74AFfZ+x2Ch1f4VxIG3IAUcynTgpedzHWMgffiGZ5C+qdHjtFlVtK qKWcM3m2QVst5J27xsWMpNHNGS+FX2T8EyyMbcdeYkd0JXjnis1iD9HT50dBISzROsl4 Fi9/YiheK/QaJ0Hs8wncb0cKX6PDrtjwzdpSdGjaxh/ugdLBTKYWjdkQBX6OTPZ2fwZj buvA== X-Gm-Message-State: AMke39nANA3P+K57kjbnSFsQk0sRJXZLWc9H5uJMpnLx6jyzdA4O/zFfzBfpX/2aEivjWQ== X-Received: by 10.157.60.147 with SMTP id z19mr1450718otc.10.1487968182673; Fri, 24 Feb 2017 12:29:42 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.13.232 with SMTP id 95ls845345ots.19.gmail; Fri, 24 Feb 2017 12:29:42 -0800 (PST) X-Received: by 10.237.41.100 with SMTP id s91mr5092177qtd.143.1487968181900; Fri, 24 Feb 2017 12:29:41 -0800 (PST) Original-Received: from mail-s68.mailgun.info (mail-s68.mailgun.info. [184.173.153.196]) by mx.google.com with ESMTPS id d13si5907425qkb.262.2017.02.24.12.29.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 12:29:41 -0800 (PST) Received-SPF: pass (google.com: domain of bounce+3f9131.69110-std-proposals=isocpp.org@miator.net designates 184.173.153.196 as permitted sender) client-ip=184.173.153.196; Original-Sender: zy@miator.net X-Mailgun-Sending-Ip: 184.173.153.196 X-Mailgun-Sid: WyI3MTBkYiIsICJzdGQtcHJvcG9zYWxzQGlzb2NwcC5vcmciLCAiNjkxMTAiXQ== Original-Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by mxa.mailgun.org with ESMTP id 58b097b5.7f942815cc30-smtp-out-n02; Fri, 24 Feb 2017 20:29:41 -0000 (UTC) Original-Received: by mail-wr0-f181.google.com with SMTP id 89so20176342wrr.3 for ; Fri, 24 Feb 2017 12:29:40 -0800 (PST) X-Received: by 10.223.130.114 with SMTP id 105mr4123215wrb.41.1487968180011; Fri, 24 Feb 2017 12:29:40 -0800 (PST) Original-Received: by 10.80.173.212 with HTTP; Fri, 24 Feb 2017 12:29:39 -0800 (PST) Original-Received: by 10.80.173.212 with HTTP; Fri, 24 Feb 2017 12:29:39 -0800 (PST) In-Reply-To: <0f4944b0-11a6-4220-9d48-38086babc97a@isocpp.org> X-Gmail-Original-Message-ID: X-Original-Sender: zy@miator.net X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@miator.net; spf=pass (google.com: domain of bounce+3f9131.69110-std-proposals=isocpp.org@miator.net designates 184.173.153.196 as permitted sender) smtp.mailfrom=bounce+3f9131.69110-std-proposals=isocpp.org@miator.net 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:31118 Archived-At: --001a114b4170ce8d5d05494c96af Content-Type: text/plain; charset=UTF-8 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. 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. 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. -- Zhihao -- 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/CAGsORuCo0J-kCzikOHOBk34CrPY%3D%2BD_dgF8s1yZKwVgqnHhOUg%40mail.gmail.com. --001a114b4170ce8d5d05494c96af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Feb 24, 2017 12:53 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:

Now, I do recognize that this could potential= ly 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 instantia= tions a dependent function call returns prvalue and in some other instantia= tions the same code returns xvalue.=C2=A0 We don't want to break your i= nstantiations when they are valid, so we modeled __extend_me in a way givin= g pure gain without hard errors.

Also, by making it explicitly illegal t= o use it in such cases, we also make it so that users don't screw up li= ke this:

=
//Given a Type::getF= oo() 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 sile= ntly compiles.

By making that last statement e= xplicitly il-formed, we can prevent people from screwing that up. So while = they may be confused why `register Type().x` works when `register Type().ge= tX()` fails, at least the compiler tells them it won't do what they = think it does.

Compiler can choose to warn it anyway= ..

<= div>
Also, I thought of an interesting feature related to span: being ab= le to qualify function members such that, if a user uses a temporary with t= hat overload, then the temporary will automatically have its lifetime exten= ded 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 `co= nst&` parameters just like `&&` ones.

We consi= dered various "smart" approaches, and we chose to propose the dum= best one -- pure manual control.=C2=A0 Explained in the paper.

--
Zhihao

--
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/CAGsORuCo0J-k= CzikOHOBk34CrPY%3D%2BD_dgF8s1yZKwVgqnHhOUg%40mail.gmail.com.
--001a114b4170ce8d5d05494c96af-- .