220 11810 <096f0ea4-9e8d-4a08-98eb-af856ace1c1b@isocpp.org> 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 08:18:34 -0700 (PDT) Lines: 179 Approved: news@gmane.org Message-ID: <096f0ea4-9e8d-4a08-98eb-af856ace1c1b@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_303_17011130.1405005514834" X-Trace: ger.gmane.org 1405005536 5900 80.91.229.3 (10 Jul 2014 15:18:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 15:18:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBS657KOQKGQE5P5N3OY@isocpp.org Thu Jul 10 17:18:51 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5G7J-0006c7-KQ for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 17:18:37 +0200 Original-Received: by mail-ie0-f200.google.com with SMTP id at20sf2412663iec.7 for ; Thu, 10 Jul 2014 08:18:36 -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=6CkDbNwCbyo4Fg4p0ZikdB98lDoJ1D4aiNKAlNodT3I=; b=dy1f85ur8B/bG//6OeDPOlm67HT6NM6xsXIjGRoGaB57QmujcKkOsNGvoza5vJChoF NaEU1/ooIZOLkKcHswGp3xQasV4vQuf1mZ7h/dHdZy0xX/WMwg4tUjfgTk5galjJ01uN 8Z8AcxpkoLOsWZzrZIPSaNkEe0X52nOsqcaksbw92A9tl3MAeQDl1mZv//Sz14bdlegh wKdKZedyGvbfACeYLgAcU0FOyUSe8lNz+y4Oo7YqiWgXayVb8wJC/f3BTs15kgrIRUbi jPwCN4hGftTzFHW6VZ9nAJ1NojwEzXfc9RNXMLQZbN2vfmrTUs1rSnoiMW1ST4oSatAe qRug== 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=6CkDbNwCbyo4Fg4p0ZikdB98lDoJ1D4aiNKAlNodT3I=; b=O7puw4txl+7z9a6vlY5pzfPGku0X/RSlsZoKR2u4KpLufnzqxjbNy6ApgWhRxwBDx7 bwI3VjMy9oySMNduvyZ3UWTl43RBriu31Cyozn5KKTzZPbbsfFpzVATGU1mcMJDxBVU2 JLkhPV7HGSyvenwjfmbukTgbwFgF0ZaxtzwXYHLVBVQOVMDlp7A15SwAqdCb0gXUD0n8 PM5aW0xL6wwjmsdCVAp1pe2zkxIbFXmzKI3cBR31rcO05fNvvHpbM1mekgaILZHcAQFB W94q6ZChQT22TJbflHpg+3Txt/1g9Sbu84wG8/CicPK7rk4xTRfKC+jdUmcC6P6gq5ni Zxew== X-Gm-Message-State: ALoCoQmLfoRGc1VKmpOGAaFrp40c6XlM1e20vh6FfvjW9QjHHHFtdwwIKkXKu0lp2Ge5cNLH6hSl X-Received: by 10.43.92.195 with SMTP id br3mr22800881icc.1.1405005516710; Thu, 10 Jul 2014 08:18:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.111.130 with SMTP id ii2ls123631obb.3.gmail; Thu, 10 Jul 2014 08:18:35 -0700 (PDT) X-Received: by 10.182.28.71 with SMTP id z7mr152006obg.16.1405005515620; Thu, 10 Jul 2014 08:18:35 -0700 (PDT) In-Reply-To: <335948E6-8140-4673-B958-930356A52070@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:11810 Archived-At: ------=_Part_303_17011130.1405005514834 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu czwartek, 10 lipca 2014 16:58:41 UTC+2 u=C5=BCytkownik David Krauss= =20 napisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9310, at 10:44 PM, Ville Voutilainen > wrote: > > On 10 July 2014 17:24, David Krauss >=20 > wrote: > > A return-by-reference from a non-ref-discriminated accessor devolving to > return-by-copy would regress legacy code, but that doesn=E2=80=99t make s= uch=20 > library > behavior semantically sound from a modern point of view. > > > The "modern point of view" should include the forwarding concerns, which > are not limited to the performance of emplace. > > > Absolutely. I=E2=80=99m have an interest in this because I write this kin= d of code. > > The rvalue-ref-qualified signatures need to return T&& instead of T. > LEWG needs an NB comment > to be able to make that fix for Fundamentals v1, and I'm going to provide > them > with one. > > > The rvalue-ref-qualified signatures of what, std::optional? That=E2=80=99= s not a > > > Uh.. yes. That's the topic of this thread. > > > Maybe I don=E2=80=99t understand the standardization process, but wouldn= =E2=80=99t the=20 > conservative solution be to simply roll that back from N4078, so optional= =20 > behaves the same as everything else? Adding a new feature in a particular= =20 > way doesn=E2=80=99t fall into the category of legacy support. > > Optional is attempting to be the most perfect proxy class ever designed,= =20 > and it=E2=80=99s pushing the envelope in a way that fundamentally disagre= es with=20 > standardization. Simply put, it=E2=80=99s churning too much. > > The debate can=E2=80=99t be just about optional, even just in this thread= ,=20 > because the rest of the library is going to have to follow suit. > But having it in the optional will create and existing practice will=20 make it easier to get the proposal that r-value overloads for other STL=20 container to get accepted. And maybe then we would have a full=20 implementation of this pattern in library. But without stepping stone like= =20 optional it would be nearly impossible. The history in short: Firstly the following paper get published as part of 2014-05 mailing:=20 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3982.html. It adds= =20 following overloads for the value and operator*: T& value() &; T const& value() const &; T&& value() &&; And I really supported like that idea, because it makes the programmer life= =20 easier. But then the https://isocpp.org/files/papers/N4078.html following= =20 paper come out in 2014-07 mailing and it adds following overloads: T& value() &; T const& value() const &; T value() &&; T value() const &&; And Anna started a thread raising an issues with this change. I hope that= =20 clears up a think for you. =20 --=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_303_17011130.1405005514834 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


W dniu czwartek, 10 lipca 2014 16:58:41 UTC+2 u=C5= =BCytkownik David Krauss napisa=C5=82:

On 2014=E2=80=930= 7=E2=80=9310, at 10:44 PM, Ville Voutilainen <ville.vo...@gmail.com> wrote:

On 10 July 2014 17:24, David Krauss <pot...@gmail.com> wrote:
A = return-by-reference from a non-ref-discriminated accessor devolving to
r= eturn-by-copy would regress legacy code, but that doesn=E2=80=99t make such= library
behavior semantically sound from a modern point of view.

The "modern point of view" should include the forwarding conc= erns, which
are not limited to the performance of emplace.

Absolutely. I=E2=80=99m have an interest in this bec= ause I write this kind of code.

The rvalue-ref-qualified signatures need to return T&= & instead of T.
LEWG needs an NB comment
to be able to make that = fix for Fundamentals v1, and I'm going to provide
them
with one.
<= br>
The rvalue-ref-qualified signatures of what, std::optional? That=E2= =80=99s not a

Uh.. yes. That's the topic of this thread= ..

Maybe I don=E2=80=99t understand the= standardization process, but wouldn=E2=80=99t the conservative solution be= to simply roll that back from N4078, so optional behaves the same as every= thing else? Adding a new feature in a particular way doesn=E2=80=99t fall i= nto the category of legacy support.

Optional is attempti= ng to be the most perfect proxy class ever designed, and it=E2=80=99s pushi= ng the envelope in a way that fundamentally disagrees with standardization.= Simply put, it=E2=80=99s churning too much.

The d= ebate can=E2=80=99t be just about optional, e= ven just in this thread, because the rest of the library is going to have t= o follow suit.

But having it in the option= al<T> will create and existing practice will make it easier to get th= e proposal that r-value overloads for other STL container to get accepted. = And maybe then we would have a full implementation of this pattern in libra= ry. But without stepping stone like optional it would be nearly impossible.=

The history in short:
Firstly the following paper get published = as part of 2014-05 mailing: http://www.open-std.org/jtc1/sc22/wg21/docs/pap= ers/2014/n3982.html. It adds following overloads for the value and operator= *:
  T& value() &;
  T const& value() const &a= mp;;
  T&& value() &&;
And I really supported li= ke that idea, because it makes the programmer life easier. But then the htt= ps://isocpp.org/files/papers/N4078.html following paper come out in 2014-07= mailing and it adds following overloads:
  T& value() &;<= br>  T const& value() const &;
  T value() &&;=
  T value() const &&;
And Anna started a thread raising= an issues with this change. I hope that clears up a think for you.
 

--

---
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_303_17011130.1405005514834-- .