220 11825 article Path: news.gmane.org!not-for-mail From: tomaszkam@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Thu, 10 Jul 2014 22:28:37 -0700 (PDT) Lines: 136 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="----=_Part_187_7527615.1405056517307" X-Trace: ger.gmane.org 1405056530 1135 80.91.229.3 (11 Jul 2014 05:28:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 05:28:50 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBBXM7WOQKGQEFY3BZMY@isocpp.org Fri Jul 11 07:28:43 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f197.google.com ([209.85.216.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5TNw-0000Dg-Fb for gclcip-std-proposals@m.gmane.org; Fri, 11 Jul 2014 07:28:40 +0200 Original-Received: by mail-qc0-f197.google.com with SMTP id i8sf2464887qcq.4 for ; Thu, 10 Jul 2014 22:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=ZxEOnDMFnmHb0O8OCrPiKj46yWOppm1WfoMP0oklctE=; b=l2pr/jw9Y3TAyXOWtlnEDg4dnV33Cch9F+Th4EWK93FFePtPc2RP8th9hliG6w2nbz x/1Wnxu8gMfhh8vk9ViWf0zpkRuY4PLOnWmx36eCLs/qz3RXtvjYRfPulPTxzQksxEK9 czQNsCdX4D1IeMwwI2EVlnLBBBrqz67lVkWv23xpHE4ZeRBcSwrNVzsZCWJREwsM8Njo XWfm4qhBOQc+/+xbBlfZLtLMiQ7QrWzkUyKShAISHAW+q6PI9CBn1m/m2KGHE36RK3fG GNWg7acyOHWfBpVJZrJUFvJuNJdQzaDtCvA3Zm2h5wS81E3GTBPkm/le88duyzONHi+A mwPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=ZxEOnDMFnmHb0O8OCrPiKj46yWOppm1WfoMP0oklctE=; b=GHcuIU0ouwPs1J+yQUMmfKsFYF3epv3KDZRHXeWNB+9bxTG92SR/gNh0lIuIYs62sD wam+ObR2hMT5qB/ZYNpYSzizzY33+CousA88zxWKIE/wYyYGzFvPz5xValUbRJgvD5zC YA+eJ88+2QBuJy/dMU0V6oi5Nrm6frc1jL9pIbIoaUzj62dCX1bSbxprqUm990kYUVi1 9v0dnZhnEAjXF9owecRsvxFTddXF+Ged14K4WutzKzGXD7I7GxSfGe9/mhg7SZfREm3e 3GHpWfWcyyv5bQBetcRV6idUBsn/AQ8RyndNnX03WtxPob25MbIw5S/Ljs/rqDVL45Tf w0GA== X-Gm-Message-State: ALoCoQk7ocVE5AtEY5tLnsLEGhOkctr/4u3pWeatR5yl6SRg7elsQlSN/V79OZN2xm2M6tljJhfM X-Received: by 10.236.202.43 with SMTP id c31mr22023778yho.25.1405056519695; Thu, 10 Jul 2014 22:28:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.129.84 with SMTP id nu20ls295078obb.31.gmail; Thu, 10 Jul 2014 22:28:38 -0700 (PDT) X-Received: by 10.182.40.233 with SMTP id a9mr116obl.36.1405056518144; Thu, 10 Jul 2014 22:28:38 -0700 (PDT) In-Reply-To: <4D3852AD-1AEB-44BA-941C-D645BAD19405@gmail.com> X-Original-Sender: tomaszkam@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:11825 Archived-At: ------=_Part_187_7527615.1405056517307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu pi=C4=85tek, 11 lipca 2014 00:59:12 UTC+2 u=C5=BCytkownik David Krau= ss napisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9311, at 6:19 AM, Ville Voutilainen > wrote: > > On 11 July 2014 01:01, David Krauss >=20 > wrote: > > What I meant is to return T const &, as in N3966, which precedes N4078.= =20 > The changelog in N4078 is wrong... as I said, churn. > > > T const &? So we could never move? > > > Sorry, first thing in the morning. Roll back to N3966, the preceding=20 > registered-paper revision. It has two value() overloads, just like=20 > container and smart pointer accessors. > > But I would like to ask for argument for removal of this additional=20 overload.=20 I we add the following r-value overload as originally proposed, it will=20 have following effect: //as always: optional f(); 1. *std::forward(u) with optional will actually perfectly forward=20 2. auto&& v =3D f().value() - will still create a dangling refence (as it= =20 it will now we two dangling reference), auto will be deduced to T instead= =20 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() =3D 20, will no longer compile if T has l-value qualified= =20 operator=3D(T const&) & //this actullay should be a true I found this actually being good not-breaking changes, similar to one=20 created my adding move constructor to every feasible class in C++11.=20 And even adding it to the single optional will not create any surprising=20 effect in the code I think adding such overloads to containers is actually possible, without= =20 breaking many code. Coud you please provide arguments, best corner cases, that makes you being= =20 against this change. I think they may get lost in this discussion because= =20 we are thinking that you are=20 recommending to have T value()&& instead of T&& value()&&, not removing it= =20 at all. --=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/. ------=_Part_187_7527615.1405056517307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


W dniu pi=C4=85tek, 11 lipca 2014 00:59:12 UTC+2 u= =C5=BCytkownik David Krauss napisa=C5=82:

On 2014=E2=80= =9307=E2=80=9311, at 6:19 AM, Ville Voutilainen <ville.vo...@gmail.com> wrote:

On 11 July 2014 01:01, David Krauss <pot...@gmail.com> wrote:
W= hat I meant is to return T const &, as in N3966, which precedes N4078. = The changelog in N4078 is wrong... as I said, churn.

T = const &? So we could never move?

So= rry, first thing in the morning. Roll back to N3966, the preceding register= ed-paper revision. It has two value() overloads, just like container and sm= art pointer accessors.


But I wou= ld like to ask for argument for removal of this additional overload.

 I we add the following r-value overload as originally proposed,= it will have following effect: //as always: optional<T> f();
&nbs= p; 1. *std::forward<U>(u) with optional will actually perfectly forwa= rd
  2. auto&& v =3D f().value() - will still create a dan= gling refence (as it it will now we two dangling reference), auto will be d= educed to T instead of T&, but v still we be l-value
  3. g(f.v= alue()), when g(const T&) accepts by cont& will work the same
&n= bsp; 4. h(f.value()), when h(T) accepts by value, will benefit from move  5. f().value() =3D 20, will no longer compile if T has l-value qual= ified operator=3D(T const&) & //this actullay should be a true
I= found this actually being good not-breaking changes, similar to one create= d 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 possibl= e, without breaking many code.

Coud you please provide arguments, be= st corner cases, that makes you being against this change. I think they may= get lost in this discussion because we are thinking that you are
recom= mending to have T value()&& instead of T&& value()&&= ;, not removing it at all.

--

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