220 11801 <74CEDDAC-1B1B-4F06-9E58-2F025921FE55@gmail.com> 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 18:00:49 +0800 Lines: 151 Approved: news@gmane.org Message-ID: <74CEDDAC-1B1B-4F06-9E58-2F025921FE55@gmail.com> 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> 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=_B46A0D6D-F4A5-4917-8000-88BB4C0A21D4" X-Trace: ger.gmane.org 1404986468 19253 80.91.229.3 (10 Jul 2014 10:01:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 10:01:08 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBV6I7GOQKGQETICJX4Y@isocpp.org Thu Jul 10 12:00:59 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5B9t-0002sV-0m for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 12:00:57 +0200 Original-Received: by mail-pa0-f71.google.com with SMTP id eu11sf58425869pac.2 for ; Thu, 10 Jul 2014 03:00:55 -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=9qvJXvbaVv8pYBgFS27olJOvzeCUxx2wWW7Q3lve2Uw=; b=LJFdMsx+6MkPHeLuKsMOZfwVGA1RntkSo9namMV/YcO53h6lKR9t0cgEwoIixIhdvf suF2vPCitwmNsK12YH/Y2qBwWYGuj1Ps8p7ZoZzClGP0y9orwqFqLwwmzXQOAItxHO7l CpA1lwiPIDKOLFwPGFrup0FnPv7Imof+TNanYkhfev1n/+U/qkRN4n2h9OpsxMLNkphs PWRB2z1os7Fekk4LV2YKTz9kDJzQ7N6mbl/WdGSgAmh0Y86YZooCNI4fzmwagOJq20MB lXyCjPUKZcioPGFEhw7tp2lqdg8c8bBoJM7A8yS5ElRRlZAtQF89Wy0zdH441EwxDKs6 Cvbg== X-Gm-Message-State: ALoCoQlOMTbw7T/lw/atZzfzyTCJciBAPA/UafnVy47Jpav8IirkwkBp/mOUgEu0RIzFhvYuURFN X-Received: by 10.66.102.9 with SMTP id fk9mr20882974pab.2.1404986455767; Thu, 10 Jul 2014 03:00:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.23.101 with SMTP id l5ls1338080igf.9.canary; Thu, 10 Jul 2014 03:00:55 -0700 (PDT) X-Received: by 10.43.129.74 with SMTP id hh10mr51725411icc.48.1404986454985; Thu, 10 Jul 2014 03:00:54 -0700 (PDT) Original-Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [2607:f8b0:4001:c05::231]) by mx.google.com with ESMTPS id z6si75746007icm.20.2014.07.10.03.00.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 03:00:54 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c05::231 as permitted sender) client-ip=2607:f8b0:4001:c05::231; Original-Received: by mail-ig0-f177.google.com with SMTP id r10so2883394igi.4 for ; Thu, 10 Jul 2014 03:00:54 -0700 (PDT) X-Received: by 10.42.240.20 with SMTP id ky20mr1011914icb.97.1404986454881; Thu, 10 Jul 2014 03:00:54 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.43]) by mx.google.com with ESMTPSA id n10sm23729618igv.21.2014.07.10.03.00.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 03:00:54 -0700 (PDT) In-Reply-To: <072cf8b4-4c74-438e-9999-0aab13bf3182@isocpp.org> 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::231 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:11801 Archived-At: --Apple-Mail=_B46A0D6D-F4A5-4917-8000-88BB4C0A21D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-07-10, at 5:29 PM, tomaszkam@gmail.com wrote: > Which makes following invoaction f(expr.value()) where takes T by const& = and expr is value of type optional, introducing has additonal possibly-c= opy dependin on expr being lvalue or r-value. And makes using optional in g= eneric context when perfect forwardin us used a pain. I propose to set of m= ethods to look like: > T& value() &; > T const& value() const &; > T&& value() &&; > To achieve consistency with std::get function or even simple meber acces= with procudes same cateogry value for subobject. Here's the issue: std::get cannot reliably produce the same value category = as a simple member access, because functions (in C++11, at least) cannot di= stinguish xvalue arguments from prvalues. A member access on a prvalue prod= uces a prvalue, but a member access get< N >( prvalue() ).mem produces an x= value. 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 lvalu= e. 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 yie= lds xvalue. Usage in the example context: return u ? std::forward(fv)(forward_component(*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 vector::front and unique_= ptr::operator* with equal aplomb, and we don't even have to add rvalue refe= rence overloads to anything. (Although doing so may still be a good idea.) > If the original set of the methods was: > T value() const; > I would arrge tthe the new function should be declared as: > T value() const; > T value() &&; > But this is not=20 ? By the way, you might as well keep the const && overload. "&&" and "const &= &" usually have identical semantics. It is possible to have an expression o= f const class type. --=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=_B46A0D6D-F4A5-4917-8000-88BB4C0A21D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 2014&= ndash;07–10, at 5:29 PM, tomas= zkam@gmail.com wrote:

Which makes following invoaction f(expr.value()) where takes T by const&= amp; and expr is value of type optional<T>, introducing has additonal= possibly-copy dependin on expr being lvalue or r-value. And makes using op= tional in generic context when perfect forwardin us used a pain. I 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 mebe= r acces with procudes same cateogry value for subobject.

Here’s the issue: std::get cannot reliably pr= oduce the same value category as a simple member access, because functions = (in C++11, at least) cannot distinguish xvalue arguments from prvalues. A m= ember access on a prvalue produces a prvalue, but a member access get< N >( prvalue() ).mem produces an = xvalue.

Why not put the adjustment into the forwar= ding function itself?

templ= ate< typename owner_type, typename value_type >
std::enable_if_t< std::is_lvalue_reference< <= /font>owner_type >::value,
  =   value_type & >
forwar= d_component( value_type & v )
&= nbsp;   { return v; } // Container passed as lvalue yields a reference= to lvalue.

<= div>template< typename owner_type, typename value= _type >
std::enable_if_t< ! s= td::is_lvalue_reference< owner_type >::value,
<= div>    value_type && ><= /div>
forward_component( value_type & v )
    { return std::move( v )= ; } // Container passed as prvalue or xvalue yields xvalue.

Usage in the example context:

  return u ? std::forward<FV>(fv)(forward_co= mponent<U>(*u)) : std::forward<FN>(fn);

forward_component trusts the user th= at the function argument is owned by an object of the template argument typ= e. It handles vector::front and unique_ptr::operator* with equal aplomb, and we don&r= squo;t even have to add rvalue reference overloads to anything. (Although d= oing so may still be a good idea.)

If the original set  of the methods was:<= br>  T  value() const;
I would arrge tthe the new function sho= uld be declared as:
  T  value() const;
  T  valu= e() &&;
But this is not

?<= /div>

By the way, you might as well keep the const && overload. “&&” and “const &am= p;&” usually have identical semantics. It is possible to h= ave an expression of const class type.

--

---
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=_B46A0D6D-F4A5-4917-8000-88BB4C0A21D4-- .