220 2765 <180b4f3b-b170-442b-923f-584e861602fb@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: optional references -- take 2 Date: Thu, 7 Feb 2013 00:24:30 -0800 (PST) Lines: 213 Approved: news@gmane.org Message-ID: <180b4f3b-b170-442b-923f-584e861602fb@isocpp.org> References: <8d57e9e9-e4cc-441c-abeb-e6526531fad5@isocpp.org> <13f19963-066b-4170-a6f2-eb90bed29be1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_487_2162560.1360225470251" X-Trace: ger.gmane.org 1360225471 530 80.91.229.3 (7 Feb 2013 08:24:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Feb 2013 08:24:31 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBPWJZWEAKGQENMT7JRY@isocpp.org Thu Feb 07 09:24:52 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f70.google.com ([209.85.212.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U3Mmo-0005hh-A9 for gclcip-std-proposals@m.gmane.org; Thu, 07 Feb 2013 09:24:50 +0100 Original-Received: by mail-vb0-f70.google.com with SMTP id s24sf2941175vbi.5 for ; Thu, 07 Feb 2013 00:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=wS+LYzi0mNjkBi4jnJr2hXixNKccxTWS4xdUTyP/xmk=; b=M7DHVudzuyalfJoeeg1GL5sJON8RugrESjJYUQwdHw2as1yJvhYbYEsJgCzgC/uJ8C h8ADh/R6MDg06eWZlnX6kiJiv7siadDGWHACdHBXTL5YhljrJmaHbGGaxVvuV9j/vBOE vP3GBUog1K3MGH0U9FqZVaqRLGyeO3QYAmTHDKqD5G0Yw4W6S0+BiruBGjZ5C8sLmlrF GTJbUst5XJ6rWH4WMqJbCkJAsPaZgIicVdEDaHc7SxYsC7Nfj9de89Sg7S5O0jtdVt8r c5Jg3Xb3hAJMJMz0Lpeu3yQ7YiYDz5UaRr6Oaof0Ah8Iljoc3Qmy1vlsE4GkmbeX8C5G HYdA== X-Received: by 10.236.82.102 with SMTP id n66mr180698yhe.28.1360225471019; Thu, 07 Feb 2013 00:24:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.127.177 with SMTP id nh17ls634509qeb.36.gmail; Thu, 07 Feb 2013 00:24:30 -0800 (PST) X-Received: by 10.49.127.198 with SMTP id ni6mr26916qeb.23.1360225470658; Thu, 07 Feb 2013 00:24:30 -0800 (PST) In-Reply-To: X-Original-Sender: akrzemi1@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:2765 Archived-At: ------=_Part_487_2162560.1360225470251 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu =B6roda, 6 lutego 2013 23:48:58 UTC+1 u=BFytkownik Tony V E napisa= =B3: > > On Wed, Feb 6, 2013 at 3:08 PM, Andrzej Krzemie=F1ski >=20 > wrote:=20 > >=20 > >> >>=20 > >=20 > > Let me just add one observation about mixed assignment. There is always= =20 > this=20 > > case where you are assigning to a disengaged optional reference. In tha= t=20 > > case assigning value is not possible because there is nothing to assign= =20 > it=20 > > to, so you have to rebind the reference. This makes the mixed assignmen= t=20 > > behave like assign_nonrebind():=20 > >=20 > > void assign_norebind(optional& optref, T& obj)=20 > > {=20 > > if (optref) *optref =3D obj;=20 > > else optref.emplace(obj);=20 > > }=20 > >=20 > > Which, as you observed, "is 2 totally different semantics ('targetting'= =20 > vs=20 > > 'set-value-of-target') rolled into one."=20 > >=20 > > Yes, I was thinking about that after hitting 'send'. Note then that:=20 > > optional oi; // disengaged=20 > oi =3D 123; //fails - how? exception?=20 > oi =3D j; //works, binds=20 > > And oi =3D j has completely different meaning when oi is engaged vs not.= =20 > Whereas that is not true for other optionals.=20 > > Or I guess maybe it is true. Any optional even for N that is=20 > NonRegular has the same assign semantics, right? ie=20 > > > if (optref) *optref =3D obj;=20 > > else optref.emplace(obj);=20 > > ie call assign, else call constructor.=20 > > It is just that for RegularTypes, those are the same thing:=20 > > T a; a =3D b; <=3D=3D> T a =3D b;=20 > Precisely so. And by using assignemt wherever possible, we get performance= =20 optimizations and usually a better exception safety guarantee. Note also that optional provides function emplace(), which is similar to=20 optional's assignment but never uses T's assignment. =20 > > But for NonRegular types, particularly references, it may not be the=20 > same. I just find it scary on references. ...Which brings us back to=20 > why you disabled it. Yet you are only disabling it for references,=20 > not for all NonRegular types. So maybe you shouldn't special case=20 > references. If you put any NonRegular types into optional, you get=20 > what you expect/deserve.(?)=20 > There is some difference between any non-regular type and a reference.=20 template optional (its primary variant) gives you a well defined behavior:= =20 we will use T's assignment in such cases and T's copy ctor in these cases. For a non-regular object type, given the definition of optional<>, you just= =20 get what you want - as you said above. If we use a primary template and=20 instantiate it with T& it does not work, it needs a specialization. If we= =20 specialize, we need to re-define the semantics... ....And there is no good way to do it. Therefore, since every semantics of= =20 assignment are confusing, we chose not to provide it. But the feedback from= =20 the Committee was to put it back... --=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/?hl=3Den. ------=_Part_487_2162560.1360225470251 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu =B6roda, 6 lutego 2013 23:48:58 UTC+1 u=BFytkownik Tony V E = napisa=B3:
On Wed, Feb 6, 2013 = at 3:08 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com> wrote= :
>
>> >>
>
> Let me just add one observation about mixed assignment. There is a= lways this
> case where you are assigning to a disengaged optional reference. I= n that
> case assigning value is not possible because there is nothing to a= ssign it
> to, so you have to rebind the reference. This makes the mixed assi= gnment
> behave like assign_nonrebind():
>
> void assign_norebind(optional<T&>& optref, T& ob= j)
> {
>    if (optref) *optref =3D obj;
>    else        optref.emplace(obj);
> }
>
> Which, as you observed, "is 2 totally different semantics ('target= ting' vs
> 'set-value-of-target') rolled into one."
>

Yes, I was thinking about that after hitting 'send'.  Note then th= at:

optional<int &> oi; // disengaged
oi =3D 123; //fails - how? exception?
oi =3D j; //works, binds

And oi =3D j has completely different meaning when oi is engaged vs not= ..
 Whereas that is not true for other optionals.

Or I guess maybe it is true.  Any optional<N> even for N tha= t is
NonRegular has the same assign semantics, right? ie

>    if (optref) *optref =3D obj;
>    else        optref.emplace(obj);

ie call assign, else call constructor.

It is just that for RegularTypes, those are the same thing:

T a; a =3D b;  <=3D=3D> T a =3D b;

Precisely so. And by using assignemt wherever pos= sible, we get performance optimizations and usually a better exception safe= ty guarantee.

Note also that optional provides function emplace(), w= hich is similar to optional's assignment but never uses T's assignment.
=  

But for NonRegular types, particularly references, it may not be the
same.  I just find it scary on references.  ...Which brings u= s back to
why you disabled it.  Yet you are only disabling it for references= ,
not for all NonRegular types.  So maybe you shouldn't special case
references.  If you put any NonRegular types into optional, you ge= t
what you expect/deserve.(?)

There is some difference between any non-regular = type and a reference.

template optional (its primary variant) gives= you a well defined behavior: we will use T's assignment in such cases and = T's copy ctor in these cases.

For a non-regular object type, given t= he definition of optional<>, you just get what you want - as you said= above. If we use a primary template and instantiate it with T& it does= not work, it needs a specialization. If we specialize, we need to re-defin= e the semantics...

...And there is no good way to do it. Therefore, = since every semantics of assignment are confusing, we chose not to provide = it. But the feedback from the Committee was to put it back...

--
 
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-pro= posals/?hl=3Den.
 
 
------=_Part_487_2162560.1360225470251-- .