------=_Part_408_17593010.1360005787933
Content-Type: text/plain; charset=ISO-8859-1


>
> > I wanted to consult with people here one more thing about mixed relops.
> > Assuming that we allow mixed relops for optional values, should we also
> > provide them for optional references?
> >
> > int i = 9;
> > optional<int&> oi = i;
> > return oi == i; // should it work?
> >
>
> Just to be clear, does it compare the values, or the ref?
>

The values.


>
> ie
>
> int i = 9;
> optional<int&> oi = i;
> int j = 9;
> return oi == j;  // also true?
>

This returns true.


>
>
> And does this follow whichever rules of set-the-value or set-the-ref
> you are choosing?
>
> ...
> j = 5;
> oi = j;
>

mixed assignment is illegal. Use one of the following instead:

*oi = j; // if you want to alter the referred-to object
oi = {j}; // if you want to rebind a reference


>
> cout << i;  // prints... 5? 9?
>

Copy constructor and copy assignment are shallow: they only (re)bind a
reference. Other operations are deep: this includes comparison (mixed or
homogenous)


>
>
> Sorry to bring up the optional & discussion again.  I really just
> wondered whether it was consistent with assignment, whichever way it
> goes.


I started another thread, in case people want to comment on optional
references. You can find the updated proposal here:
http://kojot.sggw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html
Optional references are at the end as an auxiliary proposal.

Regards,
&rzej

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_408_17593010.1360005787933
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">&gt; I wanted to =
consult with people here one more thing about mixed relops.
<br>&gt; Assuming that we allow mixed relops for optional values, should we=
 also
<br>&gt; provide them for optional references?
<br>&gt;
<br>&gt; int i =3D 9;
<br>&gt; optional&lt;int&amp;&gt; oi =3D i;
<br>&gt; return oi =3D=3D i; // should it work?
<br>&gt;
<br>
<br>Just to be clear, does it compare the values, or the ref?
<br></blockquote><div><br>The values.<br>&nbsp;<br></div><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;" class=3D"gmail_quote">
<br>ie
<br><div class=3D"GAK2G4EDN5">
<br>int i =3D 9;
<br>optional&lt;int&amp;&gt; oi =3D i;
<br></div>int j =3D 9;
<br>return oi =3D=3D j; &nbsp;// also true?
<br></blockquote><div><br>This returns true.<br>&nbsp;<br></div><blockquote=
 style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;" class=3D"gmail_quote">
<br>
<br>And does this follow whichever rules of set-the-value or set-the-ref
<br>you are choosing?
<br>
<br>...
<br>j =3D 5;
<br>oi =3D j;
<br></blockquote><div><br>mixed assignment is illegal. Use one of the follo=
wing instead:<br><br>*oi =3D j; // if you want to alter the referred-to obj=
ect<br>oi =3D {j}; // if you want to rebind a reference<br>&nbsp;<br></div>=
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">
<br>cout &lt;&lt; i; &nbsp;// prints... 5? 9?
<br></blockquote><div><br>Copy constructor and copy assignment are shallow:=
 they only (re)bind a reference. Other operations are deep: this includes c=
omparison (mixed or homogenous)<br>&nbsp;<br></div><blockquote style=3D"mar=
gin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-=
left: 1ex;" class=3D"gmail_quote">
<br>
<br>Sorry to bring up the optional &amp; discussion again. &nbsp;I really j=
ust
<br>wondered whether it was consistent with assignment, whichever way it
<br>goes.
</blockquote><div><br>I started another thread, in case people want to comm=
ent on optional references. You can find the updated proposal here: http://=
kojot.sggw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html<br>Optional=
 references are at the end as an auxiliary proposal.<br><br>Regards,<br>&am=
p;rzej <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_408_17593010.1360005787933--

.

On Mon, Feb 4, 2013 at 2:23 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.co=
m> wrote:
>> > I wanted to consult with people here one more thing about mixed relops=
..
>> > Assuming that we allow mixed relops for optional values, should we als=
o
>> > provide them for optional references?
>> >
>> > int i =3D 9;
>> > optional<int&> oi =3D i;
>> > return oi =3D=3D i; // should it work?
>> >
>>
>> Just to be clear, does it compare the values, or the ref?
>
>
> The values.
>
>
>
> mixed assignment is illegal. Use one of the following instead:
>
> *oi =3D j; // if you want to alter the referred-to object
> oi =3D {j}; // if you want to rebind a reference
>
>>
>
> Copy constructor and copy assignment are shallow: they only (re)bind a
> reference. Other operations are deep: this includes comparison (mixed or
> homogenous)
>

Is optional<T&> a RegularType?

Tony

--=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_1772_14843462.1360094562219
Content-Type: text/plain; charset=ISO-8859-1



> > mixed assignment is illegal. Use one of the following instead:
> >
> > *oi = j; // if you want to alter the referred-to object
> > oi = {j}; // if you want to rebind a reference
> >
> >>
> >
> > Copy constructor and copy assignment are shallow: they only (re)bind a
> > reference. Other operations are deep: this includes comparison (mixed or
> > homogenous)
> >
>
> Is optional<T&> a RegularType?
>

I am not sure how to answer the question. Different people have slightly
different expectations of a regular type.
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 requires. The
value compared by operator== is not under control of the optional object:
it can change "asynchronously". Also the copy/move operations are not
compatible with operator==: the former are shallow, the latter is deep.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1772_14843462.1360094562219
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; mixed assignment is i=
llegal. Use one of the following instead:
<br>&gt;
<br>&gt; *oi =3D j; // if you want to alter the referred-to object
<br>&gt; oi =3D {j}; // if you want to rebind a reference
<br>&gt;
<br>&gt;&gt;
<br>&gt;
<br>&gt; Copy constructor and copy assignment are shallow: they only (re)bi=
nd a
<br>&gt; reference. Other operations are deep: this includes comparison (mi=
xed or
<br>&gt; homogenous)
<br>&gt;
<br>
<br>Is optional&lt;T&amp;&gt; a RegularType?
<br></blockquote><div><br>I am not sure how to answer the question. Differe=
nt people have slightly different expectations of a regular type.<br>option=
al&lt;T&amp;&gt; has:<br><ul><li>default ctor</li><li>destructor<br></li><l=
i>copy/move constructor (shallow)</li><li>copy/move assignment (shallow)</l=
i><li>equality comparison (deep, provided that T is comparable)</li><li>it =
is not swappable yet, but I intend to add a shallow swap<br></li></ul>I am =
not not sure what semantic requirements a RegularType requires. The value c=
ompared by operator=3D=3D is not under control of the optional object: it c=
an change "asynchronously". Also the copy/move operations are not compatibl=
e with operator=3D=3D: the former are shallow, the latter is deep.<br></div=
><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1772_14843462.1360094562219--

.

On Tue, Feb 5, 2013 at 3:02 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com> =
wrote:
>>
>> Is optional<T&> a RegularType?
>
>
> I am not sure how to answer the question. Different people have slightly
> 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 requires.

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);

T c =3D b;
change(a);
assert(c =3D=3D b && a !=3D b);

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;

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

> The
> value compared by operator=3D=3D is not under control of the optional obj=
ect: it
> can change "asynchronously".

Let's limit our discussion to optionals over Ts where T is Regular.  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. (?)

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

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

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.

Why not allow mixed assignment even?

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

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);

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

So generic code wants to work generically (obviously) and typically on
RegularTypes.  optional<> is not always regular.  How do 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.

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>
and optional<T&> interchangeably. Nor do I think much generic code
works with T and T& interchangeably.  The semantics are different,
there isn't much of interest the generic code can reliably do.


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.

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.



Tony

--=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/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 <akrz...@gmail.com<=
javascript:>>=20
> wrote:=20
> >>=20
> >> Is optional<T&> 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<T&> 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 ...<any value of T>;=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<int&> oi =3D i;=20
optional<int&> oj =3D oi;

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

optional<int&> 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<T> 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<int&> oi =3D i;
optional<int&> 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<int &> 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<int &> 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<int&>(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<T> 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<T>=20
> and optional<T&> 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<T> and=20
optional<T&> generically. If you consider using=20
is_reference<optional<X>::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<T&>& 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

<br><br>W dniu wtorek, 5 lutego 2013 23:39:16 UTC+1 u=BFytkownik Tony V E n=
apisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Feb 5, 2013 a=
t 3:02 PM, Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"umK0-AhUhAwJ">akrz...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; Is optional&lt;T&amp;&gt; a RegularType?
<br>&gt;
<br>&gt;
<br>&gt; I am not sure how to answer the question. Different people have sl=
ightly
<br>&gt; different expectations of a regular type.
<br>
<br>That's why I cc'ed Sean Parent :-)
<br>
<br>Let's go with Stepanov, via <a href=3D"http://www.stepanovpapers.com/De=
St98.pdf" target=3D"_blank">http://www.stepanovpapers.com/<wbr>DeSt98.pdf</=
a>
<br>and Elements of Programming (<a href=3D"http://www.elementsofprogrammin=
g.com" target=3D"_blank">www.elementsofprogramming.com</a><wbr>)
<br>
<br>&gt; optional&lt;T&amp;&gt; has:
<br>&gt;
<br>&gt; default ctor
<br>&gt; destructor
<br>&gt; copy/move constructor (shallow)
<br>&gt; copy/move assignment (shallow)
<br>&gt; equality comparison (deep, provided that T is comparable)
<br>&gt; it is not swappable yet, but I intend to add a shallow swap
<br>&gt;
<br>&gt; I am not not sure what semantic requirements a RegularType require=
s.
<br>
<br>To summarize Stepanov, mainly the semantics of int w.r.t. copy,
<br>assignment, and equality:
<br>
<br>T b =3D ...&lt;any value of T&gt;;
<br>T a =3D b;
<br>assert(a =3D=3D b);
<br></blockquote><div><br>This holds, but -- so to say -- only by chance <b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>T c =3D b;
<br>change(a);
<br>assert(c =3D=3D b &amp;&amp; a !=3D b);
<br></blockquote><div>&nbsp;</div><div>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?<br><br>int =
i =3D 0;<br>int j =3D 1;<br>optional&lt;int&amp;&gt; oi =3D i; <br>optional=
&lt;int&amp;&gt; oj =3D oi;<br><br>assert (oi =3D=3D oj); // holds<br><br>o=
ptional&lt;int&amp;&gt; ok =3D oi;<br>oi =3D {j}; // this is the change(a)<=
br><br>assert (ok =3D=3D oj); // holds<br>assert (oj !=3D oi) // holds<br><=
br>j =3D 0;<br>assert (oj !=3D oi) // DOES NOT HOLD<br><br>And this is what=
 I call an "asynchronous change". The value of 'j' shouldn't affect the axi=
oms.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>oh, and since I happen to always use construction above, I should
<br>mention assignment and construction yield the same results, ie:
<br>
<br>T a; a =3D b; &nbsp;&lt;=3D=3D&gt; T a =3D b;
<br></blockquote><div><br>This holds<br>&nbsp;<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>(he also requires less-than, but we can ignore that here)
<br></blockquote><div><br>operator&lt; also works, with similar problems as=
 operator=3D=3D<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>&gt; The
<br>&gt; value compared by operator=3D=3D is not under control of the optio=
nal object: it
<br>&gt; can change "asynchronously".
<br>
<br>Let's limit our discussion to optionals over Ts where T is Regular. &nb=
sp;I
<br>agree there is not much we can do when T is not Regular.
<br>So in general, optional&lt;T&gt; is Regular if T is Regular, I think. (=
?)
<br></blockquote><div><br>The problem I (clumsily) describe also works for =
Regular T's:<br><br>int i =3D 0;<br>int j =3D 0;<br>optional&lt;int&amp;&gt=
; oi =3D i;<br>optional&lt;int&amp;&gt; oj =3D j;<br><br>assert (oi =3D=3D =
oj);<br>i =3D 9; // the "asynchronous change"<br>assert (oi !=3D oj); <br>&=
nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Also the copy/move operations are not
<br>&gt; compatible with operator=3D=3D: the former are shallow, the latter=
 is deep.
<br>&gt;
<br>
<br>That the part I'm wondering about. &nbsp;I guess the key thing is that =
even
<br>though T is regular, T &amp; isn't, as the final a !=3D b assert fails.
<br>Using 'int' and 'int &amp;' we get:
<br>
<br>int target =3D 17;
<br>
<br>int &amp; b =3D target;
<br>int &amp; a =3D b;
<br>assert(a =3D=3D b);
<br>
<br>int &amp; c =3D b;
<br>change(a);
<br>assert(c =3D=3D b &amp;&amp; a !=3D b); &nbsp;// fails! as a =3D=3D b
<br></blockquote><div><br>Yes, raw references are not regular.<br>&nbsp;<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>So does optional&lt;int &amp;&gt; have the same semantics as int &amp; =
(at least
<br>when the optional is engaged)?
<br>Except optional allows rebinding, whereas int &amp; does not.
<br></blockquote><div><br>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&nbsp; optional references) is to depa=
rt from RegularType requirements (especially: the "value separation")<br>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Why not allow mixed assignment even?
<br>
<br>optional&lt;int &amp;&gt; oi =3D target;
<br>oi =3D 123;
<br></blockquote><div><br>Here, you imply that the semantics would be non-r=
ebinding:<br><br>oi =3D 123 &lt;=3D=3D&gt;&nbsp; *oi =3D 123<br>(of course,=
 if oi !=3D nullopt)<br><br>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.<br><br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">
<br>that would be consistent with int &amp;.
<br>I guess it gets confusing with the rebinding?
<br>
<br>int alternate =3D 21;
<br>int another &nbsp;=3D 35;
<br>oi =3D alternate;
<br>assert(target =3D=3D 21);
<br>oi =3D optional&lt;int&amp;&gt;(another);
<br>oi =3D 42;
<br>assert(target !=3D 42);
<br>assert(another =3D=3D 42);
<br></blockquote><div><br>rebinding mixed assignment is confusing -- true. =
Non-rebinding one is inconsistent with the homogenous assignment, though --=
 this would also be confusing.<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>I could live with mixed assignment. &nbsp;Moreover, I think it is "more=
 correct".
<br></blockquote><div><br>Is the above statement correct? You are consideri=
ng the mixed assignment because you could live with it?<br>&nbsp;<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
<br>So generic code wants to work generically (obviously) and typically on
<br>RegularTypes. &nbsp;optional&lt;&gt; is not always regular. &nbsp;How d=
o I
<br>compile-time check that the target type is a reference? &nbsp;I assume
<br>there is optional&lt;&gt;::value_type. &nbsp;I don't expect that I can =
easily
<br>test that the value_type is regular (in general) but I can check if it
<br>is a reference.
<br></blockquote><div><br>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.<br>&nbsp;<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">
<br>Don't know what that says about your first argument in favour of
<br>optional references:
<br>"optional&lt;T&gt; can be used in generic code, were T can be either a
<br>reference or an object"
<br>
<br>I don't think generic code will typically work with both optional&lt;T&=
gt;
<br>and optional&lt;T&amp;&gt; interchangeably. Nor do I think much generic=
 code
<br>works with T and T&amp; interchangeably. &nbsp;The semantics are differ=
ent,
<br>there isn't much of interest the generic code can reliably do.</blockqu=
ote><div><br>Well, I agree with you here. And therewith I disagree with the=
 statement in my proposal :(<br>Personally, I cannot imagine why I would wa=
nt to treat optional&lt;T&gt; and optional&lt;T&amp;&gt; generically. If yo=
u consider using is_reference&lt;optional&lt;X&gt;::value_type&gt;, 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:<br>https://groups.google.com/a/isocpp.org/d/msg/s=
td-proposals/cXneqUj-5oo/zCnKbHCGsxgJ<br>That is, you only want to forward =
the T, whatever it is.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>By the way, now that I've (re)read the Auxiliary part about optional
<br>references, I see you've covered much of this. &nbsp;Hope I wasn't
<br>repeating too much, and something of the above was helpful.
<br></blockquote><div><br>It was useful. For instance you reminded me that =
a swap for optional references should be re-enabled along with the assignme=
nt. Thanks!<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
<br>And also the example:
<br>
<br>void assign_norebind(optional&lt;T&amp;&gt;&amp; optref, T&amp; obj)
<br>{
<br>&nbsp; if (optref) *optref =3D obj;
<br>&nbsp; else &nbsp; &nbsp; &nbsp; &nbsp;optref.emplace(obj);
<br>}
<br>
<br>Is that really useful? &nbsp;It is 2 totally different semantics
<br>("targetting" vs "set-value-of-target") rolled into one.
<br></blockquote><div><br>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. <br><br>Thank you for the input. I will improve th=
e rationale section based on this discussion.<br><br>Regards,<br>&amp;rzej<=
br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_98_19665365.1360145306280--

.

On Wed, Feb 6, 2013 at 5:08 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com> =
wrote:
>
>
> 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 <akrz...@gmail.com=
>
>> wrote:
>> >>
>> >> Is optional<T&> a RegularType?
>> >
>> >
>> > I am not sure how to answer the question. Different people have slight=
ly
>> > 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 requires.
>>
>> 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 point=
er
> satisfies it? IOW, does change(a) also applies to changing the referred t=
o
> (or pointed to) object?
>

I knew I should have written change(a) as:
a =3D some_other_value;

:-)

(I started writing "Given T val1, val2 with val1 !=3D val2..." but it
was getting even longer.  Stepanov used 'zap(a)', I thought
"change(a)" was at least an improvement.)

Pointers are value-types, RegularTypes - their value is an address.
We tend to *use* them for reference semantics on the pointee, but they
are actually Regular as a type.

> int i =3D 0;
>
> int j =3D 1;
> optional<int&> oi =3D i;
> optional<int&> oj =3D oi;
>
> assert (oi =3D=3D oj); // holds
>
> optional<int&> 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' should=
n't
> affect the axioms.
>

Right, but the value of j does affect the axioms, because =3D=3D isn't
working on the same "plane" as =3D.
Somewhat understandable, but :-(


>>
>> 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

It holds for optional=3Doptional, but maybe not mixed-assignment, if
that is allowed.  (I know you are _not_ talking about mixed-assign
here, but I wanted to point it out, maybe just to myself even).

And doesn't hold when T is int &.  Another reason why int & is not Regular:

int & a =3D some_int; a =3D b;  <=3D!=3D>  int & a =3D b;

I'll come back to that later.

>
>>
>>
>> (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 optional
>> > object: it
>> > can change "asynchronously".
>>
>> Let's limit our discussion to optionals over Ts where T is Regular.  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);

but that assert is by coincidence, nothing more.

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

yes "spooky action at a distance" - why I don't like: raw pointers,
shared pointers, java, reference semantics, global variables

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

agreed

> They allow the same kind of departure
> from RegularType. One could say that the only purpose of raw references (=
and
> therefore also  optional references) is to depart from RegularType
> requirements (especially: the "value separation")
>

astute

>>
>>
>> Why not allow mixed assignment even?
>>
>> optional<int &> oi =3D target;
>> oi =3D 123;
>
>
> Here, you imply that the semantics would be non-rebinding:
>
> oi =3D 123 <=3D=3D>  *oi =3D 123
> (of course, if oi !=3D nullopt)
>

yes, non-rebinding (whether using literal 123 or a variable)

> But that would be inconsistent with converting constructor: which only bi=
nds
> a reference.

Yes! ie exact same as int &.  Assignment of int & is inconsistent with
its constructor:

int i =3D 0, j =3D 1;
int & a  =3D i;  // A
a =3D j;  // B - does not rebind!
assert(i =3D=3D 1);

Line A is inconsistent with B.  Maybe you call B "mixed assignment".
A is non-mixed:  int & =3D int &.  B is mixed: int & =3D int.  :-)

So optional could be the same.
optional<int &> a =3D i;    // A
a =3D j; // B

same as behaviour as int &.


So we could *almost* say optional<T&> is Regular, and Reference on
mixed-ops.  This is not inconsistent.  Regular only talks about T
w.r.t. T, not mixed types.
Also, pointers are similarly Regular but used for Reference.

(If the language had allowed:
int i;
int * pi =3D &i;
pi =3D 12;  // sets i to 12

would that be a problem? Confusion?  (If so, should optional dial back
its operators?)
Also, if references required notation to convert a variable from value
to ref, would this have allowed rebinding:

int i =3D 0, j =3D 1;
int & ri =3D @i; // or ref_of(i) or &i or whatever.
ri =3D j; // sets i to 1
ri =3D &j; // rebinds to j

But I digress.)


I say optional<T&> is *almost* Regular, because optional<T&> is NOT
Regular on =3D=3D.  Which is why I asked in the first place.
It may seem odd that optional<T&> =3D=3D optional<T&> would do something
like compare addresses, but it would make optional consistently
Regular in all cases.
Instead optional<> is Regular *everywhere*, including (non-mixed)
assignment, except:

=3D=3D on optional<T&>



> Also the existence of this assignment was the reason that
> caused the first revision of Optional to be rejected by the Committee.
>

Sure.  Is that a problem?  :-)  What do they/we know? :-):-)

>
>>
>> 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 considering the mixed assignment
> because you could live with it?
>

As above, I think optional could be, maybe "strives" to be, Regular.
Mixed-ops don't count with Regular.  Regular only deals with T op T.
So mixed-ops can differ.
Furthermore, having mixed-assignment be Reference is consistent with int &.
Basically mixed assignment is always "I will pass this on to my
value_type, and it will do whatever it wants with it".
Which is consistent with *really mixed* assignment - ie when the value
is neither T nor optional<T>.  ie:

T t;
U u;
optional<T> ot =3D something_not_empty;

ot =3D u;

What does that do?  Is it the same as:

*ot =3D u;

ie calls T::operator=3D(U) (assuming it exists)?

So when T is int &, it would call, in effect, "int&::operator=3D(int)".
Which is non-rebinding.


(Also, going back to mixed <, I could see
opt < val  <=3D=3D> *opt < val
ie throws if not engaged.
Then T i; U u; opt<T> < U makes sense if T < U makes sense.  And
opt<T> < opt<T> is still fine as in your proposal.)

>>
>>
>> So generic code wants to work generically (obviously) and typically on
>> RegularTypes.  optional<> is not always regular.  How do 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 RegularType. Consider
> InputIterator-s.

There was a "typically" up there.  I think most generic code relies on
RegularType.  If the code doesn't need it, great, but, like Stepanov
says, we often assume Regular and forget to even think about it - ie
we make a temp variable as needed, or do certain refactorings and
optimizations that rely on it.  Of course template writers are not
your "typical" coder, so they might keep non-Regular in mind, but the
average programmer assumes it without thinking.

>
>>
>>
>> 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>
>> and optional<T&> interchangeably. Nor do I think much generic code
>> works with T and T& interchangeably.  The semantics are different,
>> 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 want to treat optional<T> and
> optional<T&> generically. If you consider using
> is_reference<optional<X>::value_type>, this is in fact a departure from
> genericity. However, some users do insist on generic use. I hope, not onl=
y
> 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/zC=
nKbHCGsxgJ
> That is, you only want to forward the T, whatever it is.
>

There will be cases like that, yes.  But not many. (Of course "no one
knows what the average programmer does"...)

>>
>> 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 assignment. 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 optional 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 the rationale section based on th=
is
> discussion.
>
> Regards,
> &rzej
>

As you may have guessed, I'm finding optional<> very interesting. :-)
Thanks for bringing it to the committee.
Tony

--=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_371_3319515.1360181322014
Content-Type: text/plain; charset=ISO-8859-1



> >>
> >> that would be consistent with int &.
> >> I guess it gets confusing with the rebinding?
> >>
> >> int alternate = 21;
> >> int another  = 35;
> >> oi = alternate;
> >> assert(target == 21);
> >> oi = optional<int&>(another);
> >> oi = 42;
> >> assert(target != 42);
> >> assert(another == 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 considering the mixed assignment
> > because you could live with it?
> >
>
> As above, I think optional could be, maybe "strives" to be, Regular.
> Mixed-ops don't count with Regular.  Regular only deals with T op T.
> So mixed-ops can differ.
> Furthermore, having mixed-assignment be Reference is consistent with int
> &.
> Basically mixed assignment is always "I will pass this on to my
> value_type, and it will do whatever it wants with it".
> Which is consistent with *really mixed* assignment - ie when the value
> is neither T nor optional<T>.  ie:
>
> T t;
> U u;
> optional<T> ot = something_not_empty;
>
> ot = u;
>
> What does that do?  Is it the same as:
>
> *ot = u;
>
> ie calls T::operator=(U) (assuming it exists)?
>
> So when T is int &, it would call, in effect, "int&::operator=(int)".
> Which is non-rebinding.
>


Let me just add one observation about mixed assignment. There is always
this case where you are assigning to a disengaged optional reference. In
that case assigning value is not possible because there is nothing to
assign it to, so you have to rebind the reference. This makes the mixed
assignment behave like assign_nonrebind():

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

Which, as you observed, "is 2 totally different semantics ('targetting' vs
'set-value-of-target') rolled into one."


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_371_3319515.1360181322014
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;&gt;
<br>&gt;&gt; that would be consistent with int &amp;.
<br>&gt;&gt; I guess it gets confusing with the rebinding?
<br>&gt;&gt;
<br>&gt;&gt; int alternate =3D 21;
<br>&gt;&gt; int another &nbsp;=3D 35;
<br>&gt;&gt; oi =3D alternate;
<br>&gt;&gt; assert(target =3D=3D 21);
<br>&gt;&gt; oi =3D optional&lt;int&amp;&gt;(another);
<br>&gt;&gt; oi =3D 42;
<br>&gt;&gt; assert(target !=3D 42);
<br>&gt;&gt; assert(another =3D=3D 42);
<br>&gt;
<br>&gt;
<br>&gt; rebinding mixed assignment is confusing -- true. Non-rebinding one=
 is
<br>&gt; inconsistent with the homogenous assignment, though -- this would =
also be
<br>&gt; confusing.
<br>&gt;
<br>&gt;&gt;
<br>&gt;&gt; I could live with mixed assignment. &nbsp;Moreover, I think it=
 is "more
<br>&gt;&gt; correct".
<br>&gt;
<br>&gt;
<br>&gt; Is the above statement correct? You are considering the mixed assi=
gnment
<br>&gt; because you could live with it?
<br>&gt;
<br>
<br>As above, I think optional could be, maybe "strives" to be, Regular.
<br>Mixed-ops don't count with Regular. &nbsp;Regular only deals with T op =
T.
<br>So mixed-ops can differ.
<br>Furthermore, having mixed-assignment be Reference is consistent with in=
t &amp;.
<br>Basically mixed assignment is always "I will pass this on to my
<br>value_type, and it will do whatever it wants with it".
<br>Which is consistent with *really mixed* assignment - ie when the value
<br>is neither T nor optional&lt;T&gt;. &nbsp;ie:
<br>
<br>T t;
<br>U u;
<br>optional&lt;T&gt; ot =3D something_not_empty;
<br>
<br>ot =3D u;
<br>
<br>What does that do? &nbsp;Is it the same as:
<br>
<br>*ot =3D u;
<br>
<br>ie calls T::operator=3D(U) (assuming it exists)?
<br>
<br>So when T is int &amp;, it would call, in effect, "int&amp;::operator=
=3D(int)".
<br>Which is non-rebinding.
<br></blockquote><br><br>Let me just add one observation about mixed assign=
ment. There is always this case where you are assigning to a disengaged opt=
ional reference. In that case assigning value is not possible because there=
 is nothing to assign it to, so you have to rebind the reference. This make=
s the mixed assignment behave like assign_nonrebind(): <br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> assign_norebind</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">optional</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;&gt;&amp;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> optref</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> obj</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">optref</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>optref </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> obj</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">else</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp; &nbsp; &nbsp;=
 &nbsp;optref</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">emplac=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">obj</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>Which, as you =
observed, "is 2 totally different semantics ('targetting' vs 'set-value-of-=
target') rolled into one."<br><br>
<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_371_3319515.1360181322014--

.

On Wed, Feb 6, 2013 at 3:08 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.co=
m> wrote:
>
>> >>
>
> Let me just add one observation about mixed assignment. There is always t=
his
> case where you are assigning to a disengaged optional reference. In that
> case assigning value is not possible because there is nothing to assign i=
t
> to, so you have to rebind the reference. This makes the mixed assignment
> behave like assign_nonrebind():
>
> void assign_norebind(optional<T&>& optref, T& obj)
> {
>    if (optref) *optref =3D obj;
>    else        optref.emplace(obj);
> }
>
> Which, as you observed, "is 2 totally different semantics ('targetting' v=
s
> 'set-value-of-target') rolled into one."
>

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

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 that 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;

But for NonRegular types, particularly references, it may not be the
same.  I just find it scary on references.  ...Which brings us 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 get
what you expect/deserve.(?)

Tony

--=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.



.

--Apple-Mail-F27E2A10-94FA-48C8-910C-9DA717F1FC76
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Sent from my iPad

On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> =
wrote:

>=20
>> > mixed assignment is illegal. Use one of the following instead:=20
>> >=20
>> > *oi =3D j; // if you want to alter the referred-to object=20
>> > oi =3D {j}; // if you want to rebind a reference=20
>> >=20
>> >>=20
>> >=20
>> > Copy constructor and copy assignment are shallow: they only (re)bind a=
=20
>> > reference. Other operations are deep: this includes comparison (mixed =
or=20
>> > homogenous)=20
>> >=20
>>=20
>> Is optional<T&> a RegularType?
>=20
> I am not sure how to answer the question. Different people have slightly =
different expectations of a regular type.
> optional<T&> has:
> default ctor
> destructor
> copy/move constructor (shallow)
> copy/move assignment (shallow)
> equality comparison (deep, provided that T is comparable)
Then the answer would be no. The semantics of regular types are well define=
d. See http://www.stepanovpapers.com/DeSt98.pdf. Copies must be equal and d=
isjoint. These semantics are not regular. I find it odd that copying would =
behave differently than a T& and I'm not sure what this construct buys you =
over a T*.

> it is not swappable yet, but I intend to add a shallow swap
Given that it is copyable and assignable how is it not swappable?

> I am not not sure what semantic requirements a RegularType requires. The =
value compared by operator=3D=3D is not under control of the optional objec=
t: it can change "asynchronously". Also the copy/move operations are not co=
mpatible with operator=3D=3D: the former are shallow, the latter is deep.
> =20

--=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.



--Apple-Mail-F27E2A10-94FA-48C8-910C-9DA717F1FC76
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div><br><br>Sent from my iPad</div><di=
v><br>On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=F1ski &lt;<a href=3D"mai=
lto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt; wrote:<br><br></div><blo=
ckquote type=3D"cite"><div><br><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>&gt; mixed assignment is illegal. Use one of the following instead:
<br>&gt;
<br>&gt; *oi =3D j; // if you want to alter the referred-to object
<br>&gt; oi =3D {j}; // if you want to rebind a reference
<br>&gt;
<br>&gt;&gt;
<br>&gt;
<br>&gt; Copy constructor and copy assignment are shallow: they only (re)bi=
nd a
<br>&gt; reference. Other operations are deep: this includes comparison (mi=
xed or
<br>&gt; homogenous)
<br>&gt;
<br>
<br>Is optional&lt;T&amp;&gt; a RegularType?
<br></blockquote><div><br>I am not sure how to answer the question. Differe=
nt people have slightly different expectations of a regular type.<br>option=
al&lt;T&amp;&gt; has:<br><ul><li>default ctor</li><li>destructor<br></li><l=
i>copy/move constructor (shallow)</li><li>copy/move assignment (shallow)</l=
i><li>equality comparison (deep, provided that T is comparable)</li></ul></=
div></div></blockquote><div>Then the answer would be no. The semantics of r=
egular types are well defined. See&nbsp;<a href=3D"http://www.stepanovpaper=
s.com/DeSt98.pdf">http://www.stepanovpapers.com/DeSt98.pdf</a>.&nbsp;Copies=
 must be equal and disjoint. These semantics are not regular. I find it odd=
 that copying would behave differently than a T&amp; and I'm not sure what =
this construct buys you over a T*.</div><div><br></div><blockquote type=3D"=
cite"><div><div><ul><li>it is not swappable yet, but I intend to add a shal=
low swap<br></li></ul></div></div></blockquote><div>Given that it is copyab=
le and assignable how is it not swappable?</div><br><blockquote type=3D"cit=
e"><div><div>I am not not sure what semantic requirements a RegularType req=
uires. The value compared by operator=3D=3D is not under control of the opt=
ional object: it can change "asynchronously". Also the copy/move operations=
 are not compatible with operator=3D=3D: the former are shallow, the latter=
 is deep.<br></div><div>&nbsp;</div>
</div></blockquote></body></html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--Apple-Mail-F27E2A10-94FA-48C8-910C-9DA717F1FC76--

.

------=_Part_1130_27364047.1360204811794
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, February 6, 2013 6:11:37 PM UTC-8, Sean Parent wrote:
>
>
>
> Sent from my iPad
>
> On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=C5=84ski <akrz...@gmail.com<=
javascript:>>=20
> wrote:
>
>
> > mixed assignment is illegal. Use one of the following instead:=20
>> >=20
>> > *oi =3D j; // if you want to alter the referred-to object=20
>> > oi =3D {j}; // if you want to rebind a reference=20
>> >=20
>> >>=20
>> >=20
>> > Copy constructor and copy assignment are shallow: they only (re)bind a=
=20
>> > reference. Other operations are deep: this includes comparison (mixed=
=20
>> or=20
>> > homogenous)=20
>> >=20
>>
>> Is optional<T&> a RegularType?=20
>>
>
> I am not sure how to answer the question. Different people have slightly=
=20
> different expectations of a regular type.
> optional<T&> has:
>
>    - default ctor
>    - destructor
>    - copy/move constructor (shallow)
>    - copy/move assignment (shallow)
>    - equality comparison (deep, provided that T is comparable)
>
> Then the answer would be no. The semantics of regular types are well=20
> defined. See http://www.stepanovpapers.com/DeSt98.pdf. Copies must be=20
> equal and disjoint. These semantics are not regular. I find it odd that=
=20
> copying would behave differently than a T& and I'm not sure what this=20
> construct buys you over a T*.
>

That's really the question I have about this whole `optional<T&>` thing:=20
what exactly is the use case for this functionality that `T*` can't also=20
cover?

--=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_1130_27364047.1360204811794
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, February 6, 2013 6:11:37 PM UTC-8, Sean Parent wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div><br><br=
>Sent from my iPad</div><div><br>On Feb 5, 2013, at 12:02 PM, Andrzej Krzem=
ie=C5=84ski &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"BVmrMgkz5PwJ">akrz...@gmail.com</a>&gt; wrote:<br><br></div><blockq=
uote type=3D"cite"><div><br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; mi=
xed assignment is illegal. Use one of the following instead:
<br>&gt;
<br>&gt; *oi =3D j; // if you want to alter the referred-to object
<br>&gt; oi =3D {j}; // if you want to rebind a reference
<br>&gt;
<br>&gt;&gt;
<br>&gt;
<br>&gt; Copy constructor and copy assignment are shallow: they only (re)bi=
nd a
<br>&gt; reference. Other operations are deep: this includes comparison (mi=
xed or
<br>&gt; homogenous)
<br>&gt;
<br>
<br>Is optional&lt;T&amp;&gt; a RegularType?
<br></blockquote><div><br>I am not sure how to answer the question. Differe=
nt people have slightly different expectations of a regular type.<br>option=
al&lt;T&amp;&gt; has:<br><ul><li>default ctor</li><li>destructor<br></li><l=
i>copy/move constructor (shallow)</li><li>copy/move assignment (shallow)</l=
i><li>equality comparison (deep, provided that T is comparable)</li></ul></=
div></div></blockquote><div>Then the answer would be no. The semantics of r=
egular types are well defined. See&nbsp;<a href=3D"http://www.stepanovpaper=
s.com/DeSt98.pdf" target=3D"_blank">http://www.stepanovpapers.<wbr>com/DeSt=
98.pdf</a>.&nbsp;Copies must be equal and disjoint. These semantics are not=
 regular. I find it odd that copying would behave differently than a T&amp;=
 and I'm not sure what this construct buys you over a T*.</div></div></bloc=
kquote><div><br>That's really the question I have about this whole `optiona=
l&lt;T&amp;&gt;` thing: what exactly is the use case for this functionality=
 that `T*` can't also cover?</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1130_27364047.1360204811794--

.

--0016e68dce83cccc7004d519ff2a
Content-Type: text/plain; charset=ISO-8859-1

On 6 February 2013 20:40, Nicol Bolas <jmckesson@gmail.com> wrote:

> That's really the question I have about this whole `optional<T&>` thing:
> what exactly is the use case for this functionality that `T*` can't also
> cover?
>

How about optional<T&&>?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--0016e68dce83cccc7004d519ff2a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 6 February 2013 20:40, Nicol Bolas <span dir=
=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>That&#39;s really the question I have about this whole `optional&lt;T&=
amp;&gt;` thing: what exactly is the use case for this functionality that `=
T*` can&#39;t also cover?</div><div class=3D"yj6qo ajU"><div id=3D":2h4" cl=
ass=3D"ajR" tabindex=3D"0">

</div></div></blockquote></div><br>How about optional&lt;T&amp;&amp;&gt;?<b=
r>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nev=
in@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (8=
47) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--0016e68dce83cccc7004d519ff2a--

.

------=_Part_1536_7806428.1360209322599
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, February 6, 2013 7:25:09 PM UTC-8, Nevin ":-)" Liber wrote:
>
> On 6 February 2013 20:40, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>> That's really the question I have about this whole `optional<T&>` thing:
>> what exactly is the use case for this functionality that `T*` can't also
>> cover?
>>
>
> How about optional<T&&>?
>

I would say that should be illegal. Consider:

T&& t1 = GetT();
T t2(t1); //Calls copy constructor.
T t3(std::move(t1)); //Explicit std::move required to cause move.

optional<T&&> ot1 = GetOptT();
T t2(*ot1); //Calls move constructor. No explicit std::move required.

Much language was expended in the C++11 standard to ensure that you *must*use an explicit std::move for anything that isn't a temporary or the return
from a variable that's going out of scope. optional<T&&> breaks this,
allowing movement without the explicit use of std::move.

optional<T&&>is dangerous.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1536_7806428.1360209322599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, February 6, 2013 7:25:09 PM UTC-8, Nevin ":-)" Liber =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quot=
e">On 6 February 2013 20:40, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1UjJtl3lfBYJ">jmck..=
..@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>That's really the question I have about this whole `optional&lt;T&amp;=
&gt;` thing: what exactly is the use case for this functionality that `T*` =
can't also cover?</div><div><div>

</div></div></blockquote></div><br>How about optional&lt;T&amp;&amp;&gt;?<b=
r></blockquote><div><br>I would say that should be illegal. Consider:<br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>T</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> t1 </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">GetT</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>T t2</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">t1</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">//Calls copy co=
nstructor.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>T t3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">move</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">t1</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">));</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">//Explicit std::move required to cause move.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br>optional</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&amp;&amp;&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> ot1 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">GetOptT</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>T t2</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ot=
1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">//Calls move constructor. =
No explicit std::move required.</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div><br>Much language was ex=
pended in the C++11 standard to ensure that you <i>must</i> use an explicit=
 std::move for anything that isn't a temporary or the return from a variabl=
e that's going out of scope. optional&lt;T&amp;&amp;&gt; breaks this, allow=
ing movement without the explicit use of std::move.</div><br>optional&lt;T&=
amp;&amp;&gt;is dangerous.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1536_7806428.1360209322599--

.

------=_Part_1105_16985628.1360223866535
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 7 lutego 2013 04:55:22 UTC+1 u=BFytkownik Nicol Bolas=20
napisa=B3:
>
>
>
> On Wednesday, February 6, 2013 7:25:09 PM UTC-8, Nevin ":-)" Liber wrote:
>>
>> On 6 February 2013 20:40, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> That's really the question I have about this whole `optional<T&>` thing=
:=20
>>> what exactly is the use case for this functionality that `T*` can't als=
o=20
>>> cover?
>>>
>>
>> How about optional<T&&>?
>>
>
> I would say that should be illegal. Consider:
>
> T&& t1 =3D GetT();
> T t2(t1); //Calls copy constructor.
> T t3(std::move(t1)); //Explicit std::move required to cause move.
>
> optional<T&&> ot1 =3D GetOptT();
> T t2(*ot1); //Calls move constructor. No explicit std::move required.
>
> Much language was expended in the C++11 standard to ensure that you *must=
*use an explicit std::move for anything that isn't a temporary or the retur=
n=20
> from a variable that's going out of scope. optional<T&&> breaks this,=20
> allowing movement without the explicit use of std::move.
>
> optional<T&&>is dangerous.
>

And it is explicitly banned in the proposal.=20

--=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_1105_16985628.1360223866535
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 7 lutego 2013 04:55:22 UTC+1 u=BFytkownik Nicol Bo=
las napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Wedne=
sday, February 6, 2013 7:25:09 PM UTC-8, Nevin ":-)" Liber wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div class=3D"gmail_quote">On 6 February 2013=
 20:40, Nicol Bolas <span dir=3D"ltr">&lt;<a>jmck...@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">

<div>That's really the question I have about this whole `optional&lt;T&amp;=
&gt;` thing: what exactly is the use case for this functionality that `T*` =
can't also cover?</div><div><div>

</div></div></blockquote></div><br>How about optional&lt;T&amp;&amp;&gt;?<b=
r></blockquote><div><br>I would say that should be illegal. Consider:<br><d=
iv style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span=
 style=3D"color:#000"><br>T</span><span style=3D"color:#660">&amp;&amp;</sp=
an><span style=3D"color:#000"> t1 </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">GetT</span=
><span style=3D"color:#660">();</span><span style=3D"color:#000"><br>T t2</=
span><span style=3D"color:#660">(</span><span style=3D"color:#000">t1</span=
><span style=3D"color:#660">);</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#800">//Calls copy constructor.</span><span style=3D"colo=
r:#000"><br>T t3</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">move</span><span style=3D"color:#660">(</span><span style=3D"color:=
#000">t1</span><span style=3D"color:#660">));</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#800">//Explicit std::move required to cau=
se move.</span><span style=3D"color:#000"><br><br>optional</span><span styl=
e=3D"color:#660">&lt;</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">&amp;&amp;&gt;</span><span style=3D"color:#000"> ot1 </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#606">GetOptT</span><span style=3D"color:#660">();</span=
><span style=3D"color:#000"><br>T t2</span><span style=3D"color:#660">(*</s=
pan><span style=3D"color:#000">ot1</span><span style=3D"color:#660">);</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#800">//Calls mov=
e constructor. No explicit std::move required.</span><span style=3D"color:#=
000"><br></span></div></code></div><br>Much language was expended in the C+=
+11 standard to ensure that you <i>must</i> use an explicit std::move for a=
nything that isn't a temporary or the return from a variable that's going o=
ut of scope. optional&lt;T&amp;&amp;&gt; breaks this, allowing movement wit=
hout the explicit use of std::move.</div><br>optional&lt;T&amp;&amp;&gt;is =
dangerous.<br></blockquote><div><br>And it is explicitly banned in the prop=
osal. <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1105_16985628.1360223866535--

.

------=_Part_1604_16439068.1360224755557
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 7 lutego 2013 03:40:11 UTC+1 u=BFytkownik Nicol Bolas=20
napisa=B3:
>
>
>
> On Wednesday, February 6, 2013 6:11:37 PM UTC-8, Sean Parent wrote:
>>
>>
>>
>> Sent from my iPad
>>
>> On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com>=
=20
>> wrote:
>>
>>
>> > mixed assignment is illegal. Use one of the following instead:=20
>>> >=20
>>> > *oi =3D j; // if you want to alter the referred-to object=20
>>> > oi =3D {j}; // if you want to rebind a reference=20
>>> >=20
>>> >>=20
>>> >=20
>>> > Copy constructor and copy assignment are shallow: they only (re)bind =
a=20
>>> > reference. Other operations are deep: this includes comparison (mixed=
=20
>>> or=20
>>> > homogenous)=20
>>> >=20
>>>
>>> Is optional<T&> a RegularType?=20
>>>
>>
>> I am not sure how to answer the question. Different people have slightly=
=20
>> different expectations of a regular type.
>> optional<T&> has:
>>
>>    - default ctor
>>    - destructor
>>    - copy/move constructor (shallow)
>>    - copy/move assignment (shallow)
>>    - equality comparison (deep, provided that T is comparable)
>>
>> Then the answer would be no. The semantics of regular types are well=20
>> defined. See http://www.stepanovpapers.com/DeSt98.pdf. Copies must be=20
>> equal and disjoint. These semantics are not regular. I find it odd that=
=20
>> copying would behave differently than a T& and I'm not sure what this=20
>> construct buys you over a T*.
>>
>
> That's really the question I have about this whole `optional<T&>` thing:=
=20
> what exactly is the use case for this functionality that `T*` can't also=
=20
> cover?
>
=20
This question implies that optional references add no (or too little)=20
value. I agree with it to some extent. First, optional<T> is a useful=20
addition to the standard even w/o optional references. Second, even if=20
optional references are useful, they are needed far less often.=20

What they buy you over raw pointers?

   1. They make the ownership of the memory clear. When you get an optional=
=20
   reference, you are sure you are not responsible for deleting it.
   2. They allow you too smoothly change the signature of your function=20
   from taking T& to taking optional<T&> and you do not need to add=20
   addressof() in all places where the function is called
   3. They allow the usage of optional in "generic contexts".

Personally, I do not find (3) convincing. But people often bring it up. One=
=20
convincing use case, already mentioned in this thread is provided here:=20
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/zCnK=
bHCGsxgJ

Also, the "generic use" does not require optional references. One can=20
implement it oneself using a=20
trick described here:=20
http://kojot.sggw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html#rati=
onale.refs

Regarding (1) and (2), I happened to use optional reference in these=20
contexts and found them more elegant than pointers. But for these usages I=
=20
never needed any kind of optional reference assignment.

--=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_1604_16439068.1360224755557
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 7 lutego 2013 03:40:11 UTC+1 u=BFytkownik Nicol Bo=
las napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Wedne=
sday, February 6, 2013 6:11:37 PM UTC-8, Sean Parent wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"auto"><div><br><br>Sent from my iPad</d=
iv><div><br>On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=F1ski &lt;<a>akrz.=
...@gmail.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><br=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">&gt; mixed assignment is illegal. =
Use one of the following instead:
<br>&gt;
<br>&gt; *oi =3D j; // if you want to alter the referred-to object
<br>&gt; oi =3D {j}; // if you want to rebind a reference
<br>&gt;
<br>&gt;&gt;
<br>&gt;
<br>&gt; Copy constructor and copy assignment are shallow: they only (re)bi=
nd a
<br>&gt; reference. Other operations are deep: this includes comparison (mi=
xed or
<br>&gt; homogenous)
<br>&gt;
<br>
<br>Is optional&lt;T&amp;&gt; a RegularType?
<br></blockquote><div><br>I am not sure how to answer the question. Differe=
nt people have slightly different expectations of a regular type.<br>option=
al&lt;T&amp;&gt; has:<br><ul><li>default ctor</li><li>destructor<br></li><l=
i>copy/move constructor (shallow)</li><li>copy/move assignment (shallow)</l=
i><li>equality comparison (deep, provided that T is comparable)</li></ul></=
div></div></blockquote><div>Then the answer would be no. The semantics of r=
egular types are well defined. See&nbsp;<a href=3D"http://www.stepanovpaper=
s.com/DeSt98.pdf" target=3D"_blank">http://www.stepanovpapers.<wbr>com/DeSt=
98.pdf</a>.&nbsp;Copies must be equal and disjoint. These semantics are not=
 regular. I find it odd that copying would behave differently than a T&amp;=
 and I'm not sure what this construct buys you over a T*.</div></div></bloc=
kquote><div><br>That's really the question I have about this whole `optiona=
l&lt;T&amp;&gt;` thing: what exactly is the use case for this functionality=
 that `T*` can't also cover?</div></blockquote><div>&nbsp;</div><div>This q=
uestion implies that optional references add no (or too little) value. I ag=
ree with it to some extent. First, optional&lt;T&gt; is a useful addition t=
o the standard even w/o optional references. Second, even if optional refer=
ences are useful, they are needed far less often. <br><br>What they buy you=
 over raw pointers?<br><ol><li>They make the ownership of the memory clear.=
 When you get an optional reference, you are sure you are not responsible f=
or deleting it.</li><li>They allow you too smoothly change the signature of=
 your function from taking T&amp; to taking optional&lt;T&amp;&gt; and you =
do not need to add addressof() in all places where the function is called</=
li><li>They allow the usage of optional in "generic contexts".</li></ol><p>=
Personally, I do not find (3) convincing. But people often bring it up. One=
 convincing use case, already mentioned in this thread is provided here: <a=
 href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj=
-5oo/zCnKbHCGsxgJ" target=3D"_blank">https://groups.google.com/a/<wbr>isocp=
p.org/d/msg/std-<wbr>proposals/cXneqUj-5oo/<wbr>zCnKbHCGsxgJ</a></p><p>Also=
, the "generic use" does not require optional references. One can implement=
 it oneself using a <br>trick described here: http://kojot.sggw.waw.pl/~akr=
zemi1/optional/tr2.optional.proposal.html#rationale.refs</p><p>Regarding (1=
) and (2), I happened to use optional reference in these contexts and found=
 them more elegant than pointers. But for these usages I never needed any k=
ind of optional reference assignment.<br></p></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1604_16439068.1360224755557--

.

------=_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 <akrz...@gmail.com<=
javascript:>>=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<T&>& 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<int &> 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<N> 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

<br><br>W dniu =B6roda, 6 lutego 2013 23:48:58 UTC+1 u=BFytkownik Tony V E =
napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Feb 6, 2013 =
at 3:08 PM, Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"cFqy3Ul3LyIJ">akrz...@gmail.com</a>&gt; wrote=
:
<br>&gt;
<br>&gt;&gt; &gt;&gt;
<br>&gt;
<br>&gt; Let me just add one observation about mixed assignment. There is a=
lways this
<br>&gt; case where you are assigning to a disengaged optional reference. I=
n that
<br>&gt; case assigning value is not possible because there is nothing to a=
ssign it
<br>&gt; to, so you have to rebind the reference. This makes the mixed assi=
gnment
<br>&gt; behave like assign_nonrebind():
<br>&gt;
<br>&gt; void assign_norebind(optional&lt;T&amp;&gt;&amp; optref, T&amp; ob=
j)
<br>&gt; {
<br>&gt; &nbsp; &nbsp;if (optref) *optref =3D obj;
<br>&gt; &nbsp; &nbsp;else &nbsp; &nbsp; &nbsp; &nbsp;optref.emplace(obj);
<br>&gt; }
<br>&gt;
<br>&gt; Which, as you observed, "is 2 totally different semantics ('target=
ting' vs
<br>&gt; 'set-value-of-target') rolled into one."
<br>&gt;
<br>
<br>Yes, I was thinking about that after hitting 'send'. &nbsp;Note then th=
at:
<br>
<br>optional&lt;int &amp;&gt; oi; // disengaged
<br>oi =3D 123; //fails - how? exception?
<br>oi =3D j; //works, binds
<br>
<br>And oi =3D j has completely different meaning when oi is engaged vs not=
..
<br>&nbsp;Whereas that is not true for other optionals.
<br>
<br>Or I guess maybe it is true. &nbsp;Any optional&lt;N&gt; even for N tha=
t is
<br>NonRegular has the same assign semantics, right? ie
<br>
<br>&gt; &nbsp; &nbsp;if (optref) *optref =3D obj;
<br>&gt; &nbsp; &nbsp;else &nbsp; &nbsp; &nbsp; &nbsp;optref.emplace(obj);
<br>
<br>ie call assign, else call constructor.
<br>
<br>It is just that for RegularTypes, those are the same thing:
<br>
<br>T a; a =3D b; &nbsp;&lt;=3D=3D&gt; T a =3D b;
<br></blockquote><div><br>Precisely so. And by using assignemt wherever pos=
sible, we get performance optimizations and usually a better exception safe=
ty guarantee.<br><br>Note also that optional provides function emplace(), w=
hich is similar to optional's assignment but never uses T's assignment.<br>=
&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>But for NonRegular types, particularly references, it may not be the
<br>same. &nbsp;I just find it scary on references. &nbsp;...Which brings u=
s back to
<br>why you disabled it. &nbsp;Yet you are only disabling it for references=
,
<br>not for all NonRegular types. &nbsp;So maybe you shouldn't special case
<br>references. &nbsp;If you put any NonRegular types into optional, you ge=
t
<br>what you expect/deserve.(?)
<br></blockquote><div><br>There is some difference between any non-regular =
type and a reference. <br><br>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.<br><br>For a non-regular object type, given t=
he definition of optional&lt;&gt;, you just get what you want - as you said=
 above. If we use a primary template and instantiate it with T&amp; it does=
 not work, it needs a specialization. If we specialize, we need to re-defin=
e the semantics...<br><br>...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...<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_487_2162560.1360225470251--

.

------=_Part_1817_24891913.1360225907195
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 7 lutego 2013 03:11:37 UTC+1 u=BFytkownik Sean Parent=20
napisa=B3:
>
>
>
> Sent from my iPad
>
> On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com<jav=
ascript:>>=20
> wrote:
>
>
> > mixed assignment is illegal. Use one of the following instead:=20
>> >=20
>> > *oi =3D j; // if you want to alter the referred-to object=20
>> > oi =3D {j}; // if you want to rebind a reference=20
>> >=20
>> >>=20
>> >=20
>> > Copy constructor and copy assignment are shallow: they only (re)bind a=
=20
>> > reference. Other operations are deep: this includes comparison (mixed=
=20
>> or=20
>> > homogenous)=20
>> >=20
>>
>> Is optional<T&> a RegularType?=20
>>
>
> I am not sure how to answer the question. Different people have slightly=
=20
> different expectations of a regular type.
> optional<T&> has:
>
>    - default ctor
>    - destructor
>    - copy/move constructor (shallow)
>    - copy/move assignment (shallow)
>    - equality comparison (deep, provided that T is comparable)
>
> Then the answer would be no. The semantics of regular types are well=20
> defined. See http://www.stepanovpapers.com/DeSt98.pdf. Copies must be=20
> equal and disjoint. These semantics are not regular. I find it odd that=
=20
> copying would behave differently than a T& and I'm not sure what this=20
> construct buys you over a T*.
>

 Nicol asked the same question, so I only put link to my other reply:=20
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/1P188wd-TBQ/vP6h=
uYaQ_v4J

In short, the answer is "not much".


>
>    - it is not swappable yet, but I intend to add a shallow swap
>   =20
> Given that it is copyable and assignable how is it not swappable?
>

Logically, having both copy ctor and copy assign implies a swap. The=20
problem is pure technical. We defined the specialization of std::swap for=
=20
any optional (even ref) to call member function swap(), but member function=
=20
swap() was not defined in optional's specialization for references.

--=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_1817_24891913.1360225907195
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 7 lutego 2013 03:11:37 UTC+1 u=BFytkownik Sean Par=
ent napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto=
"><div><br><br>Sent from my iPad</div><div><br>On Feb 5, 2013, at 12:02 PM,=
 Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"BVmrMgkz5PwJ">akrz...@gmail.com</a>&gt; wrote:<br><br></=
div><blockquote type=3D"cite"><div><br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">&gt; mixed assignment is illegal. Use one of the following instead:
<br>&gt;
<br>&gt; *oi =3D j; // if you want to alter the referred-to object
<br>&gt; oi =3D {j}; // if you want to rebind a reference
<br>&gt;
<br>&gt;&gt;
<br>&gt;
<br>&gt; Copy constructor and copy assignment are shallow: they only (re)bi=
nd a
<br>&gt; reference. Other operations are deep: this includes comparison (mi=
xed or
<br>&gt; homogenous)
<br>&gt;
<br>
<br>Is optional&lt;T&amp;&gt; a RegularType?
<br></blockquote><div><br>I am not sure how to answer the question. Differe=
nt people have slightly different expectations of a regular type.<br>option=
al&lt;T&amp;&gt; has:<br><ul><li>default ctor</li><li>destructor<br></li><l=
i>copy/move constructor (shallow)</li><li>copy/move assignment (shallow)</l=
i><li>equality comparison (deep, provided that T is comparable)</li></ul></=
div></div></blockquote><div>Then the answer would be no. The semantics of r=
egular types are well defined. See&nbsp;<a href=3D"http://www.stepanovpaper=
s.com/DeSt98.pdf" target=3D"_blank">http://www.stepanovpapers.<wbr>com/DeSt=
98.pdf</a>.&nbsp;Copies must be equal and disjoint. These semantics are not=
 regular. I find it odd that copying would behave differently than a T&amp;=
 and I'm not sure what this construct buys you over a T*.</div></div></bloc=
kquote><div><br>&nbsp;Nicol asked the same question, so I only put link to =
my other reply: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/=
1P188wd-TBQ/vP6huYaQ_v4J<br><br>In short, the answer is "not much".<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div><=
br></div><blockquote type=3D"cite"><div><div><ul><li>it is not swappable ye=
t, but I intend to add a shallow swap<br></li></ul></div></div></blockquote=
><div>Given that it is copyable and assignable how is it not swappable?</di=
v></div></blockquote><div><br>Logically, having both copy ctor and copy ass=
ign implies a swap. The problem is pure technical. We defined the specializ=
ation of std::swap for any optional (even ref) to call member function swap=
(), but member function swap() was not defined in optional's specialization=
 for references.<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1817_24891913.1360225907195--

.