220 11797 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: Thu, 10 Jul 2014 16:58:29 +0800 Lines: 146 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> 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=_21E15F34-7244-4CA2-97E4-8D9FDF9F6CD9" X-Trace: ger.gmane.org 1404982732 4912 80.91.229.3 (10 Jul 2014 08:58:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 08:58:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBP5L7GOQKGQE2OS2SYI@isocpp.org Thu Jul 10 10:58:45 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5ABd-0003sH-Bo for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 10:58:41 +0200 Original-Received: by mail-ob0-f197.google.com with SMTP id uz6sf46982278obc.4 for ; Thu, 10 Jul 2014 01:58:40 -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=7UQYBXQfBRDzxmYQxM/ISguj+KxUY8uc5+lF8juzdxw=; b=gGqR+IvEQYW0KrU4wO2yZCH7SIKlw+X9U/8ouRWGE4ENowudYf6p2HUMZkHSwHfTQg eIdLu16X2SXm4qflnhJngUTIpRDXz7Ll6SwGgLPzjMG8GgW0oaKKUH/mSBxLtLWpETXe ioPd0Z8S+vmvEaAQipGI5irqVkt7DJpCtkUlAefIJoqcfnF+IyOT8xpYX5HMabkP8h97 BN+Znd4Iox1+BTCTigriLtgdJFMTsCdW4D8nMSBuQ5RsT58m55OItFo3GfG8cFZPytRL +8kaCgaUoGvfKn8DAs+9mhslaeJoI5qXcENcz23IbaADdIGjUQ92CYnqJ34iUeY+gkvU 4TLQ== X-Gm-Message-State: ALoCoQlOCehBJIMKjQTY1i95uXr6Duk3TFlH36OXjIWa2EfCwSPBEM3y2yXLohA8nKfusc8z6muq X-Received: by 10.43.92.195 with SMTP id br3mr22142939icc.1.1404982720254; Thu, 10 Jul 2014 01:58:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.138.38 with SMTP id qn6ls1458053igb.28.canary; Thu, 10 Jul 2014 01:58:39 -0700 (PDT) X-Received: by 10.43.179.73 with SMTP id oz9mr52534120icc.18.1404982719540; Thu, 10 Jul 2014 01:58:39 -0700 (PDT) Original-Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [2607:f8b0:4001:c05::22a]) by mx.google.com with ESMTPS id h11si21379558icl.65.2014.07.10.01.58.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 01:58:39 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c05::22a as permitted sender) client-ip=2607:f8b0:4001:c05::22a; Original-Received: by mail-ig0-f170.google.com with SMTP id h15so2842897igd.1 for ; Thu, 10 Jul 2014 01:58:39 -0700 (PDT) X-Received: by 10.50.137.73 with SMTP id qg9mr19893181igb.19.1404982719400; Thu, 10 Jul 2014 01:58:39 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.43]) by mx.google.com with ESMTPSA id qa4sm23377385igb.10.2014.07.10.01.58.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 01:58:38 -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::22a 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:11797 Archived-At: --Apple-Mail=_21E15F34-7244-4CA2-97E4-8D9FDF9F6CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-07-10, at 2:49 PM, Ville Voutilainen = wrote: > On 10 July 2014 09:41, David Krauss wrote: >> If you're going to iterate over a sequence within a container, but you g= ot >> the first iterator from an xvalue, then the sequence is presumed to be d= ead >> by the first statement in the loop. >=20 > The sequence is not dead if I pass the iterator onto a processing functio= n > before the xvalue expires. Which is precisely what the general forwarding= cases > do, and what emplace does. Passing an iterator with the guarantee that the function will not retain a = reference into the sequence is fine, but that doesn't lend meaning to std::= forward< Container >( container ).begin(). If the container is still expect= ed to be valid at the semicolon, then do not move/forward. If the sequence = algorithm is supposed to move-from the sequence, then use a std::move_itera= tor instead. Perhaps there's a use-case for a std::forward_iterator (perhap= s just as an alias template) but I don't see that following directly from w= hat you've suggested so far. I'd still like to see an example of what begin() on an xvalue is supposed t= o accomplish. >> The example is in this thread, as has been said multiple times already. >> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/i= LJFlolCOBgJ >>=20 >>=20 >> That's just a link to this thread, to a message containing another link.= The >> text begin() does not occur in that thread. >=20 > Yeah, well, that message shows the "forwarding scenario". OK, I'll try to parse it. It doesn't relate to a sequence. The function nam= e means nothing. The point is simply that returning a reference avoids movi= ng through a temporary in this case, so what? This isn't the kind of justif= ication and writeup that I'd expect for something as broad as a library-wid= e policy about the interaction of value category with function returns. (Th= e author clearly didn't have such grand intent, to be fair.) Risky micro-optimization should never be the default. If forward-by-referen= ce returns are sometimes desired for performance, then add them under a fun= ction name like forward_*() or provide a suitable additional sibling to std= ::forward() to handle such cases. Do not foist the hack on everyone. Function returns should have predictable value category, whatever your pref= erence for safety vs. speed. If the function specification must depend on p= erformance, then the correct standard library specification would be to lea= ve it implementation-defined. However, it's a false dichotomy because you c= an always introduce a new name for new behavior. --=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=_21E15F34-7244-4CA2-97E4-8D9FDF9F6CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 2014&= ndash;07–10, at 2:49 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 10 July = 2014 09:41, David Krauss <potswa@gma= il.com> wrote:
If you’re going to= iterate over a sequence within a container, but you got
the first itera= tor from an xvalue, then the sequence is presumed to be dead
by the firs= t statement in the loop.

The sequence is not dead if I = pass the iterator onto a processing function
before the xvalue expires. = Which is precisely what the general forwarding cases
do, and what emplac= e does.

Passing an iterator with the gu= arantee that the function will not retain a reference into the sequence is = fine, but that doesn’t lend meaning to std::fo= rward< Container >( container ).begin(). If the container is s= till expected to be valid at the semicolon, then do not move/forward. If th= e sequence algorithm is supposed to move-from the sequence, then use a std::move_iterator instead. Perhaps there’s= a use-case for a std::forward_iterator = (perhaps just as an alias template) but I don’t see that following di= rectly from what you’ve suggested so far.

I&= rsquo;d still like to see an example of what begin()= on an xvalue is supposed to accomplish.

The example is in this thread, as has b= een said multiple times already.
https://groups.goo= gle.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iLJFlolCOBgJ

That’s just a link to this thread, to a message containing anot= her link. The
text begin() does not occur in that thread.

Yeah, well, that message shows the "forwarding scenario”.

OK, I’ll try to parse it. It doesn&rsq= uo;t relate to a sequence. The function name means nothing. The point is si= mply that returning a reference avoids moving through a temporary in this c= ase, so what? This isn’t the kind of justification and writeup that I= ’d expect for something as broad as a library-wide policy about the i= nteraction of value category with function returns. (The author clearly did= n’t have such grand intent, to be fair.)

Ris= ky micro-optimization should never be the default. If forward-by-reference = returns are sometimes desired for performance, then add them under a functi= on name like forward_*() or provide a su= itable additional sibling to std::forward() to handle such cases. Do not foist the hack on everyone.

=
Function returns should have predictable value category, whateve= r your preference for safety vs. speed. If the function specification must = depend on performance, then the correct standard library specification woul= d be to leave it implementation-defined. However, it’s a false dichot= omy because you can always introduce a new name for new behavior.

--

---
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=_21E15F34-7244-4CA2-97E4-8D9FDF9F6CD9-- .