220 11839 <13DD0D7A-A146-4667-9F30-6FB3739CDBE0@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: Fri, 11 Jul 2014 16:54:55 +0800 Lines: 115 Approved: news@gmane.org Message-ID: <13DD0D7A-A146-4667-9F30-6FB3739CDBE0@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> 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=_5C75E495-0790-4076-82F1-E4946CD01250" X-Trace: ger.gmane.org 1405068913 9917 80.91.229.3 (11 Jul 2014 08:55:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 08:55:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBZ6M72OQKGQEYWIERCI@isocpp.org Fri Jul 11 10:55:07 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5Wbh-00031p-4d for gclcip-std-proposals@m.gmane.org; Fri, 11 Jul 2014 10:55:05 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id tr6sf3976982ieb.6 for ; Fri, 11 Jul 2014 01:55:04 -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=tqYhq1waqi3HaZlea5GRQvohijRF9zY6v5eyOu82HmA=; b=Azopsbe6PpSNmWusgKzD+0yv9UaLdiady9q0f5GeFkRjh4oVpRYxVFWJHOt3cMXpz4 RqMANGpK/n2CSmVt/JPd+9Fm6DXKnB2PwjsrnM6a67yxubjuLTMa3cHg4Olq1Ewkxh2r naInNZwRSkipmZCS4WqJugug45PS3cS+WaR4r8BgXO1RMa+ACorxFN/3RClUpIFU10S8 lEtbljo00DGq3c52sF5WQYZ9qHS8M2j/IzRsFIuIPq58GV82NAKd7RGjnRVQpZ2Hb5SJ ZcWL9YP2ClQbBZnPBsZDAb5XUPpc1n08TG73CDgtWs2QifB4WSqwDgVZUuxMbHa14TO1 4Llg== X-Gm-Message-State: ALoCoQkJDT/i8vWTCgv3WHRJDcjH3GGIWVCycKOH8QKacRl8D5uxd7luYenmBvkzFaXO/kpv6r2z X-Received: by 10.182.250.229 with SMTP id zf5mr5846997obc.4.1405068904236; Fri, 11 Jul 2014 01:55:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.73.130 with SMTP id l2ls279406igv.28.gmail; Fri, 11 Jul 2014 01:55:03 -0700 (PDT) X-Received: by 10.42.106.15 with SMTP id x15mr2938966ico.67.1405068903710; Fri, 11 Jul 2014 01:55:03 -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 oy4si3632274icc.35.2014.07.11.01.55.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 01:55:03 -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 rp18so640761iec.40 for ; Fri, 11 Jul 2014 01:55:03 -0700 (PDT) X-Received: by 10.43.140.193 with SMTP id jb1mr3026789icc.15.1405068903611; Fri, 11 Jul 2014 01:55:03 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.43]) by mx.google.com with ESMTPSA id rq5sm4211270igb.0.2014.07.11.01.55.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 01:55:03 -0700 (PDT) In-Reply-To: <6a4b6425-1167-40c1-acd8-3945c8cd4c74@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::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: 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:11839 Archived-At: --Apple-Mail=_5C75E495-0790-4076-82F1-E4946CD01250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On 2014=E2=80=9307=E2=80=9311, at 3:40 PM, Andrzej Krzemie=C5=84ski wrote: > Guys, I just want to summarize what is being discussed here so that every= one is on the same page. We are discussing how overloads operator*() and va= lue() are defined in optional. >=20 > So we are not reverting the change. We change further. >=20 > Am I right? What=E2=80=99s the urgency? You can still specify the correct behavior using only the lvalue-ref access= or. Tomasz=E2=80=99 example only looked ugly because no effort was made to = solve the problem generically or elegantly. It has the same behavior as my = forward_component utility. Following up on the request to work with any smart pointer with a prvalue a= ccessor, a better solution than forward_component would be an idiom effecti= vely like std::forward< decltype( * std::forward< U >( u ) ) >( * u ) However, there are not yet any other operator * () && functions with which = to interoperate, so users are stuck writing non-generically, and std::optio= nal might as well go into the same special case as std::unique_ptr. There=E2=80=99s no reason for the TS to venture into this contentious terri= tory. The dilemma deserves further review. The problem can be solved later = without burdening users or harming existing code-bases. There=E2=80=99s no = sense in putting the cart before the horse with the entire containers and s= mart-pointers libraries. TL;DR: The churn is only churn: chasing false constraints around the design= space. Return-by-prvalue does not preclude generic forwarding, but the cur= rent state of containers and smart-pointers does. You=E2=80=99re not going = to get generic owned-object forwarding in TS1 no matter how you extend opti= onal::operator*, but you could screw up the library forever. --=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=_5C75E495-0790-4076-82F1-E4946CD01250 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2014=E2=80= =9307=E2=80=9311, at 3:40 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wrote:

Guys, I just want to summarize what is being discussed here so that everyone=20 is on the same page. We are discussing how overloads operator*() and=20 value() are defined in optional.

So we are not reverting t= he change. We change further.

Am I right?

What=E2=80=99s the urgency?

You can still specify the correct behavior using only the lvalue-ref = accessor. Tomasz=E2=80=99 example only looked ugly because no effort was ma= de to solve the problem generically or elegantly. It has the same behavior = as my forward_component utility.
Following up on the request to work with any smart pointer wit= h a prvalue accessor, a better solution than forward= _component would be an idiom effectively like

std::forward< decltype( * std::forward< U >( u ) )= >( * u )

However, there are not yet any= other operator * () && function= s with which to interoperate, so users are stuck writing non-generically, a= nd std::optional might as well go i= nto the same special case as std::unique_ptr.=

There=E2=80=99s no reason for the TS to venture i= nto this contentious territory. The dilemma deserves further review. The pr= oblem can be solved later without burdening users or harming existing code-= bases. There=E2=80=99s no sense in putting the cart before the horse with t= he entire containers and smart-pointers libraries.

TL;DR: The churn is only churn: chasing false constraints around the desig= n space. Return-by-prvalue does not preclude generic forwarding, but the cu= rrent state of containers and smart-pointers does. You=E2=80=99re not going= to get generic owned-object forwarding in TS1 no matter how you extend optional::operator*, but you could screw up the = library forever.

--

---
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=_5C75E495-0790-4076-82F1-E4946CD01250-- .