220 11858 <6B925FF7-2940-44C7-BF1D-13209A703BA2@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 18:21:20 +0800 Lines: 123 Approved: news@gmane.org Message-ID: <6B925FF7-2940-44C7-BF1D-13209A703BA2@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> <13DD0D7A-A146-4667-9F30-6FB3739CDBE0@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=_206A06F3-E0CE-407B-B5C7-CD2D5E009A6A" X-Trace: ger.gmane.org 1405074096 7805 80.91.229.3 (11 Jul 2014 10:21:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 10:21:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBKHV72OQKGQEECA2HKA@isocpp.org Fri Jul 11 12:21:29 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5XxJ-0006oq-DP for gclcip-std-proposals@m.gmane.org; Fri, 11 Jul 2014 12:21:29 +0200 Original-Received: by mail-ig0-f198.google.com with SMTP id h18sf2863821igc.1 for ; Fri, 11 Jul 2014 03:21:28 -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=4dvqIodqkai2MGNpMjALiZdGjZNUbM4O9nmgLjSKkrI=; b=auvj6bIVK5O7LAW8pv83LVMnVyihxuSKNQhZhVFyLyIS7IjdEbS0h1kItEC/0kZQn6 +pb75x/HIFBhyuHlp0Rrby4H/rN2DnvmQNxlacKcj2uI1NPfoOFZhMGhRR+NQkj7iGfQ F8UXXvIrF6NrOL8iB8JnsD9cC0iUULrgDXz8USD8Jz3Lq6CGWEWLD++4kSsuSTWo46Mo PwrocXj+Qu5VoZYp6+ExlRfnxo/rjQKPD4Unof22lCyWiVjoFvt2SUlr7Exrx2JvpBeN dkg6j45gFL+9Xo00wWopurkeRlaHkkI4wxW+Xb1a4ao9qnIpdxJSItNxwQXfsfxCVDUn 6sBQ== X-Gm-Message-State: ALoCoQk6V2LSJe5Wm/ENrZO1Boiv2wbK7esRELsboY7/Fm/E5tCQZiTuOqnM62u136R+mncqFQyP X-Received: by 10.43.70.132 with SMTP id yg4mr1608289icb.30.1405074088531; Fri, 11 Jul 2014 03:21:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.138.193 with SMTP id qs1ls278152igb.43.canary; Fri, 11 Jul 2014 03:21:28 -0700 (PDT) X-Received: by 10.42.139.4 with SMTP id e4mr3265557icu.73.1405074088002; Fri, 11 Jul 2014 03:21:28 -0700 (PDT) Original-Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [2607:f8b0:4001:c05::22e]) by mx.google.com with ESMTPS id e3si2623078igx.4.2014.07.11.03.21.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 03:21:27 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c05::22e as permitted sender) client-ip=2607:f8b0:4001:c05::22e; Original-Received: by mail-ig0-f174.google.com with SMTP id c1so4096534igq.1 for ; Fri, 11 Jul 2014 03:21:27 -0700 (PDT) X-Received: by 10.51.16.197 with SMTP id fy5mr3016528igd.47.1405074087871; Fri, 11 Jul 2014 03:21:27 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.152]) by mx.google.com with ESMTPSA id p12sm4704319igx.18.2014.07.11.03.21.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 03:21:27 -0700 (PDT) In-Reply-To: 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:c05::22e 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:11858 Archived-At: --Apple-Mail=_206A06F3-E0CE-407B-B5C7-CD2D5E009A6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-07-11, at 5:47 PM, Ville Voutilainen = wrote: > On 11 July 2014 12:36, David Krauss wrote: >>=20 >> On 2014-07-11, at 5:34 PM, Ville Voutilainen wrote: >>=20 >>> Why is that code using auto&&? >>=20 >> Can you rewrite it with any other substitute? >=20 >=20 > That would depend on the answer to the question. The container is not > going out of scope, The pattern I intended to illustrate is, "take a one-liner using std::forwa= rd and divide it over two lines by adding a named variable." If I'd passed = ch to a function, it could well get moved-from. A more straightforward example is simply naming the result of a generic fun= ction. auto && result =3D q( std::forward< V >( v ) ); Using auto instead of auto && may produce an unnecessary copy. No, it doesn= 't work if q returns an expiring reference, but yes, it does if q guarantee= s it won't. It's possible, and good, to write libraries that don't have exp= iring return values, regardless of what someone else did and the pain felt = by their users. Indeed, the question could go either way. Both alternatives introduce probl= ems, which anyway may be worked around. I could create a generic function s= ave_xvalue() to catch such and copy into a prvalue, and use that as an adap= tor to auto &&. However, I think component-forwarding should get stuck with= the workaround because it's more esoteric than auto &&. > I see nothing new that would be convincing to change the understanding > I have about what > we should do for the rvalue-ref-qualified observer overloads of optional. Well, at least we see eye-to-eye. I hope you're right about the TS not carr= ying a lock-in effect. The only responsible way to resolve this dilemma for= the entire library is with thorough review in a proper context. --=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=_206A06F3-E0CE-407B-B5C7-CD2D5E009A6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 2014&= ndash;07–11, at 5:47 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 11 July = 2014 12:36, David Krauss <potswa@gma= il.com> wrote:

On 2014-07-11, at 5:= 34 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

Why is that code using auto&&?

Can you rewrit= e it with any other substitute?


That would depend o= n the answer to the question. The container is not
going out of scope,

The pattern I intended to illustrate is,= “take a one-liner using std::forward and divide it over two lines by= adding a named variable.” If I’d passed ch to a function, it could well get moved-from.

A more straightforward example is simply naming the result of a gener= ic function.

auto &&= ; result =3D q( std::forward< V >( v ) );

=
Using auto instead of auto && may produce an unnecessary copy. No, = it doesn’t work if q returns an expiring reference, but yes, it does = if q guarantees it won’t. It’s possible, and good, to write lib= raries that don’t have expiring return values, regardless of what som= eone else did and the pain felt by their users.

In= deed, the question could go either way. Both alternatives introduce problem= s, which anyway may be worked around. I could create a generic function save_xvalue() to catch such and copy into a= prvalue, and use that as an adaptor to auto &&a= mp;. However, I think component-forwarding should get stuck with the= workaround because it’s more esoteric than au= to &&.

I see nothing new = that would be convincing to change the understanding
I have about whatwe should do for the rvalue-ref-qualified observer overloads of optional.=

Well, at least we see eye-to-eye. I hope yo= u’re right about the TS not carrying a lock-in effect. The only respo= nsible way to resolve this dilemma for the entire library is with thorough = review in a proper context.

--

---
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=_206A06F3-E0CE-407B-B5C7-CD2D5E009A6A-- .