220 32054 <9da2eb61-ab97-4b03-933e-da18139d77c0@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Aar=C3=B3n_Bueno_Villares?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Proxy objects and casting to rvalues Date: Sat, 8 Apr 2017 23:21:02 -0700 (PDT) Lines: 212 Approved: news@gmane.org Message-ID: <9da2eb61-ab97-4b03-933e-da18139d77c0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4_186886583.1491718862126" X-Trace: blaine.gmane.org 1491718868 22048 195.159.176.226 (9 Apr 2017 06:21:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Apr 2017 06:21:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCP4374NRYKBBTVFU7DQKGQEPGLQ5IA@isocpp.org Sun Apr 09 08:21:03 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cx6DZ-0004Ql-U1 for gclcip-std-proposals@m.gmane.org; Sun, 09 Apr 2017 08:20:58 +0200 Original-Received: by mail-qk0-f197.google.com with SMTP id p8sf32970389qkh.2 for ; Sat, 08 Apr 2017 23:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=1m21HVafb36C+8teaARM6iBBnrJ9QVB2X3D+70DhPZ0=; b=neyE3nVFv+StSG40yO63n5U3TZQjI/RKby2bvh73cFfLReUNtJMDszRm3AZ1qWq7jp KEpxwh77rIhzdoP4Cf7SZR2D4kr9sAjX2ORJHb+bIoBuB9IL70IPWOGNuegHWPZjtDjD SangX9UXeR03kZG47amusJ6cvZanxI9QnSohMLtt7DvN1QKLuL818JxWCg7GXa0R1q1a QmCrxeYllMY4vTi2EYSpJq9K+YLvP7snQlueqapa0Kzm+yEtPSz044oaZ5eKwwTHRkA+ nhaH6d9/ilKSi4DyrVG94NXsGPwRHsFKJYrjOwoTikF17ojn2gloy+g1Ofv/tvYPsXzv eT0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=1m21HVafb36C+8teaARM6iBBnrJ9QVB2X3D+70DhPZ0=; b=rk53osXdL/5pg/trUsPX76uGGpEs/AzTL1osFTiKIWcAtHjGVhMzEfRf06Y4uippGh Ox24RPTKftXg8D6alKm8EVG+e7fkNgBcQUUTsRfY13yk3twgG/2GX7f2hNkR9SQIynJS QJ9MQuqZpmJzMU8wkkyPbg9gqmqzndM8rcnRrCphJXVxrbN79LEUxY3+QWYPJZBQXSlm qbLJUsuE6Ybsa5avD/9tXlHK6UZUGezQW14TtDCtP6dL/eKGWD8iMI/2zx5UpnzAc2rB /yxULuAukHh+bYQF1AW6iGuWHOAwL/cUduadSNvZzcjbZyi97C1BQx6AHJFFqtVe3K/B AqnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=1m21HVafb36C+8teaARM6iBBnrJ9QVB2X3D+70DhPZ0=; b=CelxqOS8S+lV+aU0mof5/Dfj/v0tYgY47/jsU0cD87QCA+h8hGCYpYqOAfeVn9FS7R JQIIV1nMNAgpDyhL4HR0GkGzp7/rTPaxCVkAFmm/N7MvLByP05b1HiM+1zZuhdshLIl2 eN0AnqTglqq0KM67Fpm8h7avqTIWKDL5QrbBoENnJq7VbjfKX3rKnTH+WYSJw8JV3dK5 pb2CH2Q1uKpoc/jZXUmBzWENak82gmPa087AHYb7OynedcR44/D122BzZH5HmfvHDsWf FlncwLHPb/fJt7wbVb4g6ZRvoZgO+YxVN443Fie0iPPK+FkuJ8OQbDHoom2tSizJCH6T 6e1Q== X-Gm-Message-State: AFeK/H2pAra+qrjA/1ElWAHUAi4PmgSNLSt3WRkAEYNRcBZDggPdI7ucIEv1exOdr+E9AQ== X-Received: by 10.200.41.78 with SMTP id z14mr17069475qtz.23.1491718863468; Sat, 08 Apr 2017 23:21:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.34.49 with SMTP id o46ls3165696ota.12.gmail; Sat, 08 Apr 2017 23:21:02 -0700 (PDT) X-Received: by 10.157.80.130 with SMTP id b2mr217553oth.1.1491718862551; Sat, 08 Apr 2017 23:21:02 -0700 (PDT) X-Original-Sender: abv150ci@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:32054 Archived-At: ------=_Part_4_186886583.1491718862126 Content-Type: multipart/alternative; boundary="----=_Part_5_1288154988.1491718862127" ------=_Part_5_1288154988.1491718862127 Content-Type: text/plain; charset=UTF-8 Hello! And sorry for my english. Let's consider that example, taking from one comments of the Eric Niebler's blog: std::vector v{true,false,true}; for (auto i : v) i = false; // (1) The range-based for is modifying the vector, since it's taking copies of the proxy object. However, the proxy object is a reference-wrapper. And what is the property of a reference? That if I need to get a copy, a need a copy of the value type, not the reference type. I have reading some attempts to propose auto deduction rules and the sort, but the seems not satisfaying But, why not adding to the language the posibility of specifying a dual type according if they is being used as reference or value type? For example: struct Iterator { // other code value_type T; reference R; reference ! value_type operator*() const { return reference(/**/); } }; Iterator it = container.begin(); auto& ref = *it; // Compilation error, obvious. `reference` is a rvalue. auto const& ref = *it; // Ok, deduced as reference const& *it = something; // Ok, the proxy still takes control. auto value = *it; // Deduced as value_type! I have a copy of the real value!! reference value = *it; // Compilation error? The reference type, of course, must be convertible to the "after !" type. I have given the example with the iterator case, but it can be applied to any non-void function. The choice of `!` is because no specific reason. I just thought that it can be easier for parsers, since can't be confused with any other declarator. For the `vector` case: template<...> class vector { using value_type = bool; using reference = bit_wrapper; reference ! value_type operator*() const { return bit_wrapper(/**/); } }; Or even better: template<...> class vector { using value_type = bool; using reference = bit_wrapper ! value_type; reference operator*() const { return bit_wrapper(/**/) } }; That way, the semantics of the `reference` and `value_type` are keep separated. It just specifies what happens when copying. The `auto` deduction rules aren't modified, since, when copying, a cast is performing. What is seen by auto is the type of the temporary object result of the casting. What changes is the effects of the copy operation, that before doing a copy, a casting is performed (I don't know what to say about moving the combined type). auto const& ref = *it; auto val = ref; `ref` is deduced as `bit_wrapper ! bool const&" (a.k.a bit_wrapper const& untill is copied), and val is deduced as "bool". The idea is to specify that a type must fallback to another type when using it as value, and the type must be of course convertible to it. That shouldn't be specified in the `type` definition (inside the class). The `type` is unconnected to what types can be combined to (except that it must be convertible to, but a conversion can be available without having that posible combination in mind in the first place). You could even create variables or returning objects of those combined types. wrapper ! value_type val(...); // I'm creating a true reference wrapper (wrapper, by itself, is not a true reference till combined with its value type). auto v = val; // v is value_type. But it's harder to say what will be the different rules about the combined types in the different expressions it could appear, and I know that is a very big change for a very specific case (proxy "things"), but I think, if the rules are well design and very enclosed to only what it's needed, maybe it can be, maybe and at least, arguable, without touching current STL's algorithm implementations. -- 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 email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9da2eb61-ab97-4b03-933e-da18139d77c0%40isocpp.org. ------=_Part_5_1288154988.1491718862127 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello! And sorry for my english.

Let= 9;s consider that example, taking from one comments of the Eric Niebler'= ;s blog:

=C2=A0 =C2=A0 std::vector<bool> v{tr= ue,false,true};
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 for (= auto i : v)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 i =3D false; =C2=A0// (1)=

The range-based for is modifying the vector= , since it's taking copies of the proxy object. However, the proxy obje= ct is a reference-wrapper. And what is the property of a reference? That if= I need to get a copy, a need a copy of the value type, not the reference t= ype. I have reading some attempts to propose auto deduction rules and the s= ort, but the seems not satisfaying But, why not adding to the language the = posibility of specifying a dual type according if they is being used as ref= erence or value type?

For example:

<= /div>
=C2=A0 =C2=A0 struct Iterator
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // other code
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 value_type T;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference R;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference ! value_type op= erator*() const { return reference(/**/); }
=C2=A0 =C2=A0 };

=C2=A0 =C2=A0 Iterator it =3D container.begin();
=

=C2=A0 =C2=A0 auto& ref =3D *it; // Compilation err= or, obvious. `reference` is a rvalue.
=C2=A0 =C2=A0 auto const&am= p; ref =3D *it; // Ok, deduced as reference const&

=
=C2=A0 =C2=A0 *it =3D something; // Ok, the proxy still takes control.=

=C2=A0 =C2=A0 auto value =3D *it; // Deduced as v= alue_type! I have a copy of the real value!!
=C2=A0 =C2=A0 refere= nce value =3D *it; // Compilation error?

The refer= ence type, of course, must be convertible to the "after !" type. = I have given the example with the iterator case, but it can be applied to a= ny non-void function. The choice of `!` is because no specific reason. I ju= st thought that it can be easier for parsers, since can't be confused w= ith any other declarator.

For the `vector<bool&= gt;` case:

=C2=A0 =C2=A0 template<...>
=
=C2=A0 =C2=A0 class vector<bool, ...>
=C2=A0 =C2=A0 {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using value_type =3D boo= l;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using reference =3D b= it_wrapper;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0reference ! value_type operator*() const { return bit_wrapper(/**/); }
=C2=A0 =C2=A0 };

Or even better:

=C2=A0 =C2=A0 template<...>
=C2=A0 = =C2=A0 class vector<bool, ...>
=C2=A0 =C2=A0 {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using value_type =3D bool;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using reference =3D bit_wrapper= ! value_type;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0reference operator*() const { return bit_wrapper(/**/) }
= =C2=A0 =C2=A0 };

That way, the semantics of = the `reference` and `value_type` are keep separated. It just specifies what= happens when copying. The `auto` deduction rules aren't modified, sinc= e, when copying, a cast is performing. What is seen by auto is the type of = the temporary object result of the casting. What changes is the effects of = the copy operation, that before doing a copy, a casting is performed (I don= 't know what to say about moving the combined type).

=C2=A0 =C2=A0 auto const& ref =3D *it;
=C2=A0 =C2=A0 a= uto val =3D ref;

`ref` is deduced as `bit_wrapper = ! bool const&" (a.k.a bit_wrapper const& untill is copied), an= d val is deduced as "bool". The idea is to specify that a type mu= st fallback to another type when using it as value, and the type must be of= course convertible to it. That shouldn't be specified in the `type` de= finition (inside the class). The `type` is unconnected to what types can be= combined to (except that it must be convertible to, but a conversion can b= e available without having that posible combination in mind in the first pl= ace). You could even create variables or returning objects of those combine= d types.

=C2=A0 =C2=A0 wrapper ! value_type val(..= ..); // I'm creating a true reference wrapper (wrapper, by itself, is no= t a true reference till combined with its value type).
=C2=A0 =C2= =A0 auto v =3D val; // v is value_type.

But it'= ;s harder to say what will be the different rules about the combined types = in the different expressions it could appear, and I know that is a very big= change for a very specific case (proxy "things"), but I think, i= f the rules are well design and very enclosed to only what it's needed,= maybe it can be, maybe and at least, arguable, without touching current ST= L's algorithm implementations.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/9da2eb61-ab97-4b03-933e-da18139d77c0= %40isocpp.org.
------=_Part_5_1288154988.1491718862127-- ------=_Part_4_186886583.1491718862126-- .