220 11803 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 19:12:42 +0800 Lines: 160 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> <6F4B3C72-9962-48DC-8527-0C89EA1B9710@gmail.com> <072cf8b4-4c74-438e-9999-0aab13bf3182@isocpp.org> <74CEDDAC-1B1B-4F06-9E58-2F025921FE55@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=_E9E7CE9F-821B-476B-9720-FAD3FC0F878E" X-Trace: ger.gmane.org 1404990787 6401 80.91.229.3 (10 Jul 2014 11:13:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 11:13:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBOPK7GOQKGQEL6FMMHA@isocpp.org Thu Jul 10 13:13:00 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f71.google.com ([209.85.213.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5CHa-0003nn-DR for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 13:12:58 +0200 Original-Received: by mail-yh0-f71.google.com with SMTP id t59sf34965659yho.6 for ; Thu, 10 Jul 2014 04:12:57 -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=+UIi2VkB6n+J/058dhSOF/k65o5GUsgLalLCSLa0Sh8=; b=Ph3qjOcR3IX2N1Wa9b33PidJFuH0OaXIuiLsAnFCEwzpDZv/gP0FVDItC+otCbFL58 rx1MmvYe81WQIYj38hiA/0TfP8zNPa59NfRDAwQGW/ltDYTDhNCttsHh7UaO6tuWugwL M3sIM3iiMJj7pAcpVCO6j6Uh7iPKrmFAJouQCMS2HBcalRAnYtlGlGpgnuXKrqxFrzr5 Mte44gxumP/1i+1t4ld0cvi/3DelU10Xk2vl+Ie+DRRS9+O/BoibLXTTURrLOC1nTHnV tC9ZY5nxXgTBdXbOZDyMN49nsX+f5I/kvZYLpY3fEs8MHmgjKBZBzH3DWkhQzCDx5axR flYg== X-Gm-Message-State: ALoCoQnpFMlFuhdcWVI9niPmVhgZHPlJeO1kg177mj40JePRREbzwjGQp46Jq6v3dKx6wXVSuNKz X-Received: by 10.224.72.74 with SMTP id l10mr22473708qaj.4.1404990777564; Thu, 10 Jul 2014 04:12:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.97.4 with SMTP id dw4ls113123igb.10.gmail; Thu, 10 Jul 2014 04:12:56 -0700 (PDT) X-Received: by 10.42.51.204 with SMTP id f12mr55662021icg.21.1404990776848; Thu, 10 Jul 2014 04:12:56 -0700 (PDT) Original-Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [2607:f8b0:4001:c05::236]) by mx.google.com with ESMTPS id z3si3044536icw.105.2014.07.10.04.12.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 04:12:56 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c05::236 as permitted sender) client-ip=2607:f8b0:4001:c05::236; Original-Received: by mail-ig0-f182.google.com with SMTP id c1so2929120igq.9 for ; Thu, 10 Jul 2014 04:12:56 -0700 (PDT) X-Received: by 10.50.129.104 with SMTP id nv8mr20960626igb.45.1404990776720; Thu, 10 Jul 2014 04:12:56 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.43]) by mx.google.com with ESMTPSA id d10sm24229012igz.11.2014.07.10.04.12.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 04:12:56 -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::236 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:11803 Archived-At: --Apple-Mail=_E9E7CE9F-821B-476B-9720-FAD3FC0F878E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On 2014=E2=80=9307=E2=80=9310, at 6:24 PM, tomaszkam@gmail.com wrote: > W dniu czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Kraus= s napisa=C5=82: >=20 > forward_component trusts the user that the function argument is owned by = an object of the template argument type. It handles vector::front and uniqu= e_ptr::operator* with equal aplomb, and we don=E2=80=99t even have to add r= value reference overloads to anything. (Although doing so may still be a go= od idea.) >=20 > And this wis actually break every use of forward with non-owning semenati= cs (shared_ptr). Please remember that forward function was designed to p= erfectly forward value of any type in generic context without introspection= , but introducing separate forward_compoent kills the idea, because we me d= ifferentiate between shared_ptr and unique_ptr. Shared ownership fails to satisfy the stated requirement. No suitable forwa= rding semantics exist for shared_ptr, and the value category of the pointer= carries no information about the shared object. You just have to assume th= at it=E2=80=99s not-owned, unless shared_ptr::unique returns true, in which= case forward_component works. No =E2=80=9Cgeneric context=E2=80=9D can handle different pointer types. un= ique_ptr always owns its referent but T* never does. You seem to suggest= I=E2=80=99ve =E2=80=9Ckilled=E2=80=9D an alternative that never existed in= the first place. Yes, it=E2=80=99s impossible to call make_shared, destroy the sharing pool,= and still safely bind the erstwhile-shared value to a universal reference = all in one declaration. This sounds pretty contrived, though. Use of shared= _ptr at all implies that the object existed before the line in question, an= d if you want to continue using a subobject after the line, don=E2=80=99t m= ove() the shared_pointer. > Acutally defininig the rvalue reference overload for member getters retur= ning rvalue reference (T&& meber() &&) is the way a type can signialize to = forward that it owning this member. That means we could have: > T&& operator*() &&; //for unique_ptr, bot not for shared_ptr > Or for vector: > T&& front() &&; > T&& back() &&; > Or even for begin/end members that will allows us to have better traversa= ble constructor: https://groups.google.com/a/isocpp.org/forum/?fromgroups#!= topic/std-proposals/sOw68ogy6BM Yes, I mentioned that hypothetically to Ville. Considering the implementati= on effort and added compilation complexity of that strategy, you might as w= ell use forward_component() with no adjustment to the container (or plain-o= ld move() when not forwarding). > Now const&& should have the same semenantics as the const& so the additio= n overload is not necessary. Strange, I didn=E2=80=99t realize that const& is preferred over && for a co= nst rvalue implicit argument, but so it is. GCC even fails to prefer const&= & over const&. --=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=_E9E7CE9F-821B-476B-9720-FAD3FC0F878E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2014=E2=80= =9307=E2=80=9310, at 6:24 PM, tomasz= kam@gmail.com wrote:

W dniu czwartek, 10 lipca 2014 12:00:= 56 UTC+2 u=C5=BCytkownik David Krauss napisa=C5=82:

forward_component trusts the= user that the function argument is owned by an object of the template argu= ment type. It handles vector::front and = unique_ptr::operator* with equal aplomb, and = we don=E2=80=99t even have to add rvalue reference overloads to anything. (= Although doing so may still be a good idea.)
=

And this wis actually break every use of forward with non-owning s= emenatics (shared_ptr<T>). Please remember that forward function was = designed to perfectly forward value of any type in generic context without = introspection, but introducing separate forward_compoent kills the idea, be= cause we me differentiate between shared_ptr and unique_ptr.

Shared ownership fails to satisfy the sta= ted requirement. No suitable forwarding semantics exist for shared_ptr, and the value category of the pointer carries no= information about the shared object. You just have to assume that it=E2=80= =99s not-owned, unless shared_ptr::unique ret= urns true, in which case forward_component wo= rks.

No =E2=80=9Cgeneric context=E2=80=9D can= handle different pointer types. unique_ptr<= T> always owns its referent but = T* never does. You seem to suggest I=E2=80=99ve =E2=80=9Ckilled= =E2=80=9D an alternative that never existed in the first place.
<= br>
Yes, it=E2=80=99s impossible to call make_shared, destroy the sharing pool, and still safely bind th= e erstwhile-shared value to a universal reference all in one declaration. T= his sounds pretty contrived, though. Use of shared_p= tr at all implies that the object existed before the line in questio= n, and if you want to continue using a subobject after the line, don=E2=80= =99t move() the shared= _pointer.

Acutally defininig the rvalue reference overload for member gette= rs returning rvalue reference (T&& meber() &&) is the way a= type can signialize to forward that it owning this member. That means we c= ould have:
T&& operator*() &&; //for unique_ptr, bot not= for shared_ptr
Or for vector<T>:
T&& front() &&= ;;
T&& back() &&;
Or even for begin/end members that = will allows us to have better traversable constructor: https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-= proposals/sOw68ogy6BM

Y= es, I mentioned that hypothetically to Ville. Considering the implementatio= n effort and added compilation complexity of that strategy, you might as we= ll use forward_component() with no adjus= tment to the container (or plain-old move() when not forwarding).

Now const&& should have the same semenantics as the const&a= mp; so the addition overload is not necessary.

Strange, I didn=E2=80=99t realize that const& is preferred over && for a const rvalue implicit argument, bu= t so it is. GCC even fails to prefer const&&= over const&.

--

---
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=_E9E7CE9F-821B-476B-9720-FAD3FC0F878E-- .