220 2749 <13f19963-066b-4170-a6f2-eb90bed29be1@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: Wed, 6 Feb 2013 02:08:26 -0800 (PST) Lines: 520 Approved: news@gmane.org Message-ID: <13f19963-066b-4170-a6f2-eb90bed29be1@isocpp.org> References: <8d57e9e9-e4cc-441c-abeb-e6526531fad5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_98_19665365.1360145306280" X-Trace: ger.gmane.org 1360145309 10733 80.91.229.3 (6 Feb 2013 10:08:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Feb 2013 10:08:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBG6XZCEAKGQEKCQVKHA@isocpp.org Wed Feb 06 11:08:48 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ye0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U31vq-0003Gu-V0 for gclcip-std-proposals@m.gmane.org; Wed, 06 Feb 2013 11:08:47 +0100 Original-Received: by mail-ye0-f198.google.com with SMTP id l11sf1505797yen.5 for ; Wed, 06 Feb 2013 02:08:27 -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=wRF1y78vi3Mmrg3ssNOc6L5NPQ3K459CN8soIh29vAc=; b=fr863YwHnab9r91fnuxCuDwuxhHTeHObP/65jEYFM2Xwp+lULKjjlRFVzINsXVXWD0 lpnrmoVkX9Vt3oNeWiu+bk7+aJyJxVV8VZBcHknKkcTlNUkqywxJD3CwMkWyJZ/Vd/wG 0q9FiKQayDgMMWfG9KFW2qUPkFFPPJ5AT9ARVYAXJpONxaT0Fa9Puy3Ld7wY2GWelbQh JbLrQYZd6Ne+sTb+KOA3undlvGJJUnGW+FI3/cfBd08Sk0bLCWI5CmCeSJ1e+Mmd6xuM tSCROKRWc1X1I80II4fDRfxQvJNLWuBJeR0YbrrJxJ3QgLex4L7HMzhySLiEpaZPZWUh 82AA== X-Received: by 10.224.176.196 with SMTP id bf4mr9253347qab.4.1360145307666; Wed, 06 Feb 2013 02:08:27 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.74.234 with SMTP id x10ls294606qev.99.gmail; Wed, 06 Feb 2013 02:08:27 -0800 (PST) X-Received: by 10.49.116.1 with SMTP id js1mr2424806qeb.19.1360145307075; Wed, 06 Feb 2013 02:08:27 -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:2749 Archived-At: ------=_Part_98_19665365.1360145306280 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu wtorek, 5 lutego 2013 23:39:16 UTC+1 u=BFytkownik Tony V E napisa=B3= : > > On Tue, Feb 5, 2013 at 3:02 PM, Andrzej Krzemie=F1ski >=20 > wrote:=20 > >>=20 > >> Is optional a RegularType?=20 > >=20 > >=20 > > I am not sure how to answer the question. Different people have slightl= y=20 > > different expectations of a regular type.=20 > > That's why I cc'ed Sean Parent :-)=20 > > Let's go with Stepanov, via http://www.stepanovpapers.com/DeSt98.pdf=20 > and Elements of Programming (www.elementsofprogramming.com)=20 > > > optional has:=20 > >=20 > > default ctor=20 > > destructor=20 > > copy/move constructor (shallow)=20 > > copy/move assignment (shallow)=20 > > equality comparison (deep, provided that T is comparable)=20 > > it is not swappable yet, but I intend to add a shallow swap=20 > >=20 > > I am not not sure what semantic requirements a RegularType requires.=20 > > To summarize Stepanov, mainly the semantics of int w.r.t. copy,=20 > assignment, and equality:=20 > > T b =3D ...;=20 > T a =3D b;=20 > assert(a =3D=3D b);=20 > This holds, but -- so to say -- only by chance=20 > > T c =3D b;=20 > change(a);=20 > assert(c =3D=3D b && a !=3D b);=20 > =20 Well, this one is tricky. Given this criterion, would you say a raw pointer= =20 satisfies it? IOW, does change(a) also applies to changing the referred to= =20 (or pointed to) object? int i =3D 0; int j =3D 1; optional oi =3D i;=20 optional oj =3D oi; assert (oi =3D=3D oj); // holds optional ok =3D oi; oi =3D {j}; // this is the change(a) assert (ok =3D=3D oj); // holds assert (oj !=3D oi) // holds j =3D 0; assert (oj !=3D oi) // DOES NOT HOLD And this is what I call an "asynchronous change". The value of 'j'=20 shouldn't affect the axioms. > oh, and since I happen to always use construction above, I should=20 > mention assignment and construction yield the same results, ie:=20 > > T a; a =3D b; <=3D=3D> T a =3D b;=20 > This holds =20 > > (he also requires less-than, but we can ignore that here)=20 > operator< also works, with similar problems as operator=3D=3D =20 > > > The=20 > > value compared by operator=3D=3D is not under control of the optional= =20 > object: it=20 > > can change "asynchronously".=20 > > Let's limit our discussion to optionals over Ts where T is Regular. I=20 > agree there is not much we can do when T is not Regular.=20 > So in general, optional is Regular if T is Regular, I think. (?)=20 > The problem I (clumsily) describe also works for Regular T's: int i =3D 0; int j =3D 0; optional oi =3D i; optional oj =3D j; assert (oi =3D=3D oj); i =3D 9; // the "asynchronous change" assert (oi !=3D oj);=20 =20 > > > Also the copy/move operations are not=20 > > compatible with operator=3D=3D: the former are shallow, the latter is d= eep.=20 > >=20 > > That the part I'm wondering about. I guess the key thing is that even=20 > though T is regular, T & isn't, as the final a !=3D b assert fails.=20 > Using 'int' and 'int &' we get:=20 > > int target =3D 17;=20 > > int & b =3D target;=20 > int & a =3D b;=20 > assert(a =3D=3D b);=20 > > int & c =3D b;=20 > change(a);=20 > assert(c =3D=3D b && a !=3D b); // fails! as a =3D=3D b=20 > Yes, raw references are not regular. =20 > > So does optional have the same semantics as int & (at least=20 > when the optional is engaged)?=20 > Except optional allows rebinding, whereas int & does not.=20 > Given this assignment semantics, it is impossible to say if optional=20 references are 'like' raw references. They allow the same kind of departure= =20 from RegularType. One could say that the only purpose of raw references=20 (and therefore also optional references) is to depart from RegularType=20 requirements (especially: the "value separation") =20 > > Why not allow mixed assignment even?=20 > > optional oi =3D target;=20 > oi =3D 123;=20 > Here, you imply that the semantics would be non-rebinding: oi =3D 123 <=3D=3D> *oi =3D 123 (of course, if oi !=3D nullopt) But that would be inconsistent with converting constructor: which only=20 binds a reference. Also the existence of this assignment was the reason=20 that caused the first revision of Optional to be rejected by the Committee. > that would be consistent with int &.=20 > I guess it gets confusing with the rebinding?=20 > > int alternate =3D 21;=20 > int another =3D 35;=20 > oi =3D alternate;=20 > assert(target =3D=3D 21);=20 > oi =3D optional(another);=20 > oi =3D 42;=20 > assert(target !=3D 42);=20 > assert(another =3D=3D 42);=20 > rebinding mixed assignment is confusing -- true. Non-rebinding one is=20 inconsistent with the homogenous assignment, though -- this would also be= =20 confusing. > I could live with mixed assignment. Moreover, I think it is "more=20 > correct".=20 > Is the above statement correct? You are considering the mixed assignment=20 because you could live with it? =20 > > So generic code wants to work generically (obviously) and typically on=20 > RegularTypes. optional<> is not always regular. How do I=20 > compile-time check that the target type is a reference? I assume=20 > there is optional<>::value_type. I don't expect that I can easily=20 > test that the value_type is regular (in general) but I can check if it=20 > is a reference.=20 > yes, optional provides this value_type. I am not sure I agree with this=20 claim about the expectation that generic T is a RegularType. Consider=20 InputIterator-s. =20 > > Don't know what that says about your first argument in favour of=20 > optional references:=20 > "optional can be used in generic code, were T can be either a=20 > reference or an object"=20 > > I don't think generic code will typically work with both optional=20 > and optional interchangeably. Nor do I think much generic code=20 > works with T and T& interchangeably. The semantics are different,=20 > there isn't much of interest the generic code can reliably do. Well, I agree with you here. And therewith I disagree with the statement in= =20 my proposal :( Personally, I cannot imagine why I would want to treat optional and=20 optional generically. If you consider using=20 is_reference::value_type>, this is in fact a departure from=20 genericity. However, some users do insist on generic use. I hope, not only= =20 on insisting per se. One convincing example I was shown was the following: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/zCnK= bHCGsxgJ That is, you only want to forward the T, whatever it is. > By the way, now that I've (re)read the Auxiliary part about optional=20 > references, I see you've covered much of this. Hope I wasn't=20 > repeating too much, and something of the above was helpful.=20 > It was useful. For instance you reminded me that a swap for optional=20 references should be re-enabled along with the assignment. Thanks! =20 > > And also the example:=20 > > void assign_norebind(optional& optref, T& obj)=20 > {=20 > if (optref) *optref =3D obj;=20 > else optref.emplace(obj);=20 > }=20 > > Is that really useful? It is 2 totally different semantics=20 > ("targetting" vs "set-value-of-target") rolled into one.=20 > Some people insisted on this behavior for optional ref assignment. We do=20 not propose it, but if you need it, we show you how to do it. Nothing more.= =20 Thank you for the input. I will improve the rationale section based on this= =20 discussion. Regards, &rzej --=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_98_19665365.1360145306280 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu wtorek, 5 lutego 2013 23:39:16 UTC+1 u=BFytkownik Tony V E n= apisa=B3:
On Tue, Feb 5, 2013 a= t 3:02 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com> wrote:
>>
>> Is optional<T&> a RegularType?
>
>
> I am not sure how to answer the question. Different people have sl= ightly
> different expectations of a regular type.

That's why I cc'ed Sean Parent :-)

Let's go with Stepanov, via http://www.stepanovpapers.com/DeSt98.pdf
and Elements of Programming (www.elementsofprogramming.com)

> optional<T&> has:
>
> default ctor
> destructor
> copy/move constructor (shallow)
> copy/move assignment (shallow)
> equality comparison (deep, provided that T is comparable)
> it is not swappable yet, but I intend to add a shallow swap
>
> I am not not sure what semantic requirements a RegularType require= s.

To summarize Stepanov, mainly the semantics of int w.r.t. copy,
assignment, and equality:

T b =3D ...<any value of T>;
T a =3D b;
assert(a =3D=3D b);

This holds, but -- so to say -- only by chance

T c =3D b;
change(a);
assert(c =3D=3D b && a !=3D b);
 
Well, this one is tricky. Given this= criterion, would you say a raw pointer satisfies it? IOW, does change(a) a= lso applies to changing the referred to (or pointed to) object?

int = i =3D 0;
int j =3D 1;
optional<int&> oi =3D i;
optional= <int&> oj =3D oi;

assert (oi =3D=3D oj); // holds

o= ptional<int&> ok =3D oi;
oi =3D {j}; // this is the change(a)<= br>
assert (ok =3D=3D oj); // holds
assert (oj !=3D oi) // holds
<= br>j =3D 0;
assert (oj !=3D oi) // DOES NOT HOLD

And this is what= I call an "asynchronous change". The value of 'j' shouldn't affect the axi= oms.


oh, and since I happen to always use construction above, I should
mention assignment and construction yield the same results, ie:

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

This holds
 

(he also requires less-than, but we can ignore that here)

operator< also works, with similar problems as= operator=3D=3D
 

> The
> value compared by operator=3D=3D is not under control of the optio= nal object: it
> can change "asynchronously".

Let's limit our discussion to optionals over Ts where T is Regular. &nb= sp;I
agree there is not much we can do when T is not Regular.
So in general, optional<T> is Regular if T is Regular, I think. (= ?)

The problem I (clumsily) describe also works for = Regular T's:

int i =3D 0;
int j =3D 0;
optional<int&>= ; oi =3D i;
optional<int&> oj =3D j;

assert (oi =3D=3D = oj);
i =3D 9; // the "asynchronous change"
assert (oi !=3D oj);
&= nbsp;

> Also the copy/move operations are not
> compatible with operator=3D=3D: the former are shallow, the latter= is deep.
>

That the part I'm wondering about.  I guess the key thing is that = even
though T is regular, T & isn't, as the final a !=3D b assert fails.
Using 'int' and 'int &' we get:

int target =3D 17;

int & b =3D target;
int & a =3D b;
assert(a =3D=3D b);

int & c =3D b;
change(a);
assert(c =3D=3D b && a !=3D b);  // fails! as a =3D=3D b

Yes, raw references are not regular.
 

So does optional<int &> have the same semantics as int & = (at least
when the optional is engaged)?
Except optional allows rebinding, whereas int & does not.

Given this assignment semantics, it is impossible= to say if optional references are 'like' raw references. They allow the sa= me kind of departure from RegularType. One could say that the only purpose = of raw references (and therefore also  optional references) is to depa= rt from RegularType requirements (especially: the "value separation")
&n= bsp;

Why not allow mixed assignment even?

optional<int &> oi =3D target;
oi =3D 123;

Here, you imply that the semantics would be non-r= ebinding:

oi =3D 123 <=3D=3D>  *oi =3D 123
(of course,= if oi !=3D nullopt)

But that would be inconsistent with converting = constructor: which only binds a reference. Also the existence of this assig= nment was the reason that caused the first revision of Optional to be rejec= ted by the Committee.



that would be consistent with int &.
I guess it gets confusing with the rebinding?

int alternate =3D 21;
int another  =3D 35;
oi =3D alternate;
assert(target =3D=3D 21);
oi =3D optional<int&>(another);
oi =3D 42;
assert(target !=3D 42);
assert(another =3D=3D 42);

rebinding mixed assignment is confusing -- true. = Non-rebinding one is inconsistent with the homogenous assignment, though --= this would also be confusing.


I could live with mixed assignment.  Moreover, I think it is "more= correct".

Is the above statement correct? You are consideri= ng the mixed assignment because you could live with it?
 
=

So generic code wants to work generically (obviously) and typically on
RegularTypes.  optional<> is not always regular.  How d= o I
compile-time check that the target type is a reference?  I assume
there is optional<>::value_type.  I don't expect that I can = easily
test that the value_type is regular (in general) but I can check if it
is a reference.

yes, optional provides this value_type. I am not = sure I agree with this claim about the expectation that generic T is a Regu= larType. Consider InputIterator-s.
 

Don't know what that says about your first argument in favour of
optional references:
"optional<T> can be used in generic code, were T can be either a
reference or an object"

I don't think generic code will typically work with both optional<T&= gt;
and optional<T&> interchangeably. Nor do I think much generic= code
works with T and T& interchangeably.  The semantics are differ= ent,
there isn't much of interest the generic code can reliably do.

Well, I agree with you here. And therewith I disagree with the= statement in my proposal :(
Personally, I cannot imagine why I would wa= nt to treat optional<T> and optional<T&> generically. If yo= u consider using is_reference<optional<X>::value_type>, this is= in fact a departure from genericity. However, some users do insist on gene= ric use. I hope, not only on insisting per se. One convincing example I was= shown was the following:
https://groups.google.com/a/isocpp.org/d/msg/s= td-proposals/cXneqUj-5oo/zCnKbHCGsxgJ
That is, you only want to forward = the T, whatever it is.


By the way, now that I've (re)read the Auxiliary part about optional
references, I see you've covered much of this.  Hope I wasn't
repeating too much, and something of the above was helpful.

It was useful. For instance you reminded me that = a swap for optional references should be re-enabled along with the assignme= nt. Thanks!
 

And also the example:

void assign_norebind(optional<T&>& optref, T& obj)
{
  if (optref) *optref =3D obj;
  else        optref.emplace(obj);
}

Is that really useful?  It is 2 totally different semantics
("targetting" vs "set-value-of-target") rolled into one.

Some people insisted on this behavior for optiona= l ref assignment. We do not propose it, but if you need it, we show you how= to do it. Nothing more.

Thank you for the input. I will improve th= e rationale section based on this discussion.

Regards,
&rzej<= br>

--
 
---
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_98_19665365.1360145306280-- .