220 11887 <1b70888c-eb6a-49e5-b254-a475ef015570@isocpp.org> 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: Sat, 12 Jul 2014 02:10:02 -0700 (PDT) Lines: 378 Approved: news@gmane.org Message-ID: <1b70888c-eb6a-49e5-b254-a475ef015570@isocpp.org> 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> <6B925FF7-2940-44C7-BF1D-13209A703BA2@gmail.com> <944C9C01-865B-4215-8C91-95F01AEA256E@gmail.com> <8DC3E474-3957-40B2-B492-D4AF2FDDD451@gmail.com> <0ACAE525-4FB2-4932-BBD2-F0623C4EBBFB@gmail.com> <52187852-ff8e-4e59-a8cf-7a29fd0a405b@isocpp.org> <8209A2E9-D947-4C00-A1F3-38F5676A4E52@gmail.com> <4c42f7c9-0588-4ab9-9af5-b2e692513993@isocpp.org> <225BBAAC-B3FA-4014-9FB6-64C48DF4208E@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_543_20324844.1405156202697" X-Trace: ger.gmane.org 1405156213 17675 80.91.229.3 (12 Jul 2014 09:10:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 09:10:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBB27WQOPAKGQER6EECQA@isocpp.org Sat Jul 12 11:10:06 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5tJl-0007z9-KD for gclcip-std-proposals@m.gmane.org; Sat, 12 Jul 2014 11:10:06 +0200 Original-Received: by mail-ig0-f197.google.com with SMTP id r2sf1014029igi.4 for ; Sat, 12 Jul 2014 02:10:04 -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=62K4i60YbMOlSns/ctXLyuPC99f4iVbSS0iDcr4epUs=; b=fGi1JmCtpi5pqOxhM95QgAQnOW8MfOgD411hcqHWeHXok22l+C3lnPzsa/gbJHcOty HA3C/vmI4oPv1iyBXFliE5MYU4f9cZscaVN2GDwBZeL9oDi6k8H1jH3f6s80xeldcla7 Rp5OXZt4ymA73ifDeuaWcYskmh8ct6vvL68Jr6zi1CadlasWAkyIYDljTsC26xcngcOU QSn19/XXC543zDNkwq7cqm21Jh5qYshci431ywlCaxTwKQOTBMYke/yDAPVXPckzU0Xb Pls2tLT2QMP7KjDbaTnHBaqqV3tTWdv0AwwfXdd4YOie3s3paed+fHbfsfD5pITw6g8L TsrA== 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=62K4i60YbMOlSns/ctXLyuPC99f4iVbSS0iDcr4epUs=; b=i71edQgPtQ/61oFJOCvIVvo1ISDtZ6zXd4h4YhYRnMC8ZslbY81THus+EOQmBIpIwh /a0oqxB2PIzuGcRUFQxBfzSw9/ReX5pREZzwJ371+o+5eqD0zSTuaEd3qGiJEe8R6K2Q /nhfELxeqgyYAtRVhwSUXwhniKK5ZeFLEPDOC5TflNjeS25QgZ4VbUdoT2LpGP5pKpHE 3n12PsmvCfrQLhjrgt5OuFuGedBrFrz55X5vWjSx3kzuOx1/wJ0rsUuxiKDgk5sZ2ejs YLxl8Fr31xrMPaczedaexoS/3+NPeP0OZ3Wl/743FQmlDUErdD/4mz58/hhhKGz28Bvb jpDQ== X-Gm-Message-State: ALoCoQmFo/LTqZl/r6v3NKub/nz5wkgGBW50UcLeKLIDbmNG5RxsNxP+6EaFWfUVJn/tUjkvdJxQ X-Received: by 10.50.41.3 with SMTP id b3mr4353424igl.0.1405156204706; Sat, 12 Jul 2014 02:10:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.65.138 with SMTP id x10ls666822obs.53.gmail; Sat, 12 Jul 2014 02:10:03 -0700 (PDT) X-Received: by 10.182.131.232 with SMTP id op8mr43obb.40.1405156203605; Sat, 12 Jul 2014 02:10:03 -0700 (PDT) In-Reply-To: <225BBAAC-B3FA-4014-9FB6-64C48DF4208E@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:11887 Archived-At: ------=_Part_543_20324844.1405156202697 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu sobota, 12 lipca 2014 09:51:15 UTC+2 u=C5=BCytkownik David Krauss na= pisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9312, at 3:27 PM, toma...@gmail.com wrote: > > 3. The above code does not work if if the passed Nullable type define &&= =20 > overload of operator* that returns by value. > Lifetime of object bound by auto&& value =3D=20 > *std::forward(nullable); is not the same as lifetime of nullabl= e. > > > Yes, but in that case what does the std::forward express? Reading that=20 > function, I would intuitively expect addressof(value) to become a=20 > dangling reference. Any other interpretation requires thinking hard about= =20 > what did **not** happen to the result of forward. It wasn=E2=80=99t passe= d to a=20 > function, but absence of some common thing isn=E2=80=99t a good discrimin= ating=20 > factor. (And in fact, it was passed to a function, operator *.) > > Because function_taking_pointer(pointer) passes a non-owning observer,=20 > nullable must live at least through that call. The intent is best=20 > expressed by simply value =3D * nullable; do not use forward(). This can = be=20 > declared as auto && or auto & equivalently. > > Am I missing something? > No, your are ok, But let me use your previous example.=20 template< typename container_handle > void operate_on_fifth_thing( container_handle && ch ) { // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr= ee those=20 resources. // However, if not assuming ownership, there=E2=80=99s no need to make = a copy. auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )= [ 5=20 ]; // This is illustrated as a function call, but there might as well be a= =20 loop here. process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing= =20 ) ); } Then assume than we want add some log information: template< typename container_handle > void operate_on_fifth_thing( container_handle && ch ) { // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr= ee those=20 resources. // However, if not assuming ownership, there=E2=80=99s no need to make = a copy. auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )= [ 5=20 ]; //Added some logging information log_value_of_fifth_thing(fifth_thing); // This is illustrated as a function call, but there might as well be a= =20 loop here. process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing= =20 ) ); } Then the user find the extract part of the function being to big and move= =20 it to separate function: template< typename container_handle > decltype(auto) get_fifth_thing(container_handle && ch) { // Get only the fifth element. We don=E2=80=99t need the rest; OK to free= those=20 resources. // However, if not assuming ownership, there=E2=80=99s no need to make a = copy. auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )[ = 5 ]; //Some loging log_value_of_fifth_thing(fifth_thing); return fifth_thing; } template< typename container_handle > void operate_on_fifth_thing( container_handle && ch ) { // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr= ee those=20 resources. auto && fifth_thing =3D get_fifth_thing(std::forward< container_hand= le=20 >( ch)) // This is illustrated as a function call, but there might as well be a= =20 loop here. process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing= =20 ) ); } I perceive all above transformation as being acceptable and I think that=20 the programmer expectation that the code will still be valid after them is= =20 vald. Do you agree? So lets analyze the situation: 1. Status quo (no r-value overloads for operator[] this time): The code= =20 is working before and after transformation the same way. 2. R-value reference r-value overload for operator[]: The code is working= =20 before and after transformation the same way. 3. Value r-value overload for operator[]: In the decltype(auto)=20 get_fifth_thing(container_handle && ch) the auto && fifth_thing =3D=3D ( *= =20 std::forward< container_handle >( ch ) )[ 5 ]; will cause fifth_thing to be= =20 type of T&&, meaning the return type of function will be reference and that= =20 will cause auto && fifth_thing =3D get_fifth_thing(std::forward<=20 container_handle >( ch)) to be a dangling reference. The code will be=20 broken by this transormation. Breaking the connection between lifetime of object and lifetime of=20 expression that should reference for subobject is not good think. I would like to summarize the arguments pros/cons that come in the thread.= =20 This is aimed to be objective a) addition of T&& value()&&; + makes a following code auto&& s =3D temporary_of_optional().value()= =20 use move semantics + std::forward(t).value() correctly forwards value as prvalue - auto&& cs =3D temporary_of_optional().value() still not works b) addition of T value()&&; + makes a: auto&& cs =3D temporary_of_optional().value() - breaks connection between lifetime of opt.value() and opt - introduce additional temporaries (copies) if the places that=20 captures temporary by const reference: f(temporary_of_optional().value()) In addition we found that for auto&& cs =3D expr; a) If we make auto&& cs =3D expr1.expr2 work by changing extending the= =20 lifetime of object if subobject is captured or having value r-value=20 overloads, the following transformation of code will introduce dangling=20 reference: after simple transformation: template delctype(auto) some_getter(T&& t) { auto&& cs =3D std::forward(t).expr; /// some code that causes this transformation to be applied return cs; } auto&& cs =3Df(expr1); b) auto&& cs =3D expr1; does not work if the expr1 will return by value= =20 some kind of expression object that bound references to temporaries (result= =20 of expression template) My personal opinion: I would recommend to add T&& value()&& because it is introducing the move= =20 semantics to be trigger seamlessly when a rvalue of optional is used in= =20 the code. The only drawback of this change is that it will still wont fix= =20 the auto&& cs =3D f().value() statement.=20 The only argument for T value()&& presented in this tread was that it=20 will make auto&& cs =3D f().value() work, but will cause performance=20 downgrade in other parts of code, combining that will fact that auto&& cs = =3D=20 expr; still may create an dangling reference in other context I do not find= =20 this a good motivation, especially when the main argument to make auto&& cs= =20 work is that it will allow you to capture any value type in generic code. --=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_543_20324844.1405156202697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
W dniu sobota, 12 lipca 2014 09:51:15 UTC+2 u=C5=BCytkowni= k David Krauss napisa=C5=82:

On 2014=E2=80=9307=E2=80=93= 12, at 3:27 PM, toma...@gmail.com = wrote:

3. The above cod= e does not work if if the passed Nullable type define && overload o= f operator* that returns by value.
    Lifetime of o= bject bound by auto&& value =3D *std::forward<Nullable>(= nullable); is not the same as lifetime of nullable.

Yes, but in that case what does the std::forward express? Reading that function, I would intui= tively expect addressof(value) to become a da= ngling reference. Any other interpretation requires thinking hard about wha= t did *not* happen to the result of forw= ard. It wasn=E2=80=99t passed to a function, but absence of some com= mon thing isn=E2=80=99t a good discriminating factor. (And in fact, it was = passed to a function, operator *.)

Because function_taking_pointer(p= ointer) passes a non-owning observer, nu= llable must live at least through that call. The intent is best expr= essed by simply value =3D * nullable; do= not use forward(). This can be declared= as auto && or auto & equivalently.

Am I missing= something?

No, your are ok, But let me us= e your previous example.
template< typename container_handle >
void operate_on_fifth_thing( container_handle && = ch ) {
    // Get o= nly the fifth element. We don=E2=80=99t need the rest; OK to free those res= ources.
    // However, i= f not assuming ownership, there=E2=80=99s no need to make a copy.
    auto && fifth_thi= ng =3D=3D ( * std::forward< container_handle >( ch ) )[ 5 ];

    // This is illustrated as a function call, but there might = as well be a loop here.
  &nbs= p; process_for_a_long_time( std::forward< decltype( thing ) >( fifth_= thing ) );
}

Th= en assume than we want add some log information:
template< typename container_handle >=
void operate_on_fifth_thing( conta= iner_handle && ch ) {
    // Get only the fifth element. We don=E2=80=99t need the res= t; OK to free those resources.
&nbs= p;   // However, if not assuming ownership, there=E2=80=99s no need to= make a copy.
    au= to && fifth_thing =3D=3D ( * std::forward< container_handle >= ( ch ) )[ 5 ];
    //Added some logging information
&n= bsp;   log_value_of_fifth_thing(fif= th_thing);

    // This is illustrated as a function cal= l, but there might as well be a loop here.
    process_for_a_long_time( std::forward< decltype( t= hing ) >( fifth_thing ) );
}

Then the user find the extract part of the function being to b= ig and move it to separate function:
template< typename container_handle >decltype(auto) get_f= ifth_thing(container_handle && ch)
{
  // Get only the fifth eleme= nt. We don=E2=80=99t need the rest; OK to free those resources.
  // However= , if not assuming ownership, there=E2=80=99s no need to make a copy.
  = auto && fifth_thing =3D=3D ( * std::forward< container_handle &g= t;( ch ) )[ 5 ];
  //Some loging
  log_value_of_fifth_thing= (fifth_thing);
  return fifth_thing;
}

template< typename container_handle >
void operate_on_fifth_thing( contain= er_handle && ch ) {
    // Get only the fifth element. We don=E2= =80=99t need the rest; OK to free those resources.
&n= bsp;      auto && f= ifth_thing =3D g= et_fifth_thing(s= td::forward< container_handle >( ch))

    // This is il= lustrated as a function call, but there might as well be a loop here.
    process_for_a_long_time( s= td::forward< decltype( thing ) >( fifth_thing ) );
<= font face=3D"Courier">}

I perceive all above transformation= as being acceptable and I think that the programmer expectation that the c= ode will still be valid after them is vald. Do you agree?

So lets analyze the situation:
  1. Status quo (no r-value overloa= ds for operator[] this time): The code is working before and after transfor= mation the same way.
  2. R-value reference r-value overload for op= erator[]: The code is working before and after transformation the same way.=
  3. Value r-value overload for operator[]: In the decltype(auto) get_fifth_thing(contain= er_handle && ch) the auto && fifth_thing =3D=3D ( * std::forward< contai= ner_handle >( ch ) )[ 5 ]; will cause fifth_thing to be type of<= br>      T&&, meaning the return type of f= unction will be reference and that will cause auto &= amp;& fifth_thing =3D get_fifth_thing(std::forward< container_handle >( ch)) to be a dangl= ing reference. The code will be broken by this transormation.

Breaki= ng the connection between lifetime of object and lifetime of expression tha= t should reference for subobject is not good think.


I would like= to summarize the arguments pros/cons that come in the thread. This is aime= d to be objective
  a) addition of T&& value()&&;     + makes a following code auto&& s =3D te= mporary_of_optional().value() use move semantics
    = ; + std::forward<T>(t).value() correctly forwards value as prvalue     - auto&& cs =3D temporary_of_optional().v= alue() still not works
  b) addition of T value()&&;
&nb= sp;    + makes a: auto&& cs =3D temporary_of_optiona= l().value()
     - breaks connection between lifetim= e of opt.value() and opt
     - introduce additional= temporaries (copies) if the places that captures temporary by const refere= nce: f(temporary_of_optional().value())

In addition we found that fo= r auto&& cs =3D expr;
    a) If we make auto&= & cs =3D expr1.expr2 work by changing extending the lifetime of object = if subobject is captured or having value r-value overloads, the following t= ransformation of code will introduce dangling reference:
  &nb= sp;     after simple transformation:
  &nb= sp;     template<typename T>
   = ;     delctype(auto) some_getter(T&& t)
&nbs= p;       {
     &= nbsp;     auto&& cs =3D std::forward<T>(t= ).expr;
           ///= some code that causes this transformation to be applied
  &nb= sp;        return cs;
  &nb= sp;     }

      &n= bsp; auto&& cs =3Df(expr1);
    b) auto&&= cs =3D expr1; does not work if the expr1 will return by value some kind of= expression object that bound references to temporaries (result of expressi= on template)

My personal opinion:
  I would recommend to add= T&& value()&& because it is introducing the move semantics= to be trigger seamlessly when a rvalue of optional<T> is used in the= code. The only drawback of this change is that it will still wont fix the = auto&& cs =3D f().value() statement.

  The only argume= nt for T value()&& presented in this tread was that it will make au= to&& cs =3D f().value() work, but will cause performance downgrade = in other parts of code, combining that will fact that auto&& cs =3D= expr; still may create an dangling reference in other context I do not fin= d this a good motivation, especially when the main argument to make auto&am= p;& cs work is that it will allow you to capture any value type in gene= ric code.

--

---
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_543_20324844.1405156202697-- .