220 31127 <77eaed66-1df2-4f01-9d94-375eb58b21dc@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 20:13:29 -0800 (PST) Lines: 145 Approved: news@gmane.org Message-ID: <77eaed66-1df2-4f01-9d94-375eb58b21dc@isocpp.org> References: <0f4944b0-11a6-4220-9d48-38086babc97a@isocpp.org> <2bde698e-c5be-4e20-bca0-d9fa0f90af12@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1826_1598525197.1487996009388" X-Trace: blaine.gmane.org 1487996012 3233 195.159.176.226 (25 Feb 2017 04:13:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Feb 2017 04:13:32 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB2UIYTCQKGQESHTE7QA@isocpp.org Sat Feb 25 05:13:27 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chTjZ-00006A-Mg for gclcip-std-proposals@m.gmane.org; Sat, 25 Feb 2017 05:13:25 +0100 Original-Received: by mail-pf0-f200.google.com with SMTP id u62sf7433399pfk.1 for ; Fri, 24 Feb 2017 20:13:31 -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=yUNL0RWGQqL9qbrtuvIgfd6EaEDbyZBUl7Rcn7Zb3L8=; b=ZsUds8Yw5tmnjq/vmNJEvKt7dJL5Y56WtHbg0yXueMNi7AfntRVQ3Jx7zUyJHL4jwA nqmYBfTfJtFYTf0p9G6AyDWpDjS00mtY+/NUM31QzVnI8/fljfMbuoQiY2tRNDJ9zniL P37LF97swFXLU+WeNPlyYNONkpuf+RqXEN4R1LZbKipBvPkO0Lv2xSGUH1tJTkkse+cA j/UyvEWDZWqH7wFZcXEq1KJVaD9eBpqQfMMTdeo2BU/VK37PzHjtbCKjHI+UVq1+U7OC Gv+tE4EqZMsvVqDoveMlQ3XXIWG31Q3X7Sdp1KJ67Kypu7UwZHGZp1mk8edGO9T1pSqr px8Q== 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=yUNL0RWGQqL9qbrtuvIgfd6EaEDbyZBUl7Rcn7Zb3L8=; b=s4IF86sni/6Ccbvkvako3XGy36RnDgZq7f3VrPy/nzHMJ6+B6pO5QyYmt6AcWrtYL/ VEG92As/8VFyrrA+U00NrKSJnoxT53Vx6tSOjO2dL8rwXVCuas+CLCoZXxfG94swfnGb vH486CV1qe9Fw4NIITNLZH0DVm6ki025igr7iyZ4IJCHv7p4x/Gz3CBssvanoByW5BUv GR4eZhPPlE9dQR5h0W/i3ukeIM3YtPLXrWeMC0wKWL0wCJSAq7Oq4l5AtdQpM5jgK/77 99G4qSWS4ypd2Y2FwboBhwyMOF3xpEwrPJv1L9SV2eaAp8EXjedr6wm3HbYFA0H1mJPp GoLQ== 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=yUNL0RWGQqL9qbrtuvIgfd6EaEDbyZBUl7Rcn7Zb3L8=; b=uDpgokAv8B2ghV2YSdVWiAN7UQEQ9nfQioxD7IYVtTBPXoDJhAXoxcHCgd/Sk/w+ya bNPRF0NDrXJ0jJZCmfO14CQVaqybeb3Sjcv/a4LTxacYgIqW+URm+5mfooA210sBrF5T 4MIs+BlbVj4av9H/Wtt3K4T2sb4XGERP575HhF0XIhnUBu0d0gzV3nsPnZh7sgzfoOLs aBi+HHrnM/Vl8Zc8m+SQjOelDoWcJy5yBSx0qbZWjL/JRHxji8UaX95laIVRTb2ge7HT gsP3jsh1o/nN82SALCsPfJvCdym1baltRz5JI2RRCKrfynV5/RW3IhD2ZT3zmRlwRQoK QqfQ== X-Gm-Message-State: AMke39mv4tLMtQUTbbMGz5O2rmplIE1ZK8R72748crgRLe2VDSBS3vD8Tt0txwRn+TaHnw== X-Received: by 10.99.146.15 with SMTP id o15mr2112109pgd.8.1487996011031; Fri, 24 Feb 2017 20:13:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.29.200 with SMTP id w8ls8514727otw.23.gmail; Fri, 24 Feb 2017 20:13:30 -0800 (PST) X-Received: by 10.157.82.86 with SMTP id q22mr458482otg.3.1487996010374; Fri, 24 Feb 2017 20:13:30 -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:31127 Archived-At: ------=_Part_1826_1598525197.1487996009388 Content-Type: multipart/alternative; boundary="----=_Part_1827_780484860.1487996009389" ------=_Part_1827_780484860.1487996009389 Content-Type: text/plain; charset=UTF-8 On Friday, February 24, 2017 at 6:00:38 PM UTC-5, Zhihao Yuan wrote: > > On Fri, Feb 24, 2017 at 4:04 PM, Nicol Bolas > wrote: > > 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. > > auto&& binds to everything so of course x4 works. > Grr. Stupid forwarding references. Consider it amended to use the appropriate typenames then. My point was to focus on the fact that lvalues don't bind to rvalue references, and how using `register` would extend a temporary's lifetime, yet cannot be relied upon to provide a consistent value category. In one case it's an lvalue, in another it's an xvalue. > > > 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. > > But you may also noticed that std::move never moves > const and we didn't make that into an error. Move over, > it copies. `std::move` never moves *anything*; it's just a cast. And `std::move` never guarantees movement, since copying is valid move behavior. So I'm not sure I see the inconsistency there. > Good or bad, sometimes concerns with > generic programming out weight getting benefits in other > ways -- especially when we are not making the situation > any worse. > I don't understand your reasoning. You say there are concerns with generic programming. But at this point, these concerns are entirely imaginary; there has been no demonstration that real, legitimate code would be unable to use this correctly. And if the purpose of this feature is to fix the temporary lifetime extension problem, making a feature that still allows that problem to manifest very easily (by putting `register` in what is undeniably the wrong place) seems to not exactly be fixing the problem. Nor is relying on compiler warnings (which are things compilers can already detect in most cases); Quality of Implementation should be something you rely on as a *last* resort, not to correct flaws in a proposal. -- 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/77eaed66-1df2-4f01-9d94-375eb58b21dc%40isocpp.org. ------=_Part_1827_780484860.1487996009389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, February 24, 2017 at 6:00:38 PM UTC-5, Zhihao Y= uan wrote:
On Fri, Feb 24, 2017= at 4:04 PM, Nicol Bolas <jmck...@gmail.com> wrote:
> auto &&x1 =3D X().s; //This works.
> auto &&x2 =3D X(); //This works.
>
> auto &&x3 =3D register X().s; //This works.
> auto &&x4 =3D register X(); //This doesn't work.

auto&& binds to everything so of course x4 works.

Grr. Stupid forwarding references. Consider it amended to use t= he appropriate typenames then. My point was to focus on the fact that lvalu= es don't bind to rvalue references, and how using `register` would exte= nd a temporary's lifetime, yet cannot be relied upon to provide a consi= stent value category. In one case it's an lvalue, in another it's a= n xvalue.

>
> 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= ..

But you may also noticed that std::move never moves
const and we didn't make that into an error. Move over,
it copies.

`std::move` never moves anything= ; it's just a cast. And `std::move` never guarantees movement, since co= pying is valid move behavior. So I'm not sure I see the inconsistency t= here.
=C2=A0
Good or b= ad, sometimes concerns with
generic programming out weight getting benefits in other
ways -- especially when we are not making the situation
any worse.

I don't understand your reasoni= ng. You say there are concerns with generic programming. But at this point,= these concerns are entirely imaginary; there has been no demonstration tha= t real, legitimate code would be unable to use this correctly.

And i= f the purpose of this feature is to fix the temporary lifetime extension pr= oblem, making a feature that still allows that problem to manifest very eas= ily (by putting `register` in what is undeniably the wrong place) seems to = not exactly be fixing the problem. Nor is relying on compiler warnings (whi= ch are things compilers can already detect in most cases); Quality of Imple= mentation should be something you rely on as a last resort, not to c= orrect flaws in a proposal.

--
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/77eaed66-1df2-4f01-9d94-375eb58b21dc= %40isocpp.org.
------=_Part_1827_780484860.1487996009389-- ------=_Part_1826_1598525197.1487996009388-- .