220 32058 <6e471f98-15bf-4a85-8cc1-c4e0ea73a3d0@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proxy objects and casting to rvalues Date: Sun, 9 Apr 2017 11:00:35 -0700 (PDT) Lines: 270 Approved: news@gmane.org Message-ID: <6e471f98-15bf-4a85-8cc1-c4e0ea73a3d0@isocpp.org> References: <9da2eb61-ab97-4b03-933e-da18139d77c0@isocpp.org> <3bf83fd7-8b87-45ca-ac8b-3b856776acac@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_290_156605213.1491760835147" X-Trace: blaine.gmane.org 1491762891 12915 195.159.176.226 (9 Apr 2017 18:34:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Apr 2017 18:34:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBQ7NVHDQKGQEUSMI7EI@isocpp.org Sun Apr 09 20:34:41 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxHfd-0002j0-39 for gclcip-std-proposals@m.gmane.org; Sun, 09 Apr 2017 20:34:41 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id a185sf40268383ioe.13 for ; Sun, 09 Apr 2017 11:34:42 -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:in-reply-to:references: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=nQe/9fhFM+icqJ0Q1aNCBY2OaHK1ck+pmzN6nqsWsDg=; b=xm9xw2ll6PLgl84fVdFZOJBfPZ/eos7uI3KrRGHWgK5P2m5NaaCFELyZ/fjSc9b0eU LSJt3BhsgqoPOpW3A5oaiUYIVv39m+hjK9pJ+8kVVLEpUxUQF0hkcpJq9RWNCXMpncsM fkfcWOiqBTg5vEga97rVsaQqp/Cn8fMFaYJBTauzVa3xYYKKFfuiXT30Mpa4JPo9X48v jewbTMrUPCzyY+NqC8rJ5F2r+XATH4RrCPkJHp3oIDDlNOA7VCFybbU+ukPGJ+bZZ+iZ X9KTM5OmpXXHT5kOp22rmu2bFKIH9DyGjcmhqjDc+vVGjFBIJNc0AuxJVHkyzqnD+83k 2D+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references: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=nQe/9fhFM+icqJ0Q1aNCBY2OaHK1ck+pmzN6nqsWsDg=; b=ods1soD+nNKIVk7zSOJWBEbdnMg+rNizI8rdMyNUd3pEZ5VYABwKZGTOFcO6n/qF6i CX0iKENTTDkYB27yoY11CnA7xsZt1kT4TCW4+OwEsthzfZDPysvARrf1VJUOpyfLX2mC UZUKdanXg/Y7cuNZrtj+NdKwYnAzqW458Wze/pKH6z9EZVn/+IW6ZKuA4NZ4c07X1CBz sT/CnDMsHY7kVUK2zLtCpDSZm8J9EnDFTDi40w18MH/SZMIXGuQFrJoD7n7uuv6vrZ9W /3tCpZ9/1wdbLscAkVZGk2TsloOidhzGJxyiodOY/tKq3XNcjgaqI6NtrTg5SLMlCu1X AKwQ== 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:in-reply-to:references :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=nQe/9fhFM+icqJ0Q1aNCBY2OaHK1ck+pmzN6nqsWsDg=; b=nfl46nGti52mMv6nxMajRi4QYhcF2MyNaYoji0laxIOXx/UBbuqepyoXtAv/KrMOTJ imw+mxQJcNlbU7fyZzSYCPZ5hAmCNmqKlvRaQ/vNf4jkOQVHxlvQ5hKPxQio/rYNy3Zf l0Jj/jrkHampovcemw2bM1hm5qFHvVyhWCL62elmSjg5+EE+MUJXGAh4qfLGheWLPq2P UrmOyYMt7ZUhjsU/7wxbTOrDzPCnwLoDhzhb5iD3biQ4xGPgxy9o/21jJ+r9KjuPzsEL 9ONCAGoJ33iQ37sil6reoW2psmL/WefA9r9LrZ71FG/6o6+yIE5ewlJohuEBNt91qBeZ C97A== X-Gm-Message-State: AFeK/H1d/C1tpv+kE3Kkwk9MpCrJa0Co60jQLP/s1QjT0q3u4iotD9xF/gY19t3nPITexQ== X-Received: by 10.107.182.195 with SMTP id g186mr17660760iof.62.1491760836504; Sun, 09 Apr 2017 11:00:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.8.33 with SMTP id 30ls3488461oty.46.gmail; Sun, 09 Apr 2017 11:00:35 -0700 (PDT) X-Received: by 10.157.4.11 with SMTP id 11mr1030797otc.16.1491760835644; Sun, 09 Apr 2017 11:00:35 -0700 (PDT) In-Reply-To: <3bf83fd7-8b87-45ca-ac8b-3b856776acac@isocpp.org> X-Original-Sender: jmckesson@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:32058 Archived-At: ------=_Part_290_156605213.1491760835147 Content-Type: multipart/alternative; boundary="----=_Part_291_1946016572.1491760835148" ------=_Part_291_1946016572.1491760835148 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, April 9, 2017 at 11:51:46 AM UTC-4, Aar=C3=B3n Bueno Villares wr= ote: > > > On Sunday, 9 April 2017 16:30:28 UTC+2, Nicol Bolas wrote: >> >> What you're essentially asking is a modified form of something that has= =20 >> been discussed since `auto` came into existence: the ability to specify = the=20 >> type that will be deduced by `auto`. And proxy objects are the primary= =20 >> justification for it, whether it is proxy iterators or lazy evaluation o= f=20 >> expressions (you want `auto` to evaluate the lazy expression, not store = the=20 >> lazy intermediate). >> >> The best syntactic form I've seen this in is via a member function of th= e=20 >> form: >> >> class bit_wrapper >> { >> public: >> Typename operator auto() const { } >> }; >> >> Note that this allows you to do arbitrary work in the conversion section= ..=20 >> Though we might add an `=3D default` version which is equivalent to impl= icit=20 >> conversion via `return *this;`. >> >> > But I think it makes impossible to use `auto` to copy instances of that= =20 > type. For instance: > > ```C++ > struct wrapper { value_type operator auto() const { /**/ } }; > auto wrapper_obj =3D wrapper_factory::give_me_a_new_wrapper();=20 > ``` > Yes. That is in fact the whole point. Pre-`auto`, you would have had to explicitly state the name of the proxy=20 object's type if you wanted to store it. That prevented people from=20 accidentally storing proxy objects, since proxy types are usually internal= =20 objects who's names and data aren't really part of the interface. People=20 would instead use the base object's type and let implicit conversion handle= =20 things. With `auto`, you now get the proxy object's type. But that's not what you= =20 want most of the time. By giving a type an `operator auto` function, we revert back to the=20 pre-C++11 behavior: if you want to store the proxy object, you *must* name= =20 it. or any copy I have to do with the wrapper (or any intermediary function=20 > returning it), will be deduced as `value_type`. However, I'm still workin= g=20 > with a `wrapper`!! The "reference nature" has not been start yet. That=20 > conversion operator forces me to think a bit more anytime I want to use= =20 > `auto`. > Would it? Consider a string class that uses lazy expression evaluation. You do this: auto str =3D someString + otherString + moreString + StringType("literal"); What does the user expect `str` to be? Odds are very good that the user=20 wanted `str` to be a *string* value, not a lazy expression object.=20 Especially not a lazy expression object that references a temporary that=20 has now been destroyed. Pre-C++11, the user would have typed: StringType str =3D someString + otherString + moreString + StringType( "literal"); But post-C++11, the user would rather use `auto`. Except that they cannot,= =20 because this will give them something other than `StringType`. Note that by having `auto` deduce the proxy type, we introduce a bug: the= =20 temporary stored by the lazy expression object is destroyed. By using=20 `operator auto`, we prevent that bug from being accidentally encountered.= =20 It can *only* be encountered by explicitly naming the proxy object type.=20 And that makes it clear to everyone that there's a bug present. =20 > What if I want to bind the object to a reference, to modify the real=20 > object that is behind? > Then you have to name the type. You have to remember: you rarely want to play with proxy objects directly.= =20 They're mediators between some internal representation and the actual value= =20 you want to talk to. They're an implementation detail. The common case use for proxies is to convert them to their real type;=20 that's what people do with them 90% of the time. As such, if you don't want= =20 that, then you're going to have to name the type explicitly. --=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/6e471f98-15bf-4a85-8cc1-c4e0ea73a3d0%40isocpp.or= g. ------=_Part_291_1946016572.1491760835148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sunday, April 9, 2017 at 11:51:46 AM UTC-4, Aar=C3=B3n = Bueno Villares wrote:

On Sunday, 9 April 2017 16:30:28 UTC+2, Nicol Bolas= wrote:
What you&#= 39;re essentially asking is a modified form of something that has been disc= ussed since `auto` came into existence: the ability to specify the type tha= t will be deduced by `auto`. And proxy objects are the primary justificatio= n for it, whether it is proxy iterators or lazy evaluation of expressions (= you want `auto` to evaluate the lazy expression, not store the lazy interme= diate).

The best syntactic form I've seen this in is via a membe= r function of the form:

class b= it_wrapper
{
public:
=C2=A0 =C2=A0 Typename operator = auto()<= span style=3D"color:#000"> const { <conversion expression&g= t; }
};

Note that this allows you to do arbitrary work in= the conversion section. Though we might add an `=3D default` version which= is equivalent to implicit conversion via `return *this;`.


But I think it makes impossible to use `auto`= to copy instances of that type. For instance:

```C++
struct wrap= per { value_type operator auto() const { /**/ } };
auto wrapper_obj =3D= wrapper_factory::give_me_a_new_wrapper();=C2=A0
```

Yes. That is in fact the whole point.

Pre-`= auto`, you would have had to explicitly state the name of the proxy object&= #39;s type if you wanted to store it. That prevented people from accidental= ly storing proxy objects, since proxy types are usually internal objects wh= o's names and data aren't really part of the interface. People woul= d instead use the base object's type and let implicit conversion handle= things.

With `auto`, you now get the proxy object's type. But t= hat's not what you want most of the time.

By giving a type an `o= perator auto` function, we revert back to the pre-C++11 behavior: if you wa= nt to store the proxy object, you must name it.

or any cop= y I have to do with the wrapper (or any intermediary function returning it)= , will be deduced as `value_type`. However, I'm still working with a `w= rapper`!! The "reference nature" has not been start yet. That con= version operator forces me to think a bit more anytime I want to use `auto`= ..

Would it?

Consider a st= ring class that uses lazy expression evaluation. You do this:

auto str =3D someString + otherString + moreString + StringType("literal");

What does the user expect `= str` to be? Odds are very good that the user wanted `str` to be a string= value, not a lazy expression object. Especially not a lazy expression = object that references a temporary that has now been destroyed.

Pre-= C++11, the user would have typed:

StringType str =3D someString + otherString + moreString + StringT= ype("literal&qu= ot;);

But post-C++11, the user would rather use `auto`. = Except that they cannot, because this will give them something other than `= StringType`.

Note that by having `auto` deduce the proxy type, we in= troduce a bug: the temporary stored by the lazy expression object is destro= yed. By using `operator auto`, we prevent that bug from being accidentally = encountered. It can only be encountered by explicitly naming the pro= xy object type. And that makes it clear to everyone that there's a bug = present.
=C2=A0
What if I want to bind the object to a reference, to m= odify the real object that is behind?

Then you have to name the type.

You have to remember: you rare= ly want to play with proxy objects directly. They're mediators between = some internal representation and the actual value you want to talk to. They= 're an implementation detail.

The common case use for proxies is= to convert them to their real type; that's what people do with them 90= % of the time. As such, if you don't want that, then you're going t= o have to name the type explicitly.

--
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/6e471f98-15bf-4a85-8cc1-c4e0ea73a3d0= %40isocpp.org.
------=_Part_291_1946016572.1491760835148-- ------=_Part_290_156605213.1491760835147-- .