220 11809 <335948E6-8140-4673-B958-930356A52070@gmail.com> article
Path: news.gmane.org!not-for-mail
From: David Krauss <potswa@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:58:26 +0800
Lines: 108
Approved: news@gmane.org
Message-ID: <335948E6-8140-4673-B958-930356A52070@gmail.com>
References: <b538efba-faf4-4ffc-a553-302b9d2ba2c0@isocpp.org>
 <CANh-dX=M7niArNp-1sCcqxaREEJSxmjMftgw7uMHN9YnZC-h+w@mail.gmail.com>
 <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>
 <F1CBA358-0AD8-4ADD-99DA-6D00FCFE150F@gmail.com> <CAFk2RUZENmaMW5NwBaiF6byfhgRyPUsSmuyVjnRDhbjcfaTtQA@mail.gmail.com>
 <CC03CC1C-8487-40C8-97DF-2CA7661DAD55@gmail.com> <CAFk2RUa7-WTcL=XFYO8KMyU4rdpjDEfFM6n6SkUZ=SW_U7s5XQ@mail.gmail.com>
 <EF930317-EB97-402E-A3A0-CC46E7E2D998@gmail.com> <CAFk2RUZigiwLwFpfVXuFS8cqy38hPG3OGhGUi+iNwSYuYvyAyQ@mail.gmail.com>
 <A46ADDB4-C9B0-4163-81BE-900CD879D8C8@gmail.com> <CAFk2RUZ-DqEcMeehjH8KedYgErxKMq4O9kmeN4FZzjkXMYSsiw@mail.gmail.com>
 <6F4B3C72-9962-48DC-8527-0C89EA1B9710@gmail.com> <CAFk2RUb5xynaoQx-j4cQuXC8t-0GGc9-CZyRA2V=j6cfuNQV=g@mail.gmail.com>
 <35873CE5-ED8C-4C03-A6A1-E4132DECD91F@gmail.com> <CAFk2RUYRJSNcXykj9oPd=3EehSozf7PcX8ACM_hrqhK+Ur2V8A@mail.gmail.com>
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=_36C7DCE8-AF9A-4998-B313-76D861386C7E"
X-Trace: ger.gmane.org 1405004331 22686 80.91.229.3 (10 Jul 2014 14:58:51 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 10 Jul 2014 14:58:51 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCW25A7E3QCRBIGU7KOQKGQEV4BGRLY@isocpp.org Thu Jul 10 16:58:43 2014
Return-path: <std-proposals+bncBCW25A7E3QCRBIGU7KOQKGQEV4BGRLY@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-qc0-f198.google.com ([209.85.216.198])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCW25A7E3QCRBIGU7KOQKGQEV4BGRLY@isocpp.org>)
	id 1X5Fo2-0004kS-4H
	for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 16:58:42 +0200
Original-Received: by mail-qc0-f198.google.com with SMTP id m20sf30853678qcx.9
        for <gclcip-std-proposals@m.gmane.org>; Thu, 10 Jul 2014 07:58:41 -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=VM6yw2RWArBSsoimp1Dmvj+cwfQwIamjiUl0gsRfEBI=;
        b=AptmgQQfSF5SSpcxc2I9RNfr70J7fa3b+GZPqYAnDiU1a/tbPtrUQX7lmJmOiqZvLg
         Eqp9+pYXTS4yVSVYaAPdwqqNae4JNDz3b3p1/laSOYAAv8OHXR2cMi+jBvKjSouau83O
         Qck0QN6jsRWHHDmJV3nuEq43eZ5LzE20kfI2OSm1mmxk1lC3RoN0HJ9RJ0qtr+DK5nax
         WDVVED1y8X/HCU2uSitdAWfkY3uwpcsO6iLtqxcRZ0obavu8fOpRfYHFlw8oRL8SecuJ
         KL7eiAKa8UPbrbjCQIB8Tc2uFzONpqu+XeqnMBjM/MIy9N73gyBtJHcxdyy4VHqwstVT
         rLRg==
X-Gm-Message-State: ALoCoQmQubdc9VDYmn/cWCAIOuRAESv30+4eXGwFPXZ0279qYe3enrMkyDE3BhwOMuuBlmCW3AzD
X-Received: by 10.236.66.178 with SMTP id h38mr12180862yhd.44.1405004321283;
        Thu, 10 Jul 2014 07:58:41 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.43.163 with SMTP id x3ls201871igl.2.gmail; Thu, 10 Jul 2014
 07:58:40 -0700 (PDT)
X-Received: by 10.50.33.17 with SMTP id n17mr22032624igi.15.1405004320685;
        Thu, 10 Jul 2014 07:58:40 -0700 (PDT)
Original-Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [2607:f8b0:4001:c03::235])
        by mx.google.com with ESMTPS id t10si13553989igh.36.2014.07.10.07.58.40
        for <std-proposals@isocpp.org>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Thu, 10 Jul 2014 07:58:40 -0700 (PDT)
Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::235 as permitted sender) client-ip=2607:f8b0:4001:c03::235;
Original-Received: by mail-ie0-f181.google.com with SMTP id rp18so2181525iec.40
        for <std-proposals@isocpp.org>; Thu, 10 Jul 2014 07:58:40 -0700 (PDT)
X-Received: by 10.50.66.179 with SMTP id g19mr7052610igt.34.1405004320485;
        Thu, 10 Jul 2014 07:58:40 -0700 (PDT)
Original-Received: from [172.20.10.2] ([121.54.54.43])
        by mx.google.com with ESMTPSA id tp2sm25768984igb.7.2014.07.10.07.58.31
        for <std-proposals@isocpp.org>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Thu, 10 Jul 2014 07:58:39 -0700 (PDT)
In-Reply-To: <CAFk2RUYRJSNcXykj9oPd=3EehSozf7PcX8ACM_hrqhK+Ur2V8A@mail.gmail.com>
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::235 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: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11809
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/11809>

--Apple-Mail=_36C7DCE8-AF9A-4998-B313-76D861386C7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 10:44 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:

> On 10 July 2014 17:24, David Krauss <potswa@gmail.com> wrote:
>> A return-by-reference from a non-ref-discriminated accessor devolving to
>> return-by-copy would regress legacy code, but that doesn't make such lib=
rary
>> behavior semantically sound from a modern point of view.
>=20
> The "modern point of view" should include the forwarding concerns, which
> are not limited to the performance of emplace.

Absolutely. I'm have an interest in this because 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 provid=
e
>> them
>> with one.
>>=20
>>=20
>> The rvalue-ref-qualified signatures of what, std::optional? That's not a
>=20
> Uh.. yes. That's the topic of this thread.

Maybe I don't understand the standardization process, but wouldn't the cons=
ervative solution be to simply roll that back from N4078, so optional behav=
es the same as everything else? Adding a new feature in a particular way do=
esn't fall into the category of legacy support.

Optional is attempting to be the most perfect proxy class ever designed, an=
d it's pushing the envelope in a way that fundamentally disagrees with stan=
dardization. Simply put, it's churning too much.

The debate can't be just about optional, even just in this thread, because =
the rest of the library is going to have to follow suit.

--=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=_36C7DCE8-AF9A-4998-B313-76D861386C7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 10:44 PM, Ville Voutilainen &lt;<a href=3D"mailto:vil=
le.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 10 July=
 2014 17:24, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gm=
ail.com</a>&gt; wrote:<br><blockquote type=3D"cite">A return-by-reference f=
rom a non-ref-discriminated accessor devolving to<br>return-by-copy would r=
egress legacy code, but that doesn&rsquo;t make such library<br>behavior se=
mantically sound from a modern point of view.<br></blockquote><br>The "mode=
rn point of view" should include the forwarding concerns, which<br>are not =
limited to the performance of emplace.<br></blockquote><div><br></div><div>=
Absolutely. I&rsquo;m have an interest in this because I write this kind of=
 code.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite">The rva=
lue-ref-qualified signatures need to return T&amp;&amp; instead of T.<br>LE=
WG needs an NB comment<br>to be able to make that fix for Fundamentals v1, =
and I'm going to provide<br>them<br>with one.<br><br><br>The rvalue-ref-qua=
lified signatures of what, std::optional? That&rsquo;s not a<br></blockquot=
e><br>Uh.. yes. That's the topic of this thread.<br></blockquote><div><br><=
/div></div>Maybe I don&rsquo;t understand the standardization process, but =
wouldn&rsquo;t the conservative solution be to simply roll that back from N=
4078, so optional behaves the same as everything else? Adding a new feature=
 in a particular way doesn&rsquo;t fall into the category of legacy support=
..<div><br></div><div>Optional is attempting to be the most perfect proxy cl=
ass ever designed, and it&rsquo;s pushing the envelope in a way that fundam=
entally disagrees with standardization. Simply put, it&rsquo;s churning too=
 much.</div><div><br></div><div>The debate can&rsquo;t be just about <font =
face=3D"Courier">optional</font>, even just in this thread, because the res=
t of the library is going to have to follow suit.</div><div><br></div></bod=
y></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_36C7DCE8-AF9A-4998-B313-76D861386C7E--

.
