220 11802 article Path: news.gmane.org!not-for-mail From: tomaszkam@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 03:24:50 -0700 (PDT) Lines: 225 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 Content-Type: multipart/alternative; boundary="----=_Part_49_17651027.1404987890892" X-Trace: ger.gmane.org 1404987902 4958 80.91.229.3 (10 Jul 2014 10:25:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 10:25:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBB5GT7GOQKGQEVY4ZYHQ@isocpp.org Thu Jul 10 12:24:55 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5BX3-0004lX-PR for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 12:24:54 +0200 Original-Received: by mail-qa0-f72.google.com with SMTP id s7sf8960223qap.7 for ; Thu, 10 Jul 2014 03:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=cKToDHbN92bxjpvFZWjzqnBoaE5f9yRAyTmAqUwXhXQ=; b=BrqfWmBgYn/xrnz83g16FxClxr9KBusdyz7dF773nrxZekmsu4Q2hQL9xprdhMiv9+ DPSJ1DLgbzb9bE75J52Q/ZIj+/BjOKtpel3Qj06zXyA9Rbp5tiNcpID+kqTfNiiKQuGR EZqZ+zaGQtiCh1TB9J/DBb2LTrVhvrbobqPOsr5b6oWfy0CZ9ABhVqCRwTsn2ArRSBKU NzUKvJYRvZaKG2D2Zs91UYOUlxlExAzu+EZfL1L/Is9wFYfo7P89eaj28JJCq/tTX6ly WiCZge3mfA/7YXP/nMSabxGLACjNowdQg5FBjyST9onpSeV1XKLUPSeIgwyH+VB3C9vd u0vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=cKToDHbN92bxjpvFZWjzqnBoaE5f9yRAyTmAqUwXhXQ=; b=lj/OPvO3xMUZ3msTi4VMb2ZdsD4yR07Gt55PZWGYDa1t2V/BJvHF3qMgl6v0alJIHM ZQC0UkutEgJ9Sujh+oDyUXw5KDeA+oDZ1h/O+x8wEGR8ekW7F7uvaH7oV76ySxtwpm2M Phl7KaPPWUZUvrRzjwlQmR+liW4u8frF7IiipPX88plOju3F4NrsAOT+BedfLYlbdz81 lu34MRd/wu1P2XcmOJ0mF2pl196uzIcMgawH53yKWJ4syhkTL+HhQb9e2EJtvysrF1JI 375FmAPPurVH2QbNq42LaFKCXYMFACct7ZgRkaQImh8vuBAKuj3w4w003Sr5xnIyn1B5 rz/g== X-Gm-Message-State: ALoCoQnylr31Hu0H0M73GKtsiVPaX7No38VQpHAEhcxf7slD8O5uf/u5Wwxvkd4QK2AJohYgwR85 X-Received: by 10.236.98.33 with SMTP id u21mr19323952yhf.39.1404987892837; Thu, 10 Jul 2014 03:24:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.181.99 with SMTP id dv3ls24101obc.4.gmail; Thu, 10 Jul 2014 03:24:51 -0700 (PDT) X-Received: by 10.182.176.37 with SMTP id cf5mr59466obc.22.1404987891817; Thu, 10 Jul 2014 03:24:51 -0700 (PDT) In-Reply-To: <74CEDDAC-1B1B-4F06-9E58-2F025921FE55@gmail.com> X-Original-Sender: tomaszkam@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:11802 Archived-At: ------=_Part_49_17651027.1404987890892 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Krauss= =20 napisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9310, at 5:29 PM, toma...@gmail.com wrote: > > Which makes following invoaction f(expr.value()) where takes T by const&= =20 > and expr is value of type optional, introducing has additonal=20 > possibly-copy dependin on expr being lvalue or r-value. And makes using= =20 > optional in generic context when perfect forwardin us used a pain. I=20 > propose to set of methods to look like: > T& value() &; > T const& value() const &; > T&& value() &&; > To achieve consistency with std::get function or even simple meber acces= =20 > with procudes same cateogry value for subobject. > > > Here=E2=80=99s the issue: std::get cannot reliably produce the same value= category=20 > as a simple member access, because functions (in C++11, at least) cannot= =20 > distinguish xvalue arguments from prvalues. A member access on a prvalue= =20 > produces a prvalue, but a member access get< N >( prvalue() ).mem produce= s=20 > an xvalue. > > Why not put the adjustment into the forwarding function itself? > > template< typename owner_type, typename value_type > > std::enable_if_t< std::is_lvalue_reference< owner_type >::value, > value_type & > > forward_component( value_type & v ) > { return v; } // Container passed as lvalue yields a reference to=20 > lvalue. > > template< typename owner_type, typename value_type > > std::enable_if_t< ! std::is_lvalue_reference< owner_type >::value, > value_type && > > forward_component( value_type & v ) > { return std::move( v ); } // Container passed as prvalue or xvalue= =20 > yields xvalue. > > Usage in the example context: > > return u ? std::forward(fv)(forward_component(*u)) :=20 > std::forward(fn); > > forward_component trusts the user that the function argument is owned by= =20 > an object of the template argument type. It handles vector::front and=20 > unique_ptr::operator* with equal aplomb, and we don=E2=80=99t even have t= o add=20 > rvalue reference overloads to anything. (Although doing so may still be a= =20 > good idea.) > And this wis actually break every use of forward with non-owning semenatics= =20 (shared_ptr). Please remember that forward function was designed to=20 perfectly forward value of any type in generic context without=20 introspection, but introducing separate forward_compoent kills the idea,=20 because we me differentiate between shared_ptr and unique_ptr. Acutally defininig the rvalue reference overload for member getters=20 returning rvalue reference (T&& meber() &&) is the way a type can=20 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=20 traversable constructor:=20 https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposa= ls/sOw68ogy6BM If the original set of the methods was: > T value() const; > I would argee tthe the new function should be declared as: > T value() const &; > T value() &&; > But this is not true in the case of optional. And also not having safe=20 > version of operator* , that will allow you to modyfy value inplace, would= =20 > be a failure. Maybe the name is wrong. > > ? > > By the way, you might as well keep the const && overload. =E2=80=9C&&=E2= =80=9D and =E2=80=9Cconst=20 > &&=E2=80=9D usually have identical semantics. It is possible to have an= =20 > expression of const class type. > > Now const&& should have the same semenantics as the const& so the additio= n=20 overload is not neccessary.=20 =20 --=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/. ------=_Part_49_17651027.1404987890892 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

On 2014=E2=80=930= 7=E2=80=9310, at 5:29 PM, toma...@gmai= l.com wrote:

Which = makes following invoaction f(expr.value()) where takes T by const& and = expr is value of type optional<T>, introducing has additonal possibly= -copy dependin on expr being lvalue or r-value. And makes using optional in= generic context when perfect forwardin us used a pain. I propose to set of= methods to look like:
  T& value() &;
  T const&a= mp; value() const &;
  T&& value() &&;
 = ;To achieve consistency with std::get function or even simple meber acces w= ith procudes same cateogry value for subobject.
=
Here=E2=80=99s the issue: std::get cannot reliably produce t= he same value category as a simple member access, because functions (in C++= 11, at least) cannot distinguish xvalue arguments from prvalues. A member a= ccess on a prvalue produces a prvalue, but a member access get< N >( prvalue() ).mem produces an xvalue= ..

Why not put the adjustment into the forwarding f= unction itself?

template<= ; typename owner_type, typename value_type >
std::enable_if_t< std::is_lvalue_reference< = owner_type >::value,
  &nb= sp; value_type & >
forward_c= omponent( value_type & v )
&nbs= p;   { return v; } // Container passed as lvalue yields a reference to= lvalue.

template< typenam= e owner_type, typename value_type >
std::enable_if_t< ! std::is_lvalue_reference< owner_type&= nbsp;>::value,
    val= ue_type && >
forward_com= ponent( value_type & v )
 =   { return std::move( v ); } // Container passed as prvalue or xvalue= yields xvalue.

Usage in the example contex= t:

  return u ? std::f= orward<FV>(fv)(forward_component<U>(*u)) : std::forward<= ;FN>(fn);

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

And this wis actually break = every use of forward with non-owning semenatics (shared_ptr<T>). Plea= se remember that forward function was designed to perfectly forward value o= f any type in generic context without introspection, but introducing separa= te forward_compoent kills the idea, because we me differentiate between sha= red_ptr and unique_ptr.

Acutally defininig the rvalue reference over= load for member getters returning rvalue reference (T&& meber() &am= p;&) is the way a type can signialize to forward that it owning this me= mber. That means we could have:
T&& operator*() &&; //fo= r unique_ptr, bot not for shared_ptr
Or for vector<T>:
T&&a= mp; front() &&;
T&& back() &&;
Or even for be= gin/end members that will allows us to have better traversable constructor:= https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-propos= als/sOw68ogy6BM

If the original set  of the methods was:
  T=   value() const;
I would argee tthe the new function should be decl= ared as:
  T  value() const &;
  T  value() &= amp;&;
But this is not true in the case of optional. And also not ha= ving safe version of operator* , that will allow you to modyfy value inplac= e, would be a failure. Maybe the name is wrong.
?

By the way, you might as well keep the const && overload. =E2=80=9C&&=E2=80=9D and =E2=80=9Cconst &&=E2=80=9D usually have identical semantics. It i= s possible to have an expression of const class type.

<= /div>
Now const&& should have the same semenantics as t= he const& so the addition overload is not neccessary.
 

--

---
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>.
------=_Part_49_17651027.1404987890892-- .