220 11891 <6CFC366C-D196-4A2E-B4EE-D1E6B26AE6C0@gmail.com> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Sat, 12 Jul 2014 19:14:27 +0800 Lines: 169 Approved: news@gmane.org Message-ID: <6CFC366C-D196-4A2E-B4EE-D1E6B26AE6C0@gmail.com> References: <4DA018C3-2327-4F55-B7F8-7988EC7B789A@gmail.com> <1a858a77-310b-4591-aaf5-960c40d9f5fc@isocpp.org> <66AF41C1-CB37-4311-98EA-D47DBC6068DC@gmail.com> <66c38b61-7a95-4ace-b34f-2346bb334fb9@isocpp.org> <6F4B3C72-9962-48DC-8527-0C89EA1B9710@gmail.com> <35873CE5-ED8C-4C03-A6A1-E4132DECD91F@gmail.com> <335948E6-8140-4673-B958-930356A52070@gmail.com> <76ACA175-5A44-4BE8-B49F-BAC6DA65E6B1@gmail.com> <4D3852AD-1AEB-44BA-941C-D645BAD19405@gmail.com> <6a4b6425-1167-40c1-acd8-3945c8cd4c74@isocpp.org> <13DD0D7A-A146-4667-9F30-6FB3739CDBE0@gmail.com> <6B925FF7-2940-44C7-BF1D-13209A703BA2@gmail.com> <944C9C01-865B-4215-8C91-95F01AEA256E@gmail.com> <8DC3E474-3957-40B2-B492-D4AF2FDDD451@gmail.com> <0ACAE525-4FB2-4932-BBD2-F0623C4EBBFB@gmail.com> <52187852-ff8e-4e59-a8cf-7a29fd0a405b@isocpp.org> <8209A2E9-D947-4C00-A1F3-38F5676A4E52@gmail.com> <4c42f7c9-0588-4ab9-9af5-b2e692513993@isocpp.org> <225BBAAC-B3FA-4014-9FB6-64C48DF4208E@gmail.com> <1b70888c-eb6a-49e5-b254-a475ef015570@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_A140FED6-ED88-4EAA-B521-AB8B212D20B8" X-Trace: ger.gmane.org 1405163707 28317 80.91.229.3 (12 Jul 2014 11:15:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 11:15:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBMFRQSPAKGQEH56F5JI@isocpp.org Sat Jul 12 13:15:00 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5vGc-0000aR-ED for gclcip-std-proposals@m.gmane.org; Sat, 12 Jul 2014 13:14:58 +0200 Original-Received: by mail-ob0-f197.google.com with SMTP id vb8sf2636778obc.8 for ; Sat, 12 Jul 2014 04:14:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=lkS/dAqZvAkhkj3rx2FKm2KZ7phdnkJZNke3dW0ciQ0=; b=NN5uyMR2rf9wK9OOlUCSPTYaZQAm8Q50UPfinAm6e5DPXWecuFhLwvIcPLeEKqbbK/ fA74ZMxKkovYG4QpVAs6adl+s64gU4rWvWE7yWsacznxf+a85IDyuo+oganmVPpCh6Ri heWpfO1t4v0d5AzGPqGTazOUkMU82TtS/QPuy2F5dZQbD2Hyyf3xUeMkUGlViH/15Jf7 OhZx9gaiSPBr+5KpKt9eppjbCWbfHldgjvjeMaaOrmLhaZ2lbv9pqsTbuTl31gCIb/Tt 3mJKj/jwu/71AjazDtx7/LPS2aoRmxmnjmf9iVrs7QSenhmoQb2fkvtIV/4GoDai6HG5 pbrA== X-Gm-Message-State: ALoCoQmkEFWyRi+6dIqIuoDSFgWw2blK+zFQFzgnkFEQmmH0VMKpdiqYUpBeNckLLLEbpudwx7/n X-Received: by 10.182.102.34 with SMTP id fl2mr2418570obb.16.1405163697212; Sat, 12 Jul 2014 04:14:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.117.7 with SMTP id ka7ls784913igb.32.gmail; Sat, 12 Jul 2014 04:14:56 -0700 (PDT) X-Received: by 10.50.137.73 with SMTP id qg9mr11366482igb.19.1405163696427; Sat, 12 Jul 2014 04:14:56 -0700 (PDT) Original-Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [2607:f8b0:4001:c03::22e]) by mx.google.com with ESMTPS id h11si9721315icl.65.2014.07.12.04.14.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 04:14:56 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::22e as permitted sender) client-ip=2607:f8b0:4001:c03::22e; Original-Received: by mail-ie0-f174.google.com with SMTP id rd18so1740492iec.5 for ; Sat, 12 Jul 2014 04:14:56 -0700 (PDT) X-Received: by 10.42.12.76 with SMTP id x12mr23528icx.96.1405163696309; Sat, 12 Jul 2014 04:14:56 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.44]) by mx.google.com with ESMTPSA id lo3sm4689369igb.22.2014.07.12.04.14.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 04:14:55 -0700 (PDT) In-Reply-To: <1b70888c-eb6a-49e5-b254-a475ef015570@isocpp.org> X-Mailer: Apple Mail (2.1878.6) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::22e as permitted sender) smtp.mail=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:11891 Archived-At: --Apple-Mail=_A140FED6-ED88-4EAA-B521-AB8B212D20B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-07-12, at 5:10 PM, tomaszkam@gmail.com wrote: > 3. Value r-value overload for operator[]: In the decltype(auto) get_fif= th_thing(container_handle && ch) theauto && fifth_thing =3D=3D ( * std::for= ward< container_handle >( ch ) )[ 5 ]; will cause fifth_thing to be type of > T&&, meaning the return type of function will be reference and that= will cause auto && fifth_thing =3Dget_fifth_thing(std::forward< container_= handle >( ch)) to be a dangling reference. The code will be broken by this = transormation. Actually, the program is ill-formed because the name fifth_thing is an lval= ue and it will not bind to the returned rvalue reference. If it were change= d to std::forward< decltype( fifth_thing ) >( fifth_thing ), then your argu= ment holds, but that's not realistically intuitive. If the problem is inste= ad fixed by changing the return type to auto (since only special move and f= orward functions should return xvalues) then my argument holds, but then th= e user gets one or two copies (only zero or one if they think to std::move(= fifth_thing )). This interaction between decltype(auto) and a named rvalue reference sounds= like fodder for a core DR. It's nasty regardless of library policies, and = considering that a diagnostic is already required, it's fixable. The safe s= olution, considering the possibility of a bound temporary, is to deduce a n= on-reference type (return a prvalue), and if the user wants to return an xv= alue, they should write return std::forward(...). I'm also tempted to say t= hat returning the name of an rvalue reference should be a copy elision case= , but this needs further study. (I'm out on a limb, but given these two res= olutions, then the code would work perfectly.) Aside from named rvalue references, a policy of prvalue accessors will indu= ce decltype(auto) to return by prvalue as well. > Breaking the connection between lifetime of object and lifetime of expres= sion that should reference for subobject is not good think. The question is whether or not to reference a subobject of an xvalue at all= .. An xvalue is usually assumed to be invalidated by the first thing to happ= en to it, usually any time between getting bound to a parameter and the sem= icolon. Once it's passed, we don't care what happens to it. Subobjects/comp= onents of xvalues devolving to prvalues preserves this rule, because there = is never an actual reference to a subobject in the first place. > My personal opinion: >=20 > The only argument for T value()&& presented in this tread was that it w= ill make auto&& cs =3D f().value() work, but will cause performance downgra= de in other parts of code, Maybe this is what came through the presentation of examples, but the core = argument is the principle that an xvalue is dead (and reusable) once it goe= s into any function. I don't think libraries scale well with any other rule= , although functions that "only" perform access do intuitively seem special= .. --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --Apple-Mail=_A140FED6-ED88-4EAA-B521-AB8B212D20B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 2014&= ndash;07–12, at 5:10 PM, tomas= zkam@gmail.com wrote:

  = 3. Value r-value overload for operator[]: In the decltype(auto) get_fifth_thing(container_handle && ch) theauto && fifth_thing =3D=3D ( * std:= :forward< container_handle >( ch ) )[ 5 ]; will cause fifth_thing to be type of
&nbs= p;     T&&, meaning the return type of function= will be reference and that will cause auto && fifth_thing =3D= get_fifth_thing(std::forward< = container_handle >( ch))&nb= sp;to be a dangling reference. The code will be broken by this trans= ormation.

Actually, t= he program is ill-formed because the name fifth= _thing is an lvalue and it will not bind to the returned rvalue refe= rence. If it were changed to std::forward< declty= pe( fifth_thing ) >( fifth_thing ), then your argument holds, but= that’s not realistically intuitive. If the problem is instead fixed = by changing the return type to auto = ;(since only special move and = forward functions should return xvalues)= then my argument holds, but then the user gets one or two copies (only zer= o or one if they think to std::move( fifth_thing )).

This interaction between decltype(auto) and a named rvalue reference sounds like fodder= for a core DR. It’s nasty regardless of library policies, and consid= ering that a diagnostic is already required, it’s fixable. The safe s= olution, considering the possibility of a bound temporary, is to deduce a n= on-reference type (return a prvalue), and if the user wants to return an xv= alue, they should write return std::forward(…= ). I’m also tempted to say that returning the name of an rvalu= e reference should be a copy elision case, but this needs further study. (I= ’m out on a limb, but given these two resolutions, then the code woul= d work perfectly.)

Aside from named rvalue referen= ces, a policy of prvalue accessors will induce declt= ype(auto) to return by prvalue as well.

Breaking th= e connection between lifetime of object and lifetime of expression that sho= uld reference for subobject is not good think.

The question is whether or not to reference a sub= object of an xvalue at all. An xvalue is usually assumed to be invalidated = by the first thing to happen to it, usually any time between getting bound = to a parameter and the semicolon. Once it’s passed, we don’t ca= re what happens to it. Subobjects/components of xvalues devolving to prvalu= es preserves this rule, because there is never an actual reference to a sub= object in the first place.

My personal opinion:

&nb= sp; The only argument for T value()&& presented in this tread was t= hat it will make auto&& cs =3D f().value() work, but will cause per= formance downgrade in other parts of code,
<= div>
Maybe this is what came through the presentation of exam= ples, but the core argument is the principle that an xvalue is dead (and re= usable) once it goes into any function. I don’t think libraries scale= well with any other rule, although functions that “only” perfo= rm access do intuitively seem special.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--Apple-Mail=_A140FED6-ED88-4EAA-B521-AB8B212D20B8-- .