220 32055 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: Re: Proxy objects and casting to rvalues Date: Sun, 9 Apr 2017 08:43:37 +0200 Lines: 287 Approved: news@gmane.org Message-ID: References: <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/alternative; boundary=94eb2c0954540d8d13054cb6300a X-Trace: blaine.gmane.org 1491720271 16054 195.159.176.226 (9 Apr 2017 06:44:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Apr 2017 06:44:31 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCP4374NRYKBBQVQU7DQKGQE7VFM3SA@isocpp.org Sun Apr 09 08:44:26 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cx6a5-0002H0-Cf for gclcip-std-proposals@m.gmane.org; Sun, 09 Apr 2017 08:44:13 +0200 Original-Received: by mail-pf0-f198.google.com with SMTP id 14sf14342162pfk.5 for ; Sat, 08 Apr 2017 23:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=mqlqvKlbIULJlpuxOP2snI9ByUPly+DVDTjJr1wX7hI=; b=fDDpldptjb8a1HzgL7ifOczqw5XZkAiQTUCT9XoZDsDnIDhMQhrBkMeB4dkV5QPccX K/8g3nQNZgaHuGvvJSwiDUE/7rWJYJqbR6jdfY3c11Nk/1X0xqZrM/u7iDsmFzao5YeO mVKrWm9tsUqSzTVLTyGmCNjn22Yr+4VfNESxW0x3aNz3tW7+0PZplYLTAPLA1PK+MbF/ /XXpLufetx1COyf1wQOXErnO4TEVXpmzHsSrewmt6PJeCb6dkygQIi9ae7bfxCdBNdoi ODXSFsy7G68YI46ZJNdDG+uv8IX3hPqZqgFGmAgV5HaUj8X3rBt5JYYQjo6qgvMaXgpo rWQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=mqlqvKlbIULJlpuxOP2snI9ByUPly+DVDTjJr1wX7hI=; b=hEge8Yh1vAK/kQmQKtPNZKQ5HrkQt4xluqL30oo0IVHvxnIn3mnPh7RLjNBd0uGmds C5r67tt4Vu6NhwsH1YSUImM6K3rMJjgWeTouKTgIUDdv0tf/R7YLMo4j/2xnL3Zamovm poZwNEkL0+8QBGufEVxgwJ89D1Jfu7JoqiYoTLCxnbs8/LPcSz/ERwyVT4Fyz9DvSfha 02DUFaFpvkQme6O5Yjzz4Rw6s/L06OKyUioHJLaUl+VYUpQAmf7CIEhfnJBOx+JkX6pL 8E84v+uI8z3BPFvru8yI6ynE5FbARW/snfAlx5zopfZIo7aTHTnr9h+kUhiP4H9MaVjI lV6A== X-Gm-Message-State: AN3rC/459h4ZuKKMRIp7BTPkr6YI+9iUHP59k5QUHfPPvVxG6egZOdwXUd2HL7ksgr0hzA== X-Received: by 10.99.157.11 with SMTP id i11mr3780082pgd.78.1491720258892; Sat, 08 Apr 2017 23:44:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.56.220 with SMTP id k28ls1706837ote.7.gmail; Sat, 08 Apr 2017 23:44:18 -0700 (PDT) X-Received: by 10.202.229.6 with SMTP id c6mr21787410oih.45.1491720258111; Sat, 08 Apr 2017 23:44:18 -0700 (PDT) Original-Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com. [2607:f8b0:4003:c06::22a]) by mx.google.com with ESMTPS id k25si4854372otb.56.2017.04.08.23.44.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 23:44:18 -0700 (PDT) Received-SPF: pass (google.com: domain of abv150ci@gmail.com designates 2607:f8b0:4003:c06::22a as permitted sender) client-ip=2607:f8b0:4003:c06::22a; Original-Received: by mail-oi0-x22a.google.com with SMTP id r203so121157042oib.3 for ; Sat, 08 Apr 2017 23:44:18 -0700 (PDT) X-Received: by 10.202.240.85 with SMTP id o82mr21826488oih.26.1491720257504; Sat, 08 Apr 2017 23:44:17 -0700 (PDT) Original-Received: by 10.74.68.70 with HTTP; Sat, 8 Apr 2017 23:43:37 -0700 (PDT) In-Reply-To: <9da2eb61-ab97-4b03-933e-da18139d77c0@isocpp.org> X-Original-Sender: abv150ci@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of abv150ci@gmail.com designates 2607:f8b0:4003:c06::22a as permitted sender) smtp.mailfrom=abv150ci@gmail.com; dmarc=pass (p=NONE sp=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:32055 Archived-At: --94eb2c0954540d8d13054cb6300a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My first paragraph is closed of not being understandable, sorry: The range-based-for is modifying the vector, since it's taking copies of the proxy objects. However, each proxy object is a reference-wrapper. And what is the property of a reference? That if I need to get a copy, I need a copy of the value type, not the reference itselft. I was reading some attempts to propose "auto operators" and the sort, but they seemed not satisfying. But, why not adding to the language the posibility of specifying dual types according to if the type is being used as reference or value type? On 9 April 2017 at 08:21, Aar=C3=B3n Bueno Villares wr= ote: > 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 =3D 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 =3D container.begin(); > > auto& ref =3D *it; // Compilation error, obvious. `reference` is a > rvalue. > auto const& ref =3D *it; // Ok, deduced as reference const& > > *it =3D something; // Ok, the proxy still takes control. > > auto value =3D *it; // Deduced as value_type! I have a copy of the re= al > value!! > reference value =3D *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 =3D bool; > using reference =3D bit_wrapper; > > reference ! value_type operator*() const { return > bit_wrapper(/**/); } > }; > > Or even better: > > template<...> > class vector > { > using value_type =3D bool; > using reference =3D 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 performin= g. > 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 movi= ng > the combined type). > > auto const& ref =3D *it; > auto val =3D 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 wh= at > types can be combined to (except that it must be convertible to, but a > conversion can be available without having that posible combination in mi= nd > 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 i= ts > value type). > auto v =3D val; // v is value_type. > > But it's harder to say what will be the different rules about the combine= d > 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, may= be > 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 > > . > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAMbYJhYK55BWCgLxcYHRzwo4MOgyFe68mnVcPvaTrAXyWUn= wOA%40mail.gmail.com. --94eb2c0954540d8d13054cb6300a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My first paragraph is closed of not being understandable, = sorry:

The range-based-for is modifying the vector, since it's t= aking copies of the proxy objects. However, each proxy object is a referenc= e-wrapper. And what is the property of a reference? That if I need to get a= copy, I need a copy of the value type, not the reference itselft. I was re= ading some attempts to propose "auto operators" and the sort, but= they seemed not satisfying. But, why not adding to the language the posibi= lity of specifying dual types according to if the type is being used as ref= erence or value type?

=C2=A0

On 9 April 2017 at 08:21, Aar=C3=B3n Bueno Villares= <abv150ci@gmail.com> wrote:
Hello! And sorry for my english.

Le= t's consider that example, taking from one comments of the Eric Niebler= 's blog:

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

The range-based for is modifying the ve= ctor, 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? Tha= t if I need to get a copy, a need a copy of the value type, not the referen= ce type. I have reading some attempts to propose auto deduction rules and t= he 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:
<= br>
=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_typ= e operator*() const { return reference(/**/); }
=C2=A0 =C2=A0 };<= /div>

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

=C2=A0 =C2=A0 auto& ref =3D *it; // Compilation= error, obvious. `reference` is a rvalue.
=C2=A0 =C2=A0 auto cons= t& ref =3D *it; // Ok, deduced as reference const&

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

=C2=A0 =C2=A0 auto value =3D *it; // Deduced = as value_type! I have a copy of the real value!!
=C2=A0 =C2=A0 re= ference value =3D *it; // Compilation error?

The r= eference type, of course, must be convertible to the "after !" ty= pe. 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 confus= ed with any other declarator.

For the `vector<b= ool>` case:

=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 referenc= e =3D bit_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_wr= apper ! 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 semantic= s 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 typ= e of the temporary object result of the casting. What changes is the effect= s 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 auto val =3D ref;

`ref` is deduced as `bit_wra= pper ! bool const&" (a.k.a bit_wrapper const& untill is copied= ), and val is deduced as "bool". The idea is to specify that a ty= pe 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 `typ= e` definition (inside the class). The `type` is unconnected to what types c= an 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 fir= st place). You could even create variables or returning objects of those co= mbined types.

=C2=A0 =C2=A0 wrapper ! value_type v= al(...); // I'm creating a true reference wrapper (wrapper, by itself, = is not 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 v= ery big change for a very specific case (proxy "things"), but I t= hink, 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 cur= rent STL'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-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/9da2= eb61-ab97-4b03-933e-da18139d77c0%40isocpp.org.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMbYJhYK55BWCgLx= cYHRzwo4MOgyFe68mnVcPvaTrAXyWUnwOA%40mail.gmail.com.
--94eb2c0954540d8d13054cb6300a-- .