220 11833 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Tomasz_Kami=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Fri, 11 Jul 2014 09:49:47 +0200 Lines: 185 Approved: news@gmane.org Message-ID: 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5da0937fec0104fde62f14 X-Trace: ger.gmane.org 1405065001 27460 80.91.229.3 (11 Jul 2014 07:50:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 07:50:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBHFO72OQKGQEOD6WBRI@isocpp.org Fri Jul 11 09:49:54 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 1X5VaY-0003AL-Hg for gclcip-std-proposals@m.gmane.org; Fri, 11 Jul 2014 09:49:50 +0200 Original-Received: by mail-ob0-f197.google.com with SMTP id uz6sf3767442obc.4 for ; Fri, 11 Jul 2014 00:49:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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=SPXr7cJrh9PpdWclBfzhzlhVmn7o6rS9iAsV1qO+pV4=; b=bVmCi3wKyRwq1hHGXJH1jQdHbxbMstyczz5VgOPbI9MAx3bk7pUS64KjzgGhRFVJF9 GIpPo2HeEw4+DV4wSHjPfvKBxxznaH0fVaeyyxXhC52wZxH8HlmwXX7zX3busZV9hLHS SeDu87SrXOhIVuSLWTzbCMLECGBKoQxlxYAubnYYFDjJxzfEDYSnd0CE5amf3USHOCMA lPaT6B2X7YXISs0uPqTcav1HvIms7Iis665uvxl0KFV+w3fZs52+KVlYvZpmZm9c7p3y uRuA1mDpLY/IOEFc2Gg2LsnO+WXHL8UpXG6HSuF65NA4Bs0It8plpxxvYKchT25EN6BS 31fA== X-Gm-Message-State: ALoCoQn86+qSLmbkcdyGWv/5AeAp+xbFdoIvTKHBDo/Rqd/zG4BTJ9tEJNDTWbYDLh5HilnIHZbs X-Received: by 10.42.235.132 with SMTP id kg4mr1331225icb.22.1405064989450; Fri, 11 Jul 2014 00:49:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.20.238 with SMTP id q14ls320120obe.85.gmail; Fri, 11 Jul 2014 00:49:48 -0700 (PDT) X-Received: by 10.182.98.194 with SMTP id ek2mr59546913obb.5.1405064988265; Fri, 11 Jul 2014 00:49:48 -0700 (PDT) Original-Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [2607:f8b0:4003:c01::22d]) by mx.google.com with ESMTPS id o4si2623024obi.87.2014.07.11.00.49.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 00:49:48 -0700 (PDT) Received-SPF: pass (google.com: domain of tomaszkam@gmail.com designates 2607:f8b0:4003:c01::22d as permitted sender) client-ip=2607:f8b0:4003:c01::22d; Original-Received: by mail-ob0-f173.google.com with SMTP id vb8so506689obc.32 for ; Fri, 11 Jul 2014 00:49:48 -0700 (PDT) X-Received: by 10.60.63.195 with SMTP id i3mr32900713oes.76.1405064988059; Fri, 11 Jul 2014 00:49:48 -0700 (PDT) Original-Received: by 10.202.214.4 with HTTP; Fri, 11 Jul 2014 00:49:47 -0700 (PDT) In-Reply-To: X-Original-Sender: tomaszkam@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tomaszkam@gmail.com designates 2607:f8b0:4003:c01::22d as permitted sender) smtp.mail=tomaszkam@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:11833 Archived-At: --047d7b5da0937fec0104fde62f14 Content-Type: text/plain; charset=UTF-8 You mean that: T const&& value() const&&; I see no additional problem with adding that. Not uses case come to my mind at this moment, but I am pretty sure that someone will found one. I thin we should think of some kind of defininig template for this specializations U _member; I would propose: template //real type of object (example T const& for cons& funtion delctype(auto) member() { return std::forward>(_member); }; //cv ref deduced\ template //real type of object delctype(auto) member() const { return std::forward>(_member); }; //ref deduced, const specified template //real type of object delctype(auto) member() & { return std::forward>(_member); }; //cv deduced, ref specified template //real type of object delctype(auto) member() cont & { return std::forward>(_member); }; //eror, not think to dedupe 2014-07-11 9:35 GMT+02:00 Ville Voutilainen : > On 11 July 2014 08:28, wrote: > > I we add the following r-value overload as originally proposed, it will > > have following effect: //as always: optional f(); > > 1. *std::forward(u) with optional will actually perfectly forward > > 2. auto&& v = f().value() - will still create a dangling refence (as > it it > > will now we two dangling reference), auto will be deduced to T instead of > > T&, but v still we be l-value > > 3. g(f.value()), when g(const T&) accepts by cont& will work the same > > 4. h(f.value()), when h(T) accepts by value, will benefit from move > > 5. f().value() = 20, will no longer compile if T has l-value qualified > > operator=(T const&) & //this actullay should be a true > > I found this actually being good not-breaking changes, similar to one > > created my adding move constructor to every feasible class in C++11. > > And even adding it to the single optional will not create any surprising > > effect in the code > > I think adding such overloads to containers is actually possible, without > > breaking many code. > > > I think we should do what N3982 does with the addition of > const-rvalue-ref-qualified > overloads. With the addition of those, people who care about > forwarding const-rvalues > perfectly will get what they need. > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q/unsubscribe > . > To unsubscribe from this group and all its topics, send an email 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-proposals/. > -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7b5da0937fec0104fde62f14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You mean that:
=C2=A0 T const= && value() const&&;
I see no additional problem wi= th adding that. Not uses case come to my mind at this moment, but I am pret= ty sure that someone will found one.

=C2=A0I thin we should think of some kind of defininig template for thi= s specializations
=C2=A0U _member;

= =C2=A0I would propose:
=C2=A0template<this T> //real ty= pe of object (example T const& for cons& funtion
=C2=A0delctype(auto) member() { return std::forward<same_cv_as<= T, U>>(_member); }; //cv ref deduced\

=C2=A0template<t= his T> //real type of object
=C2=A0delctype(auto) member()=C2= =A0 const { return std::forward<same_cv_as<T, U>>(_member); }; = //ref deduced, const specified

=C2=A0template<this T> //real type of object
=C2=A0= delctype(auto) member()=C2=A0 & { return std::forward<same_cv_as<= T, U>>(_member); }; //cv deduced, ref specified

=C2=A0tem= plate<this T> //real type of object
=C2=A0delctype(auto) member()=C2=A0 cont & { return std::forward&= lt;same_cv_as<T, U>>(_member); }; //eror, not think to dedupe
<= /div>


2014-07-= 11 9:35 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com= >:
On 11 July 2014 08:28, =C2= =A0<tomaszkam@gmail.com> w= rote:
> =C2=A0I we add the following r-value overload as originally proposed, = it will
> have following effect: //as always: optional<T> f();
> =C2=A0 1. *std::forward<U>(u) with optional will actually perfec= tly forward
> =C2=A0 2. auto&& v =3D f().value() - will still create a dangl= ing refence (as it it
> will now we two dangling reference), auto will be deduced to T instead= of
> T&, but v still we be l-value
> =C2=A0 3. g(f.value()), when g(const T&) accepts by cont& will= work the same
> =C2=A0 4. h(f.value()), when h(T) accepts by value, will benefit from = move
> =C2=A0 5. f().value() =3D 20, will no longer compile if T has l-value = qualified
> operator=3D(T const&) & //this actullay should be a true
> I found this actually being good not-breaking changes, similar to one<= br> > created my adding move constructor to every feasible class in C++11. > And even adding it to the single optional will not create any surprisi= ng
> effect in the code
> I think adding such overloads to containers is actually possible, with= out
> breaking many code.


I think we should do what N3982 does with the addition of
const-rvalue-ref-qualified
=C2=A0overloads. With the addition of those, people who care about
forwarding const-rvalues
perfectly will get what they need.

--

---
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscrib= e@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/gro= up/std-proposals/.

--

---
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>.
--047d7b5da0937fec0104fde62f14-- .