220 11894 <08854dbb-6997-4fee-bbab-68fb64fbfbbf@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 06:25:18 -0700 (PDT) Lines: 141 Approved: news@gmane.org Message-ID: <08854dbb-6997-4fee-bbab-68fb64fbfbbf@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> <1b70888c-eb6a-49e5-b254-a475ef015570@isocpp.org> <6CFC366C-D196-4A2E-B4EE-D1E6B26AE6C0@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5_15173946.1405171518705" X-Trace: ger.gmane.org 1405171530 13788 80.91.229.3 (12 Jul 2014 13:25:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 13:25:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBP7OQSPAKGQEUNHCRKA@isocpp.org Sat Jul 12 15:25:23 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f69.google.com ([209.85.192.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5xIn-0002cC-Cw for gclcip-std-proposals@m.gmane.org; Sat, 12 Jul 2014 15:25:21 +0200 Original-Received: by mail-qg0-f69.google.com with SMTP id j107sf5808997qga.8 for ; Sat, 12 Jul 2014 06:25:20 -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=2l1sB/+ccZvpC00SvfExGy4Ka7+ewakxPV3WbH+eB/A=; b=kd76crWPK6/93H8O1o8JuueouTe/4Mb1dhzC8EktekvxfmcRCoXiO8o70UvZBlE+hn qb0J7nusWu4zxcGCJttZIXk48P5ZI6ghpYH7oj7r6IZVAmmCx1E3O1jHflhzbni79opv V7kpEQG9Uvb6WPqDZSy9b0YLLtu3b5Kt7CAzn4zgHA6mvSq3OQPzHyyv4YyZjVn/ef98 RXnz9U9I6xCsI5swuaiAcFz9qH5bWd8frquLmtjQarkS7s+k4lUX2gmzor5IaWkMm+dE BOZYHWq9NouoXCfsMMeQZ22GqhX+FgneOmH4ieRRa5+d3SmZYDXerLsGWazcb/B/1tI/ l1pQ== 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=2l1sB/+ccZvpC00SvfExGy4Ka7+ewakxPV3WbH+eB/A=; b=hmaf9gEFha42AfkG7rr3B/cy0vuur7sKuVGY04wK3hYTgFyIhUHYEDBbKhLkzhgfC2 MXbtNZ4YvEH9AWGPJmH9yELH0fGW764TRVQUSpqPqYTVGwRdq7l8NDz3gqjmYEgfCrQ5 4zdAkTPz7JLgp20JTb+ZmLwaLFDDmGQ6c+qjcmQL7zrqOhCDmhkjgjv/gn3XZewmEp6w sZ5RzX46xEgDaus0PtaPS/aBotYbCCpgyMvhuHlT/lpWuv6TqMx+cJWkf8wxlewr3J9/ zNTO3pe9ijqAzdmYDhd8XwqBUY3e7o5o3wxzBSgi98PuY+msRbfL4lzPTBkG0e9xTjWW sVNg== X-Gm-Message-State: ALoCoQkAVwwfD4TPhTCJEJlwq4Vvy5aGzRal1M7nNTDEuqMWM5KqRW5lZmavW3tqPjpURPOaNK+u X-Received: by 10.224.127.6 with SMTP id e6mr2482893qas.3.1405171520272; Sat, 12 Jul 2014 06:25:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.236.135 with SMTP id uu7ls652234obc.41.gmail; Sat, 12 Jul 2014 06:25:19 -0700 (PDT) X-Received: by 10.182.85.198 with SMTP id j6mr102obz.35.1405171519367; Sat, 12 Jul 2014 06:25:19 -0700 (PDT) In-Reply-To: <6CFC366C-D196-4A2E-B4EE-D1E6B26AE6C0@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:11894 Archived-At: ------=_Part_5_15173946.1405171518705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > Maybe this is what came through the presentation of examples, but the cor= e=20 > argument is the principle that an xvalue is dead (and reusable) once it= =20 > goes into any function. I don=E2=80=99t think libraries scale well with a= ny other=20 > rule, although functions that =E2=80=9Conly=E2=80=9D perform access do in= tuitively seem=20 > special. > > Actually in this thread we presented a lot of examples for which the=20 generic code (I assume that by libraries you mean the one using generic=20 code), with the set of following rules: a) auto&& cs does not work in generality b) we have rvalue reference overloads return rvalue references and was requiring separte treatment for rvalues and lvalues or imposing=20 performance loss when: c) we have rvalue reference overloads return value Futhermore the second set of rules failed to quaranty that auto&& cs will= =20 always work. No examples for situation when T&& op()&& overloads breaks something that works before= =20 their introduction was presented. So in my opinion this treads rather shows up that the T&& op()&& and zero= =20 guarantee for auto&& is set of rule with the libraries scares well. As an example, if the code I have presented will be rewritten using with=20 instead of auto&&: template< typename container_handle > decltype(auto) get_fifth_thing(container_handle && ch) { return with(( * std::forward< container_handle >( ch ) )[ 5 ] [](auto&& fifth_thing) { log_value_of_fifth_thing(fifth_thing); return fifth_thing; }); } template< typename container_handle > void operate_on_fifth_thing( container_handle && ch ) { with(get_fifth_thing(std::forward< container_handle >( ch)) [](auto&& fifth_thing){ process_for_a_long_time( std::forward< decltype( thing ) >(=20 fifth_thing ) ); }); =20 } The code works in any case, even if the container_handle is lazy evaluator= =20 returning by value.=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_5_15173946.1405171518705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Maybe this is what came through the pr= esentation of examples, but the core argument is the principle that an xval= ue is dead (and reusable) once it goes into any function. I don=E2=80=99t t= hink libraries scale well with any other rule, although functions that =E2= =80=9Conly=E2=80=9D perform access do intuitively seem special.
<= br>
Actually in this thread we presented= a lot of examples for which the generic code (I assume that by libraries y= ou mean the one using generic code), with the set of following rules:
&n= bsp;  a) auto&& cs does not work in generality
  = b) we have rvalue reference overloads return rvalue references
and was = requiring separte treatment for rvalues and lvalues or imposing performance= loss when:
   c) we have rvalue reference overloads return va= lue
Futhermore the second set of rules failed to quaranty that auto&= & cs will always work. No examples
for situation when T&& op= ()&& overloads breaks something that works before their introductio= n was presented.

So in my opinion this treads rather shows up that t= he T&& op()&& and zero guarantee for auto&& is set = of rule with the libraries scares well.

As an example, if the code I= have presented will be rewritten using with instead of auto&&:
=
template< typenam= e container_handle >
decltype(auto) get_fifth_thing(container_handle && = ch)
{
  return with(( * std::forward< container_handle >( ch ) )[ 5 ]
&nb= sp;   [](auto&& fifth_thing) {
      log_value_of_fifth_thing(fifth_thing);
       return fifth_thing;
  =   });
}

template<= typename container_handle >
void operate_on_fifth_thing( container_handle &= & ch ) {
    with(get_fifth_thing(std::forward< container_handle >( ch))      [](auto&& fifth_thing){
=         process_for_a_long_time( std::forward< decltype( th= ing ) >( fifth_thing ) );
      });   
}

The code works in any case, even if the cont= ainer_handle is lazy evaluator returning by value.

--

---
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_5_15173946.1405171518705-- .