Topic: std::optional -- hashing optional references
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 17 Dec 2012 12:14:01 -0800 (PST)
Raw View
------=_Part_252_31050022.1355775241911
Content-Type: text/plain; charset=ISO-8859-1
Hi Everybody,
Following the suggestion by Joe Gottman, we intend to make optional<T>
hash-able provided that T itself is hash-able. (We will use T's hash for
engaged optionals, and for disengaged optional we will just pick one
special value). The more difficult question is how to hash optional
references.
1. Should we employ similar logic as unique_ptr and hash only the value
of the underlying raw pointer? (Any T& can be hashed this way)
2. Should we hash the referred-to value? (and enable hashing only for
hash-able Ts)
3. Prevent hashing of optional references?
Given that optional references (with now re-enabled rebinding semantics)
already look similar to pointers, the first choice appears the most
natural. I wonder what others in this group think?
Regards
&rzej
--
------=_Part_252_31050022.1355775241911
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Everybody,<br>Following the suggestion by Joe Gottman, we intend to make=
optional<T> hash-able provided that T itself is hash-able. (We will =
use T's hash for engaged optionals, and for disengaged optional we will jus=
t pick one special value). The more difficult question is how to hash optio=
nal references. <br><ol><li>Should we employ similar logic as unique_ptr an=
d hash only the value of the underlying raw pointer? (Any T& can be has=
hed this way)<br></li><li>Should we hash the referred-to value? (and enable=
hashing only for hash-able Ts)</li><li>Prevent hashing of optional referen=
ces?</li></ol><p>Given that optional references (with now re-enabled rebind=
ing semantics) already look similar to pointers, the first choice appears t=
he most natural. I wonder what others in this group think?</p><p>Regards<br=
>&rzej<br></p>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_252_31050022.1355775241911--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 17 Dec 2012 15:26:58 -0600
Raw View
--bcaec554d29aeba49204d1130c3f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 17 December 2012 14:14, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wr=
ote:
> Hi Everybody,
> Following the suggestion by Joe Gottman, we intend to make optional<T>
> hash-able provided that T itself is hash-able. (We will use T's hash for
> engaged optionals, and for disengaged optional we will just pick one
> special value). The more difficult question is how to hash optional
> references.
>
> 1. Should we employ similar logic as unique_ptr and hash only the
> value of the underlying raw pointer? (Any T& can be hashed this way)
> 2. Should we hash the referred-to value? (and enable hashing only for
> hash-able Ts)
>
>
Given that the underlying value can be changed out from under the optional
reference, I don't believe 2 is a viable solution.
For instance:
int i =3D 3;
int j =3D 5;
optional<int&> oi =3D i;
optional<int&> oj =3D j;
unordered_set<optional<int&>> s;
s.insert(i);
s.insert(j);
j =3D 2; // we just broke the invariants for unordered_set
> 3. Prevent hashing of optional references?
Was there an argument for optional references besides uniformity in
template code (which I am in favor of)? The reason I am asking is that I
don't see that same uniformity for use as a key in a set or map, but if
there is another reason, it could sway my thoughts on (1) vs. (3). Note:
I'm *not* looking to reopen that debate; I just can't remember, and there
are way too many messages in previous threads to go back and look right now=
..
At this point, I'm neutral on 1, strongly against 2, and weakly for 3.
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
--bcaec554d29aeba49204d1130c3f
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On 17 December 2012 14:14, Andrzej Krzemie=F1ski <span dir=3D"ltr"><<a h=
ref=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>&=
gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
Hi Everybody,<br>Following the suggestion by Joe Gottman, we intend to make=
optional<T> hash-able provided that T itself is hash-able. (We will =
use T's hash for engaged optionals, and for disengaged optional we will=
just pick one special value). The more difficult question is how to hash o=
ptional references. <br>
<ol><li>Should we employ similar logic as unique_ptr and hash only the valu=
e of the underlying raw pointer? (Any T& can be hashed this way)<br></l=
i><li>Should we hash the referred-to value? (and enable hashing only for ha=
sh-able Ts)</li>
</ol></blockquote><div><br></div><div>Given that the underlying value can b=
e changed out from under the optional reference, I don't believe 2 is a=
viable solution.</div><div><br></div><div>For instance:</div><div><br>
</div><div>int i =3D 3;</div><div>int j =3D 5;</div><div>optional<int&am=
p;> oi =3D i;</div><div>optional<int&> oj =3D j;</div><div>uno=
rdered_set<optional<int&>> s;</div><div>s.insert(i);</div><=
div>
s.insert(j);</div><div>j =3D 2; // we just broke the invariants for unorder=
ed_set</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
3. Prevent hashing of optional references?</blockquote><div><br></div><div>=
Was there an argument for optional references besides uniformity in templat=
e code (which I am in favor of)? =A0The reason I am asking is that I don=
9;t see that same uniformity for use as a key in a set or map, but if there=
is another reason, it could sway my thoughts on (1) vs. (3). =A0Note: =A0I=
'm *not* looking to reopen that debate; I just can't remember, and =
there are way too many messages in previous threads to go back and look rig=
ht now.</div>
<div><br></div><div>At this point, I'm neutral on 1, strongly against 2=
, and weakly for 3.</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <=
;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@e=
viloverlord.com</a>>=A0 (847) 691-1404<br>
<p></p>
-- <br />
<br />
<br />
<br />
--bcaec554d29aeba49204d1130c3f--
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Mon, 17 Dec 2012 21:35:48 +0000
Raw View
This is a multi-part message in MIME format.
--------------070400080904030008040806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 17/12/12 20:14, Andrzej Krzemien'ski wrote:
> Hi Everybody,
> Following the suggestion by Joe Gottman, we intend to make optional<T>
> hash-able provided that T itself is hash-able. (We will use T's hash
> for engaged optionals, and for disengaged optional we will just pick
> one special value). The more difficult question is how to hash
> optional references.
>
> 1. Should we employ similar logic as unique_ptr and hash only the
> value of the underlying raw pointer? (Any T& can be hashed this way)
> 2. Should we hash the referred-to value? (and enable hashing only for
> hash-able Ts)
> 3. Prevent hashing of optional references?
>
> Given that optional references (with now re-enabled rebinding
> semantics) already look similar to pointers, the first choice appears
> the most natural. I wonder what others in this group think?
>
There is a much bigger issue of hashing many standard types, including
all the standard containers. The basic definition of a valid hash
function is:
if a == b, then hash(a) == hash(b).
This obviously requires a valid hash function for the optional value,
and just requiring the hash function is valid would be (in my opinion)
sufficient.
Chris
--
--------------070400080904030008040806
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 17/12/12 20:14, Andrzej Krzemieński
wrote:<br>
</div>
<blockquote
cite="mid:b6cf06c1-e4a9-462e-b2f2-2113fe249318@isocpp.org"
type="cite">Hi Everybody,<br>
Following the suggestion by Joe Gottman, we intend to make
optional<T> hash-able provided that T itself is hash-able.
(We will use T's hash for engaged optionals, and for disengaged
optional we will just pick one special value). The more difficult
question is how to hash optional references. <br>
<ol>
<li>Should we employ similar logic as unique_ptr and hash only
the value of the underlying raw pointer? (Any T& can be
hashed this way)<br>
</li>
<li>Should we hash the referred-to value? (and enable hashing
only for hash-able Ts)</li>
<li>Prevent hashing of optional references?</li>
</ol>
<p>Given that optional references (with now re-enabled rebinding
semantics) already look similar to pointers, the first choice
appears the most natural. I wonder what others in this group
think?<br>
</p>
</blockquote>
<br>
There is a much bigger issue of hashing many standard types,
including all the standard containers. The basic definition of a
valid hash function is:<br>
<br>
if a == b, then hash(a) == hash(b).<br>
<br>
This obviously requires a valid hash function for the optional
value, and just requiring the hash function is valid would be (in my
opinion) sufficient.<br>
<br>
Chris<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070400080904030008040806--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 18 Dec 2012 00:30:36 -0800 (PST)
Raw View
------=_Part_119_2749960.1355819436999
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 17 grudnia 2012 22:26:58 UTC+1 u=BFytkownik Nevin ":=
-)"=20
Liber napisa=B3:
>
> On 17 December 2012 14:14, Andrzej Krzemie=F1ski <akrz...@gmail.com<javas=
cript:>
> > wrote:
>
>> Hi Everybody,
>> Following the suggestion by Joe Gottman, we intend to make optional<T>=
=20
>> hash-able provided that T itself is hash-able. (We will use T's hash for=
=20
>> engaged optionals, and for disengaged optional we will just pick one=20
>> special value). The more difficult question is how to hash optional=20
>> references.=20
>>
>> 1. Should we employ similar logic as unique_ptr and hash only the=20
>> value of the underlying raw pointer? (Any T& can be hashed this way)
>> 2. Should we hash the referred-to value? (and enable hashing only for=
=20
>> hash-able Ts)=20
>>
>>
> Given that the underlying value can be changed out from under the optiona=
l=20
> reference, I don't believe 2 is a viable solution.
>
> For instance:
>
> int i =3D 3;
> int j =3D 5;
> optional<int&> oi =3D i;
> optional<int&> oj =3D j;
> unordered_set<optional<int&>> s;
> s.insert(i);
> s.insert(j);
> j =3D 2; // we just broke the invariants for unordered_set
> =20
>
>> 3. Prevent hashing of optional references?
>
>
> Was there an argument for optional references besides uniformity in=20
> template code (which I am in favor of)? The reason I am asking is that I=
=20
> don't see that same uniformity for use as a key in a set or map, but if=
=20
> there is another reason, it could sway my thoughts on (1) vs. (3). Note:=
=20
> I'm *not* looking to reopen that debate; I just can't remember, and ther=
e=20
> are way too many messages in previous threads to go back and look right n=
ow.
>
> At this point, I'm neutral on 1, strongly against 2, and weakly for 3.
>
Another motivation for using optional references -- not even in generic=20
contexts -- is that they offer an attractive alternative to pointers: same=
=20
observer functions, simpler initialization (no addressof() required), and=
=20
the type makes it clear who the owner is.
Regards,
&rzej
--=20
------=_Part_119_2749960.1355819436999
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=B3ek, 17 grudnia 2012 22:26:58 UTC+1 u=BFytkownik =
Nevin ":-)" Liber napisa=B3:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
17 December 2012 14:14, Andrzej Krzemie=F1ski <span dir=3D"ltr"><<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GAEAaXBdJ9kJ">=
akrz...@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
Hi Everybody,<br>Following the suggestion by Joe Gottman, we intend to make=
optional<T> hash-able provided that T itself is hash-able. (We will =
use T's hash for engaged optionals, and for disengaged optional we will jus=
t pick one special value). The more difficult question is how to hash optio=
nal references. <br>
<ol><li>Should we employ similar logic as unique_ptr and hash only the valu=
e of the underlying raw pointer? (Any T& can be hashed this way)<br></l=
i><li>Should we hash the referred-to value? (and enable hashing only for ha=
sh-able Ts)</li>
</ol></blockquote><div><br></div><div>Given that the underlying value can b=
e changed out from under the optional reference, I don't believe 2 is a via=
ble solution.</div><div><br></div><div>For instance:</div><div><br>
</div><div>int i =3D 3;</div><div>int j =3D 5;</div><div>optional<int&am=
p;> oi =3D i;</div><div>optional<int&> oj =3D j;</div><div>uno=
rdered_set<optional<int&>> s;</div><div>s.insert(i);</div><=
div>
s.insert(j);</div><div>j =3D 2; // we just broke the invariants for unorder=
ed_set</div><div> </div><blockquote class=3D"gmail_quote" style=3D"mar=
gin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">
3. Prevent hashing of optional references?</blockquote><div><br></div><div>=
Was there an argument for optional references besides uniformity in templat=
e code (which I am in favor of)? The reason I am asking is that I don=
't see that same uniformity for use as a key in a set or map, but if there =
is another reason, it could sway my thoughts on (1) vs. (3). Note: &n=
bsp;I'm *not* looking to reopen that debate; I just can't remember, and the=
re are way too many messages in previous threads to go back and look right =
now.</div>
<div><br></div><div>At this point, I'm neutral on 1, strongly against 2, an=
d weakly for 3.</div></div></blockquote><div><br>Another motivation for usi=
ng optional references -- not even in generic contexts -- is that they offe=
r an attractive alternative to pointers: same observer functions, simpler i=
nitialization (no addressof() required), and the type makes it clear who th=
e owner is.<br><br>Regards,<br>&rzej<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_119_2749960.1355819436999--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 18 Dec 2012 00:46:21 -0800 (PST)
Raw View
------=_Part_131_12438221.1355820381634
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 17 grudnia 2012 22:35:48 UTC+1 u=BFytkownik Chris=20
Jefferson napisa=B3:
>
> On 17/12/12 20:14, Andrzej Krzemie=F1ski wrote:
> =20
> Hi Everybody,
> Following the suggestion by Joe Gottman, we intend to make optional<T>=20
> hash-able provided that T itself is hash-able. (We will use T's hash for=
=20
> engaged optionals, and for disengaged optional we will just pick one=20
> special value). The more difficult question is how to hash optional=20
> references.=20
>
> 1. Should we employ similar logic as unique_ptr and hash only the=20
> value of the underlying raw pointer? (Any T& can be hashed this way)
> 2. Should we hash the referred-to value? (and enable hashing only for=
=20
> hash-able Ts)=20
> 3. Prevent hashing of optional references?=20
>
> Given that optional references (with now re-enabled rebinding semantics)=
=20
> already look similar to pointers, the first choice appears the most=20
> natural. I wonder what others in this group think?
> =20
>
> There is a much bigger issue of hashing many standard types, including al=
l=20
> the standard containers. The basic definition of a valid hash function is=
:
>
> if a =3D=3D b, then hash(a) =3D=3D hash(b).
>
> This obviously requires a valid hash function for the optional value, and=
=20
> just requiring the hash function is valid would be (in my opinion)=20
> sufficient.
>
Thanks for the insightful answer. Now I realize what the nature of the=20
problem is. Namely, it is not clear for optional<T&> what its value (or=20
"the set of salient attributes") is. Is it only the pointer, or also the=20
referred-to value. I realize this is reopening of the previous debate, but=
=20
I believe it is important: current behavior (hashing aside) is=20
inconsistent: the assignment is shallow, but equality-comparison is deep.=
=20
On the other hand, C++ references themselves display this inconsistency:=20
their copy construction is shallow, but their comparison is deep. So, the=
=20
behavior might be right, although chosen unconsciously. I do not know where=
=20
the hashing function falls though. Perhaps the equality comparison should=
=20
be changed.
Regards,
&rzej
--=20
------=_Part_131_12438221.1355820381634
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=B3ek, 17 grudnia 2012 22:35:48 UTC+1 u=BFytkownik =
Chris Jefferson napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>On 17/12/12 20:14, Andrzej Krzemie=F1ski
wrote:<br>
</div>
<blockquote type=3D"cite">Hi Everybody,<br>
Following the suggestion by Joe Gottman, we intend to make
optional<T> hash-able provided that T itself is hash-able.
(We will use T's hash for engaged optionals, and for disengaged
optional we will just pick one special value). The more difficult
question is how to hash optional references. <br>
<ol>
<li>Should we employ similar logic as unique_ptr and hash only
the value of the underlying raw pointer? (Any T& can be
hashed this way)<br>
</li>
<li>Should we hash the referred-to value? (and enable hashing
only for hash-able Ts)</li>
<li>Prevent hashing of optional references?</li>
</ol>
<p>Given that optional references (with now re-enabled rebinding
semantics) already look similar to pointers, the first choice
appears the most natural. I wonder what others in this group
think?<br>
</p>
</blockquote>
<br>
There is a much bigger issue of hashing many standard types,
including all the standard containers. The basic definition of a
valid hash function is:<br>
<br>
if a =3D=3D b, then hash(a) =3D=3D hash(b).<br>
<br>
This obviously requires a valid hash function for the optional
value, and just requiring the hash function is valid would be (in my
opinion) sufficient.<br></div></blockquote><div><br>Thanks for the insi=
ghtful answer. Now I realize what the nature of the problem is. Namely, it =
is not clear for optional<T&> what its value (or "the set of sali=
ent attributes") is. Is it only the pointer, or also the referred-to value.=
I realize this is reopening of the previous debate, but I believe it is im=
portant: current behavior (hashing aside) is inconsistent: the assignment i=
s shallow, but equality-comparison is deep. <br><br>On the other hand, C++ =
references themselves display this inconsistency: their copy construction i=
s shallow, but their comparison is deep. So, the behavior might be right, a=
lthough chosen unconsciously. I do not know where the hashing function fall=
s though. Perhaps the equality comparison should be changed.<br><br>Regards=
,<br>&rzej<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_131_12438221.1355820381634--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 18 Dec 2012 10:43:24 -0600
Raw View
--0015175cfcccc03adb04d12334f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 18 December 2012 02:46, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wr=
ote:
>
> On the other hand, C++ references themselves display this inconsistency:
> their copy construction is shallow, but their comparison is deep. So, the
> behavior might be right, although chosen unconsciously. I do not know whe=
re
> the hashing function falls though. Perhaps the equality comparison should
> be changed.
>
Hashing and comparison operators should all be consistent with each other.
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
--0015175cfcccc03adb04d12334f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 18 December 2012 02:46, Andrzej Krzemie=C5=84ski <span dir=3D"ltr"><<=
a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</=
a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<br><div>On the other hand, C++ references themselves display this inconsis=
tency: their copy construction is shallow, but their comparison is deep. So=
, the behavior might be right, although chosen unconsciously. I do not know=
where the hashing function falls though. Perhaps the equality comparison s=
hould be changed.<br clear=3D"all">
</div></blockquote><div><br>Hashing and comparison operators should all be =
consistent with each other.<br></div></div>-- <br>=C2=A0Nevin ":-)&quo=
t; Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404<br>
<p></p>
-- <br />
<br />
<br />
<br />
--0015175cfcccc03adb04d12334f4--
.
Author: stackmachine@hotmail.com
Date: Tue, 18 Dec 2012 09:01:45 -0800 (PST)
Raw View
------=_Part_85_14059469.1355850105535
Content-Type: text/plain; charset=ISO-8859-1
I think optional references should just be disallowed. References aren't
objects, they don't have an address and it therefore doesn't make sense to
'store' them inside an optional. If you want an optional reference, you
actually want a pointer.
--
------=_Part_85_14059469.1355850105535
Content-Type: text/html; charset=ISO-8859-1
I think optional references should just be disallowed. References aren't objects, they don't have an address and it therefore doesn't make sense to 'store' them inside an optional. If you want an optional reference, you actually want a pointer.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_85_14059469.1355850105535--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 18 Dec 2012 11:10:20 -0600
Raw View
--0015174c12ce46e81b04d123aae5
Content-Type: text/plain; charset=ISO-8859-1
On 18 December 2012 11:01, <stackmachine@hotmail.com> wrote:
> I think optional references should just be disallowed. References aren't
> objects, they don't have an address and it therefore doesn't make sense to
> 'store' them inside an optional. If you want an optional reference, you
> actually want a pointer.
Are we really going to reopen that discussion again? I don't see any new
information being presented, and I'd rather we make forward progress so
that we have a chance of actually getting optional into the standard.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--0015174c12ce46e81b04d123aae5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 18 December 2012 11:01, <span dir=3D"ltr"><<a href=3D"mailto:stackma=
chine@hotmail.com" target=3D"_blank">stackmachine@hotmail.com</a>></span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think optional references should just be disallowed. References aren'=
t objects, they don't have an address and it therefore doesn't make=
sense to 'store' them inside an optional. If you want an optional =
reference, you actually want a pointer.</blockquote>
<div><br></div><div>Are we really going to reopen that discussion again? =
=A0I don't see any new information being presented, and I'd rather =
we make forward progress so that we have a chance of actually getting optio=
nal into the standard.=A0</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404<br>
<p></p>
-- <br />
<br />
<br />
<br />
--0015174c12ce46e81b04d123aae5--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 14:56:06 -0300
Raw View
On Tue, Dec 18, 2012 at 2:10 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 18 December 2012 11:01, <stackmachine@hotmail.com> wrote:
>>
>> I think optional references should just be disallowed. References aren't
>> objects, they don't have an address and it therefore doesn't make sense to
>> 'store' them inside an optional. If you want an optional reference, you
>> actually want a pointer.
>
>
> Are we really going to reopen that discussion again?
I hope not.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 15:16:34 -0300
Raw View
On Mon, Dec 17, 2012 at 5:14 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
> Hi Everybody,
> Following the suggestion by Joe Gottman, we intend to make optional<T>
> hash-able provided that T itself is hash-able. (We will use T's hash for
> engaged optionals, and for disengaged optional we will just pick one spec=
ial
> value). The more difficult question is how to hash optional references.
>
> Should we employ similar logic as unique_ptr and hash only the value of t=
he
> underlying raw pointer?
IMO, this is the most logical choice.
The reason is that, again IMHO, if you are using an associative
container of references instead of values, you want object identity as
the default meaning for equality. That's exactly what you get if you
use pointers (or if you could use bare references).
If that's not really the behavior you want, then you should provide
your own hash function that hashes the referenced/pointed-to object.
I agree with Nevin that option 2 is certainly wrong.
I could live with 3 FWIW, but I like 2 better since, in C++, I always
prefer to have features, even if they must be used with the proper
understanding of how they work, than to miss them.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
.
Author: stackmachine@hotmail.com
Date: Tue, 18 Dec 2012 10:16:34 -0800 (PST)
Raw View
------=_Part_430_33056497.1355854595021
Content-Type: text/plain; charset=ISO-8859-1
What discussion? Did I miss something?
--
------=_Part_430_33056497.1355854595021
Content-Type: text/html; charset=ISO-8859-1
What discussion? Did I miss something?<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_430_33056497.1355854595021--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 15:23:45 -0300
Raw View
On Tue, Dec 18, 2012 at 3:16 PM, <stackmachine@hotmail.com> wrote:
> What discussion? Did I miss something?
>
The one about optional references, and what should they be like.
It has been going on for several years now (not continuously of
course). It is the main reason why we didn't have std::optional in
2003.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 15:26:32 -0300
Raw View
On Tue, Dec 18, 2012 at 3:23 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Tue, Dec 18, 2012 at 3:16 PM, <stackmachine@hotmail.com> wrote:
>> What discussion? Did I miss something?
>>
> The one about optional references, and what should they be like.
>
> It has been going on for several years now (not continuously of
> course). It is the main reason why we didn't have std::optional in
> 2003.
>
Well, no, that was before I presented the first paper.
I meant already, as in TR1 or C++11
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 18 Dec 2012 11:47:44 -0800 (PST)
Raw View
------=_Part_231_4868879.1355860064792
Content-Type: text/plain; charset=ISO-8859-1
> > Should we employ similar logic as unique_ptr and hash only the value of
> the
> > underlying raw pointer?
>
> IMO, this is the most logical choice.
>
> The reason is that, again IMHO, if you are using an associative
> container of references instead of values, you want object identity as
> the default meaning for equality. That's exactly what you get if you
> use pointers (or if you could use bare references).
> If that's not really the behavior you want, then you should provide
> your own hash function that hashes the referenced/pointed-to object.
>
> I agree with Nevin that option 2 is certainly wrong.
>
> I could live with 3 FWIW, but I like 2 better since, in C++, I always
> prefer to have features, even if they must be used with the proper
> understanding of how they work, than to miss them.
>
Let me summarize my understanding of the problem so far:
A. In the currently proposed optional references operator== performs a deep
comparison (it also compares the referred-to value).
B. If optional references are hash-able, operator== and the default hash
shall be consistnt with one another. This can be expressed as: if a == b,
then hash(a) == hash(b).
C. If we apply "deep hashing" (option 2 from my above list), it is easy to
corrupt the associative container of optional references, because the
(deep) state of contained object can be easily altered from outside the
container (as explained by Nevin above).
Now, if we want to avoid problem in "C", we have to apply shallow (raw
pointer) hashing (option 1 from my list). But that violates point "B". The
only way to fix it (that I can see) is to change "A" and provide shallow
equality comparison for optional references. This makes optional references
work even more like raw pointers, and less like C++ native references. We
still have a reasonable picture of optional references: they are like raw
pointers, except that you initialize them without addressof().
So to summarize, I propose shallow hash and shallow comparison for optional
refs.
What do you think?
Regards,
&rzej
--
------=_Part_231_4868879.1355860064792
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;">> Should we employ simi=
lar logic as unique_ptr and hash only the value of the
<br>> underlying raw pointer?
<br>
<br>IMO, this is the most logical choice.
<br>
<br>The reason is that, again IMHO, if you are using an associative
<br>container of references instead of values, you want object identity as
<br>the default meaning for equality. That's exactly what you get if you
<br>use pointers (or if you could use bare references).
<br>If that's not really the behavior you want, then you should provide
<br>your own hash function that hashes the referenced/pointed-to object.
<br>
<br>I agree with Nevin that option 2 is certainly wrong.
<br>
<br>I could live with 3 FWIW, but I like 2 better since, in C++, I always
<br>prefer to have features, even if they must be used with the proper
<br>understanding of how they work, than to miss them.
<br></blockquote><div><br>Let me summarize my understanding of the problem =
so far:<br><br>A. In the currently proposed optional references operator=3D=
=3D performs a deep comparison (it also compares the referred-to value).<br=
><br>B. If optional references are hash-able, operator=3D=3D and the defaul=
t hash shall be consistnt with one another. This can be expressed as: if a =
=3D=3D b, then hash(a) =3D=3D hash(b).<br><br>C. If we apply "deep hashing"=
(option 2 from my above list), it is easy to corrupt the associative conta=
iner of optional references, because the (deep) state of contained object c=
an be easily altered from outside the container (as explained by Nevin abov=
e).<br><br>Now, if we want to avoid problem in "C", we have to apply shallo=
w (raw pointer) hashing (option 1 from my list). But that violates point "B=
". The only way to fix it (that I can see) is to change "A" and provide sha=
llow equality comparison for optional references. This makes optional refer=
ences work even more like raw pointers, and less like C++ native references=
.. We still have a reasonable picture of optional references: they are like =
raw pointers, except that you initialize them without addressof().<br><br>S=
o to summarize, I propose shallow hash and shallow comparison for optional =
refs.<br>What do you think?<br><br>Regards,<br>&rzej <br><br><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_231_4868879.1355860064792--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 18 Dec 2012 11:52:37 -0800 (PST)
Raw View
------=_Part_37_31727249.1355860358121
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 18 grudnia 2012 19:16:34 UTC+1 u=BFytkownik=20
stackm...@hotmail.com napisa=B3:
>
> What discussion? Did I miss something?
>
For instance:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/cXneqUj-=
5oo
http://lists.boost.org/Archives/boost/2003/10/55549.php
http://lists.boost.org/Archives/boost/2005/03/81141.php
https://groups.google.com/forum/?fromgroups#!msg/boost-developers-archive/C=
gjtV0ZLw8c/0rNj66FxSXAJ
https://groups.google.com/d/msg/boost-developers-archive/CgjtV0ZLw8c/uS5vzz=
BVajoJ =20
Regards,
&rzej
--=20
------=_Part_37_31727249.1355860358121
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu wtorek, 18 grudnia 2012 19:16:34 UTC+1 u=BFytkownik stackm..=
..@hotmail.com napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What d=
iscussion? Did I miss something?<br></blockquote><div><br>For instance:<br>=
<br><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-pro=
posals/cXneqUj-5oo">https://groups.google.com/a/isocpp.org/forum/#!topic/st=
d-proposals/cXneqUj-5oo</a><br><a href=3D"http://lists.boost.org/Archives/b=
oost/2003/10/55549.php" target=3D"_blank">http://lists.boost.org/<wbr>Archi=
ves/boost/2003/10/55549.<wbr>php</a><br><a href=3D"http://lists.boost.org/A=
rchives/boost/2005/03/81141.php" target=3D"_blank">http://lists.boost.org/<=
wbr>Archives/boost/2005/03/81141.<wbr>php</a><br><a href=3D"https://groups.=
google.com/forum/?fromgroups#%21msg/boost-developers-archive/CgjtV0ZLw8c/0r=
Nj66FxSXAJ" target=3D"_blank">https://groups.google.com/<wbr>forum/?fromgro=
ups#!msg/boost-<wbr>developers-archive/<wbr>CgjtV0ZLw8c/0rNj66FxSXAJ</a><br=
><a href=3D"https://groups.google.com/d/msg/boost-developers-archive/CgjtV0=
ZLw8c/uS5vzzBVajoJ" target=3D"_blank">https://groups.google.com/d/<wbr>msg/=
boost-developers-archive/<wbr>CgjtV0ZLw8c/uS5vzzBVajoJ</a> <br><br>Re=
gards,<br>&rzej<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_37_31727249.1355860358121--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 18 Dec 2012 21:21:18 +0100
Raw View
2012/12/18 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>
> Let me summarize my understanding of the problem so far:
>
> A. In the currently proposed optional references operator=3D=3D performs =
a deep
> comparison (it also compares the referred-to value).
>
> B. If optional references are hash-able, operator=3D=3D and the default h=
ash
> shall be consistnt with one another. This can be expressed as: if a =3D=
=3D b,
> then hash(a) =3D=3D hash(b).
>
> C. If we apply "deep hashing" (option 2 from my above list), it is easy t=
o
> corrupt the associative container of optional references, because the (de=
ep)
> state of contained object can be easily altered from outside the containe=
r
> (as explained by Nevin above).
>
> Now, if we want to avoid problem in "C", we have to apply shallow (raw
> pointer) hashing (option 1 from my list). But that violates point "B". Th=
e
> only way to fix it (that I can see) is to change "A" and provide shallow
> equality comparison for optional references. This makes optional referenc=
es
> work even more like raw pointers, and less like C++ native references. We
> still have a reasonable picture of optional references: they are like raw
> pointers, except that you initialize them without addressof().
>
> So to summarize, I propose shallow hash and shallow comparison for option=
al
> refs.
> What do you think?
I'm not convinced that reasoning C is a complete show-stopper for deep
value semantics
of optional<T&>. You can a lot of useless or "dangerous" things, if
you are careless,
the question is whether one really gets hurt by that.
Let me remind that the following is already possible:
#include <set>
#include <functional>
#include <iostream>
int main()
{
std::set<std::reference_wrapper<int>> s;
int i =3D 1;
int j =3D 2;
s.insert(std::ref(i));
s.insert(std::ref(j));
int k =3D 1;
std::cout << (s.end() !=3D s.find(std::ref(k))) << std::endl;
j =3D -1; // Oops
}
I have never stumbled across practical problems with that possibility.
Similar things can be done with pairs or tuples of references:
#include <set>
#include <functional>
#include <tuple>
#include <iostream>
int main()
{
std::set<std::tuple<int&>> s;
int i =3D 1;
int j =3D 2;
s.insert(std::make_tuple(std::ref(i)));
s.insert(std::make_tuple(std::ref(j)));
int k =3D 1;
std::cout << (s.end() !=3D s.find(std::make_tuple(std::ref(k)))) << std=
::endl;
int r =3D 100;
std::cout << (s.end() =3D=3D s.find(std::make_tuple(std::ref(r)))) << s=
td::endl;
j =3D -1; // Oops
}
Again, even though tuples and pairs are quite popular in code that I have s=
een
this property of silently mutating objects hasn't been reported as a
major problem
to me.
Actually "reference-like" objects are what Java and .NET languages heavily =
use.
People learn to handle this.
Real pointers or smart pointers in C++ all behave similarly as the
presented objects.
Even, if the default equality or default hash behave on pointer values, no-=
one
hinders you to provide value-evaluating predicates, hashers, or
comparison functions, so
what?
In my opinion it should be considered more important, what an optional<T&>
represents. If this is similar to reference_wrapper and =3D=3D and hash are
consistent, this is fine for me.
If you prefer to consider them as pointers, I can accept this, too,
but I tend to
prefer that optional<T&> behaves "value-like" in regard to =3D=3D, hash,
and comparison
functions.
Just my two Euro Cents,
- Daniel
--=20
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 17:03:00 -0300
Raw View
On Tue, Dec 18, 2012 at 4:47 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> So to summarize, I propose shallow hash and shallow comparison for option=
al
> refs.
Right.
I thought we were doing that for comparisons already. We should.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Wed, 19 Dec 2012 00:41:33 +0000
Raw View
On 18/12/12 20:03, Fernando Cacciola wrote:
> On Tue, Dec 18, 2012 at 4:47 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.co=
m> wrote:
>>
>> So to summarize, I propose shallow hash and shallow comparison for optio=
nal
>> refs.
> Right.
>
> I thought we were doing that for comparisons already. We should.
Could you give me a justification for this?
I was working under the mental model that if 'a =3D=3D b', then given an=20
optional oa assigned a and an optional ob assigned b, 'ao =3D=3D ab', so=20
optional<T> is kind of like 'T with an extra value, denoting empty'.
Given this mental model, why would an optional<T&> only do a shallow=20
comparison, comparing memory locations? I'm thinking about how I would=20
explain / teach this decision.
I understand there are issues about putting values in containers, but=20
the same issues arise in any class which contains references or pointers=20
to external data when put into a standard container.
Chris
--=20
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 18 Dec 2012 18:58:48 -0600
Raw View
On Tue, Dec 18, 2012 at 2:21 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> In my opinion it should be considered more important, what an optional<T&=
>
> represents. If this is similar to reference_wrapper and =3D=3D and hash a=
re
> consistent, this is fine for me.
reference_wrapper-like +1. It looks like a reference wrapper, then it
is. If users
want a shallow comparison/hashing, they can choose optional<T*> (not banish=
ed,
I think?).
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 22:34:38 -0300
Raw View
On Tue, Dec 18, 2012 at 5:21 PM, Daniel Kr=C3=BCgler
<daniel.kruegler@gmail.com> wrote:
> 2012/12/18 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>>
>> Let me summarize my understanding of the problem so far:
>>
>> A. In the currently proposed optional references operator=3D=3D performs=
a deep
>> comparison (it also compares the referred-to value).
>>
>> B. If optional references are hash-able, operator=3D=3D and the default =
hash
>> shall be consistnt with one another. This can be expressed as: if a =3D=
=3D b,
>> then hash(a) =3D=3D hash(b).
>>
>> C. If we apply "deep hashing" (option 2 from my above list), it is easy =
to
>> corrupt the associative container of optional references, because the (d=
eep)
>> state of contained object can be easily altered from outside the contain=
er
>> (as explained by Nevin above).
>>
>> Now, if we want to avoid problem in "C", we have to apply shallow (raw
>> pointer) hashing (option 1 from my list). But that violates point "B". T=
he
>> only way to fix it (that I can see) is to change "A" and provide shallow
>> equality comparison for optional references. This makes optional referen=
ces
>> work even more like raw pointers, and less like C++ native references. W=
e
>> still have a reasonable picture of optional references: they are like ra=
w
>> pointers, except that you initialize them without addressof().
>>
>> So to summarize, I propose shallow hash and shallow comparison for optio=
nal
>> refs.
>> What do you think?
>
> I'm not convinced that reasoning C is a complete show-stopper for deep
> value semantics
> of optional<T&>. You can a lot of useless or "dangerous" things, if
> you are careless,
> the question is whether one really gets hurt by that.
>
> Let me remind that the following is already possible:
>
> #include <set>
> #include <functional>
> #include <iostream>
>
> int main()
> {
> std::set<std::reference_wrapper<int>> s;
I couldn't find the definition of hash for reference_wrapper.
Where is it? and how is it defined?
Not could I found its operator =3D=3D or a specialization of less<>.
In any case, I do agree with you that aliasing side effects are not
necessarily a strong case against deep hashing.
My reasons against it are different. Please see my response to the
question in the next post.
> optional<T&> behaves "value-like" in regard to =3D=3D, hash,
> and comparison
> functions.
>
I'll borrow this for the next response.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 22:50:52 -0300
Raw View
On Tue, Dec 18, 2012 at 9:41 PM, Chris Jefferson <chris@bubblescope.net> wr=
ote:
> On 18/12/12 20:03, Fernando Cacciola wrote:
>>
>> On Tue, Dec 18, 2012 at 4:47 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmai=
l.com>
>> wrote:
>>>
>>>
>>> So to summarize, I propose shallow hash and shallow comparison for
>>> optional
>>> refs.
>>
>> Right.
>>
>> I thought we were doing that for comparisons already. We should.
>
>
> Could you give me a justification for this?
>
I can give you a reason. But not a justification as in an argument as
in "this is correct and anything else is not".
> I was working under the mental model that if 'a =3D=3D b', then given an
> optional oa assigned a and an optional ob assigned b, 'ao =3D=3D ab', so
> optional<T> is kind of like 'T with an extra value, denoting empty'.
>
> Given this mental model, why would an optional<T&> only do a shallow
> comparison, comparing memory locations? I'm thinking about how I would
> explain / teach this decision.
>
It has already been establish that if oa =3D=3D ob then *necessarily*
hash(oa)=3D=3Dhash(ob)
This is a hard requirement because hashing is used to separate
elements into buckets to avoid comparing them, so we can't have
objects that compare equal into separate buckets or we'll never find
them as corresponding to the same equality class (i.e. algorithms
won't work correctly)
So, we don't really have a choice of semantics for hash, it directly
depends on operator =3D=3D
Now....
Here is the debate again that I hoped to avoid by it flushing the
decision kind of arbitrarily:
If optional<T&>::operator=3D assigns the value like references do, then
the consistent behavior IMO is that operator=3D=3D compares values just as
well. That is, deep assignment and deep comparisons.
OTOH, if optional<T&>::operator=3D rebinds the reference, then the
consistent behavior IMO is that operator=3D=3D compares pointers (i.e.
compares identity not value)
Like Daniel said, what is important is what optional<T&> is. IMO,
*given* its rebinding semantics, it is (currently proposed as) like
reference_wrapper, which is a pointer with a convenient value access
through a T& type. As such, it has shallow assignment and shallow
comparison (and then necessarily shallow hashing)
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 18 Dec 2012 22:55:01 -0300
Raw View
On Tue, Dec 18, 2012 at 10:34 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Tue, Dec 18, 2012 at 5:21 PM, Daniel Kr=FCgler
>> optional<T&> behaves "value-like" in regard to =3D=3D, hash,
>> and comparison
>> functions.
>>
> I'll borrow this for the next response.
(Actually I better respond here.)
Indeed, if it is "value-like", it better has deep =3D=3D
But then it would be inconsistent to have shallow assignment,
Since I propose shallow (i.e. rebinding) assignment, I propose shallow
=3D=3D as well, for consistency.
Of course, you could say that why should it have rebinding semantics,
and here we would go again...
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 18 Dec 2012 20:11:12 -0600
Raw View
On Tue, Dec 18, 2012 at 7:50 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> OTOH, if optional<T&>::operator= rebinds the reference, then the
> consistent behavior IMO is that operator== compares pointers (i.e.
> compares identity not value)
Maybe I missed some discussions, but in the rev.3 of the proposal,
optional<T&> assignment is disallowed. And if we have to choose
one, I don't recommend rebinding.
http://kojot.sggw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 19 Dec 2012 07:33:58 +0100
Raw View
2012/12/19 Fernando Cacciola <fernando.cacciola@gmail.com>:
> On Tue, Dec 18, 2012 at 5:21 PM, Daniel Kr=C3=BCgler
> <daniel.kruegler@gmail.com> wrote:
>> 2012/12/18 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>>>
>>> Let me summarize my understanding of the problem so far:
>>>
>>> A. In the currently proposed optional references operator=3D=3D perform=
s a deep
>>> comparison (it also compares the referred-to value).
>>>
>>> B. If optional references are hash-able, operator=3D=3D and the default=
hash
>>> shall be consistnt with one another. This can be expressed as: if a =3D=
=3D b,
>>> then hash(a) =3D=3D hash(b).
>>>
>>> C. If we apply "deep hashing" (option 2 from my above list), it is easy=
to
>>> corrupt the associative container of optional references, because the (=
deep)
>>> state of contained object can be easily altered from outside the contai=
ner
>>> (as explained by Nevin above).
>>>
>>> Now, if we want to avoid problem in "C", we have to apply shallow (raw
>>> pointer) hashing (option 1 from my list). But that violates point "B". =
The
>>> only way to fix it (that I can see) is to change "A" and provide shallo=
w
>>> equality comparison for optional references. This makes optional refere=
nces
>>> work even more like raw pointers, and less like C++ native references. =
We
>>> still have a reasonable picture of optional references: they are like r=
aw
>>> pointers, except that you initialize them without addressof().
>>>
>>> So to summarize, I propose shallow hash and shallow comparison for opti=
onal
>>> refs.
>>> What do you think?
>>
>> I'm not convinced that reasoning C is a complete show-stopper for deep
>> value semantics
>> of optional<T&>. You can a lot of useless or "dangerous" things, if
>> you are careless,
>> the question is whether one really gets hurt by that.
>>
>> Let me remind that the following is already possible:
>>
>> #include <set>
>> #include <functional>
>> #include <iostream>
>>
>> int main()
>> {
>> std::set<std::reference_wrapper<int>> s;
>
>
> I couldn't find the definition of hash for reference_wrapper.
> Where is it? and how is it defined?
It doesn't exist (nor for pair and tuple, but it is quite probable that the=
y
will be added for the latter two). The discussion in this thread had IMO
unnecessarily focused on hashing, but my counter examples were intended
to move the focus away, because the focus had the effect that two different
argument chains had been mixed up. The original question in regard to
pointer-like versus value-like hash is already relevant for any of the
comparison functions. The arguments presented that value-like hash would
produce fragile unordered_containers is not restricted to hash nor to
unordered containers. The example I provided simply demonstrate the
same potential fragility for existing C++03 containers. I also tried to
point out that this fact alone has never been presented as a fundamental
problem with reference_wrapper, tuple<T&>, pair<T1&, T2&>, etc....
> Not could I found its operator =3D=3D or a specialization of less<>.
The operator =3D=3D is not needed. You can write the expression x =3D=3D y =
with
reference_wrapper<T> objects x and y, because it has a conversion function =
to
T&. If you instantiate less<reference_wrapper<T>>, it *just works* for the =
same
reason, there is no extra specialization needed nor specified.
- Daniel
--=20
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 19 Dec 2012 01:47:33 -0800 (PST)
Raw View
------=_Part_306_22896609.1355910453950
Content-Type: text/plain; charset=ISO-8859-1
>
> > I couldn't find the definition of hash for reference_wrapper.
> > Where is it? and how is it defined?
>
> It doesn't exist (nor for pair and tuple, but it is quite probable that
> they
> will be added for the latter two). The discussion in this thread had IMO
> unnecessarily focused on hashing, but my counter examples were intended
> to move the focus away, because the focus had the effect that two
> different
> argument chains had been mixed up. The original question in regard to
> pointer-like versus value-like hash is already relevant for any of the
> comparison functions. The arguments presented that value-like hash would
> produce fragile unordered_containers is not restricted to hash nor to
> unordered containers. The example I provided simply demonstrate the
> same potential fragility for existing C++03 containers. I also tried to
> point out that this fact alone has never been presented as a fundamental
> problem with reference_wrapper, tuple<T&>, pair<T1&, T2&>, etc....
>
Again, let me summarize everything I learned here, recap some things from
previous discussions, and add my 2 cents. Back to this list of
"constraints":
A. In the currently proposed optional references operator== performs a deep
> comparison (it also compares the referred-to value).
>
> B. If optional references are hash-able, operator== and the default hash
> shall be consistent with one another. This can be expressed as: if a == b,
> then hash(a) == hash(b).
>
> C. If we apply "deep hashing" (option 2 from my above list), it is easy to
> corrupt the associative container of optional references, because the
> (deep) state of contained object can be easily altered from outside the
> container (as explained by Nevin above).
>
I understand that we have two plausible options to satisfy B: either accept
the problem in "C" or modify "A".
The analogy with tuple of references will not work for optional references
because the latter need to address the problem that the former never had:
deal with the null-state (the disengaged state). For instance, we could
expect of optional references that assigning nullopt and then assigning
some other optional reference 'or' will work the same way as assigning
'or' directly in one go. This question is irrelevant for tuples of
references.
We need to provide a meaningful "picture" of what optional references are.
If we apply solution "shallow copy, shallow comparison, shallow hash"
(shallow everything), we get a clear answer: they are pointers (with
slightly different interface. More: they are an attractive alternative to
pointers, because they make it clear that they never own the referred-to
object. More: we are able to clearly define what the *value* (or a salient
attribute) of an optional reference is: a pointer: an address of the
referred to object for engaged optional and nullptr for the disengaged.
Given that, I believe that we are able to explain and teach optional
references easier than reference_wrappers. The later do not have a well
defined value (copy is shallow, comparison is deep).
Another acceptable solution is to apply reference_wrapper's semantics to
optional references. My personal opinion, though, is that it is a worse
solution because reference_wrapper has a weaker "conceptual model".
Just to clarify, in N3406<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html>there is no assignment for optional references. However, we obtained the
feedback from the Committee that we should put it back. In the next
revision it will be there. This adds a bunch of new issues to be resolved.
This discussion is to help us come up with a reasonable 'conceptual model'
for optional references. We realize we will not satisfy all the
users/requirements. we are only aiming at reasonable compromise.
Regards,
&rzej
--
------=_Part_306_22896609.1355910453950
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">> I couldn't find the defin=
ition of hash for reference_wrapper.
<br>> Where is it? and how is it defined?
<br>
<br>It doesn't exist (nor for pair and tuple, but it is quite probable that=
they
<br>will be added for the latter two). The discussion in this thread had IM=
O
<br>unnecessarily focused on hashing, but my counter examples were intended
<br>to move the focus away, because the focus had the effect that two diffe=
rent
<br>argument chains had been mixed up. The original question in regard to
<br>pointer-like versus value-like hash is already relevant for any of the
<br>comparison functions. The arguments presented that value-like hash woul=
d
<br>produce fragile unordered_containers is not restricted to hash nor to
<br>unordered containers. The example I provided simply demonstrate the
<br>same potential fragility for existing C++03 containers. I also tried to
<br>point out that this fact alone has never been presented as a fundamenta=
l
<br>problem with reference_wrapper, tuple<T&>, pair<T1&, T=
2&>, etc....
<br></blockquote><div><br>Again, let me summarize everything I learned here=
, recap some things from previous discussions, and add my 2 cents. Back to =
this list of "constraints":<br><br><blockquote style=3D"margin: 0px 0px 0px=
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" clas=
s=3D"gmail_quote">A. In the currently proposed optional references operator=
=3D=3D performs a deep comparison (it also compares the referred-to value).=
<br><br>B.
If optional references are hash-able, operator=3D=3D and the default hash=
=20
shall be consistent with one another. This can be expressed as: if a =3D=3D=
=20
b, then hash(a) =3D=3D hash(b).<br><br>C. If we apply "deep hashing" (optio=
n
2 from my above list), it is easy to corrupt the associative container=20
of optional references, because the (deep) state of contained object can
be easily altered from outside the container (as explained by Nevin=20
above).<br></blockquote><br>I understand that we have two plausible options=
to satisfy B: either accept the problem in "C" or modify "A".<br><br>The a=
nalogy with tuple of references will not work for optional references becau=
se the latter need to address the problem that the former never had: deal w=
ith the null-state (the disengaged state). For instance, we could expect of=
optional references that assigning nullopt and then assigning some other o=
ptional reference 'or' will work the same way as assigning 'or' direc=
tly in one go. This question is irrelevant for tuples of references.<br><br=
>We need to provide a meaningful "picture" of what optional references are.=
If we apply solution "shallow copy, shallow comparison, shallow hash" (sha=
llow everything), we get a clear answer: they are pointers (with slightly d=
ifferent interface. More: they are an attractive alternative to pointers, b=
ecause they make it clear that they never own the referred-to object. More:=
we are able to clearly define what the *value* (or a salient attribu=
te) of an optional reference is: a pointer: an address of the referred to o=
bject for engaged optional and nullptr for the disengaged. Given that, I be=
lieve that we are able to explain and teach optional references easier than=
reference_wrappers. The later do not have a well defined value (copy is sh=
allow, comparison is deep).<br><br>Another acceptable solution is to apply =
reference_wrapper's semantics to optional references. My personal opinion, =
though, is that it is a worse solution because reference_wrapper has a weak=
er "conceptual model".<br><br>Just to clarify, in<a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html"> N3406</a> there is no=
assignment for optional references. However, we obtained the feedback from=
the Committee that we should put it back. In the next revision it will be =
there. This adds a bunch of new issues to be resolved. This discussion is t=
o help us come up with a reasonable 'conceptual model' for optional referen=
ces. We realize we will not satisfy all the users/requirements. we are only=
aiming at reasonable compromise.<br><br>Regards,<br>&rzej<br> <br=
><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_306_22896609.1355910453950--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Wed, 19 Dec 2012 09:49:07 -0300
Raw View
On Wed, Dec 19, 2012 at 3:33 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
>>
>> I couldn't find the definition of hash for reference_wrapper.
>> Where is it? and how is it defined?
>
> It doesn't exist (nor for pair and tuple, but it is quite probable that t=
hey
> will be added for the latter two). The discussion in this thread had IMO
> unnecessarily focused on hashing, but my counter examples were intended
> to move the focus away, because the focus had the effect that two differe=
nt
> argument chains had been mixed up. The original question in regard to
> pointer-like versus value-like hash is already relevant for any of the
> comparison functions. The arguments presented that value-like hash would
> produce fragile unordered_containers is not restricted to hash nor to
> unordered containers. The example I provided simply demonstrate the
> same potential fragility for existing C++03 containers. I also tried to
> point out that this fact alone has never been presented as a fundamental
> problem with reference_wrapper, tuple<T&>, pair<T1&, T2&>, etc....
>
agree with you that aliasing side effects are a general, hopefully
well known, issue, so it should not be an argument against deep
hashing.
>> Not could I found its operator =3D=3D or a specialization of less<>.
>
> The operator =3D=3D is not needed. You can write the expression x =3D=3D =
y with
> reference_wrapper<T> objects x and y, because it has a conversion functio=
n to
> T&. If you instantiate less<reference_wrapper<T>>, it *just works* for th=
e same
> reason, there is no extra specialization needed nor specified.
>
OK
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 19 Dec 2012 12:59:07 -0500
Raw View
On Tue, Dec 18, 2012 at 3:46 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu poniedzia=B3ek, 17 grudnia 2012 22:35:48 UTC+1 u=BFytkownik Chris
> Jefferson napisa=B3:
>>
>> On 17/12/12 20:14, Andrzej Krzemie=F1ski wrote:
>>
>> Hi Everybody,
>> Following the suggestion by Joe Gottman, we intend to make optional<T>
>> hash-able provided that T itself is hash-able. (We will use T's hash for
>> engaged optionals, and for disengaged optional we will just pick one spe=
cial
>> value). The more difficult question is how to hash optional references.
>>
>> Should we employ similar logic as unique_ptr and hash only the value of
>> the underlying raw pointer? (Any T& can be hashed this way)
>> Should we hash the referred-to value? (and enable hashing only for
>> hash-able Ts)
>> Prevent hashing of optional references?
>>
>> Given that optional references (with now re-enabled rebinding semantics)
>> already look similar to pointers, the first choice appears the most natu=
ral.
>> I wonder what others in this group think?
>>
>>
>> There is a much bigger issue of hashing many standard types, including a=
ll
>> the standard containers. The basic definition of a valid hash function i=
s:
>>
>> if a =3D=3D b, then hash(a) =3D=3D hash(b).
>>
>> This obviously requires a valid hash function for the optional value, an=
d
>> just requiring the hash function is valid would be (in my opinion)
>> sufficient.
>
>
> Thanks for the insightful answer. Now I realize what the nature of the
> problem is. Namely, it is not clear for optional<T&> what its value (or "=
the
> set of salient attributes") is. Is it only the pointer, or also the
> referred-to value. I realize this is reopening of the previous debate, bu=
t I
> believe it is important: current behavior (hashing aside) is inconsistent=
:
> the assignment is shallow, but equality-comparison is deep.
>
> On the other hand, C++ references themselves display this inconsistency:
> their copy construction is shallow, but their comparison is deep. So, the
> behavior might be right, although chosen unconsciously. I do not know whe=
re
> the hashing function falls though. Perhaps the equality comparison should=
be
> changed.
>
> Regards,
> &rzej
>
> --
>
At Portland I suggested a table of some sort describing when optional
acts like an object, and when it acts like a pointer. Although some
thought it was obvious. I'll just remake the suggestion - I think it
would be helpful. Seeing it in a table might point out some glaring
inconsistencies might be otherwise hard to see.
Tony
--=20
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 19 Dec 2012 11:46:21 -0800 (PST)
Raw View
------=_Part_745_21911843.1355946381382
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 19 grudnia 2012 18:59:07 UTC+1 u=BFytkownik Tony V E napisa=
=B3:
>
>
> At Portland I suggested a table of some sort describing when optional=20
> acts like an object, and when it acts like a pointer. Although some=20
> thought it was obvious. I'll just remake the suggestion - I think it=20
> would be helpful. Seeing it in a table might point out some glaring=20
> inconsistencies might be otherwise hard to see.=20
>
I would be glad to add anything that would make optional easier to=20
understand. I am just not sure what you expect exactly of this table. Is=20
the following what you suggest?
for optional<T>:
operation | object-like | pointer-like
------------+----------------+-------------
copy-ctor | yes |=20
------------+----------------+-------------
copy-assign | yes |
------------+----------------+-------------
comparison | yes |
------------+----------------+-------------
hash | yes |
for optional<T&> (still under debate):
operation | object-like | pointer-like
------------+----------------+-------------
copy-ctor | | yes
------------+----------------+-------------
copy-assign | | yes
------------+----------------+-------------
comparison | | yes
------------+----------------+-------------
hash | | yes
--=20
------=_Part_745_21911843.1355946381382
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =B6roda, 19 grudnia 2012 18:59:07 UTC+1 u=BFytkownik Tony V =
E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>At Portland I =
suggested a table of some sort describing when optional
<br>acts like an object, and when it acts like a pointer. Although so=
me
<br>thought it was obvious. I'll just remake the suggestion - I think=
it
<br>would be helpful. Seeing it in a table might point out some glari=
ng
<br>inconsistencies might be otherwise hard to see.
<br></blockquote><div><br>I would be glad to add anything that would make o=
ptional easier to understand. I am just not sure what you expect exactly of=
this table. Is the following what you suggest?<br><br>for optional<T>=
;:<br><br><span style=3D"font-family: courier new,monospace;">operation&nbs=
p; | object-like | pointer-like<br>------------+--------=
--------+-------------<br>copy-ctor | yes &nbs=
p; | <br>------------+-----------=
-----+-------------<br>copy-assign | yes &nb=
sp; |<br>------------+----------------+-------------<br>c=
omparison | yes =
|</span><br><span style=3D"font-family: courier new,monospace;=
"><span style=3D"font-family: courier new,monospace;">------------+--------=
--------+-------------<br>hash | =
yes |</sp=
an><br><br><br><span style=3D"font-family: arial,sans-serif;">for optional&=
lt;T&> (still under debate):</span><br></span><br><span style=3D"fon=
t-family: courier new,monospace;">operation | object-like=
| pointer-like<br>------------+----------------+-------------<br>co=
py-ctor | &nb=
sp; | yes<br>------------+----------------+-------------<=
br>copy-assign | &n=
bsp; | yes<br>------------+----------------+-------------<br>co=
mparison | &nbs=
p; | yes<br><span style=3D"font-family: courier new=
,monospace;">------------+----------------+-------------<br>hash  =
; | &nb=
sp; | yes<br></span></span></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_745_21911843.1355946381382--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Wed, 19 Dec 2012 17:08:02 -0300
Raw View
On Wed, Dec 19, 2012 at 5:46 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu =B6roda, 19 grudnia 2012 18:59:07 UTC+1 u=BFytkownik Tony V E napi=
sa=B3:
>>
>>
>> At Portland I suggested a table of some sort describing when optional
>> acts like an object, and when it acts like a pointer. Although some
>> thought it was obvious. I'll just remake the suggestion - I think it
>> would be helpful. Seeing it in a table might point out some glaring
>> inconsistencies might be otherwise hard to see.
>
>
> I would be glad to add anything that would make optional easier to
> understand. I am just not sure what you expect exactly of this table. Is =
the
> following what you suggest?
>
> for optional<T>:
>
> operation | object-like | pointer-like
> ------------+----------------+-------------
> copy-ctor | yes |
> ------------+----------------+-------------
> copy-assign | yes |
> ------------+----------------+-------------
> comparison | yes |
> ------------+----------------+-------------
> hash | yes |
>
>
> for optional<T&> (still under debate):
>
> operation | object-like | pointer-like
> ------------+----------------+-------------
> copy-ctor | | yes
> ------------+----------------+-------------
> copy-assign | | yes
> ------------+----------------+-------------
> comparison | | yes
> ------------+----------------+-------------
> hash | | yes
>
> --
>
>
I think he expected the rest of the operations to also appear in the table(=
s)
In particular, operator * would be pointer-like, for example
Andrzej, could you update the table accordingly?
TIA
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 20 Dec 2012 09:22:52 -0800 (PST)
Raw View
------=_Part_379_16016697.1356024172096
Content-Type: text/plain; charset=ISO-8859-1
> I think he expected the rest of the operations to also appear in the
> table(s)
> In particular, operator * would be pointer-like, for example
>
> Andrzej, could you update the table accordingly?
>
Would the following table do?
expr | axiom | pre | post | ret | ret| rem
| | | | type | val|
--------+--------------+---------+---------------------+------+----+-------
OT{} | OT{nullopt} | | | | |
disengaged
OT{v} | | | | | |
engaged, stores v
OT{o} | | | | | | same
engagement/val
o = o2 | | | o == o2 | OT& | o |
| | | bool(o) == bool(o2) | OT& | o |
| | | if(o) *o == *o2 | OT& | o |
o = v | | | bool(o) == true | OT& | o |
| | | *o == v | OT& | o |
bool(o) | o != nullopt | | | bool | |
engaged?
*o | | bool(o) | | T& | |
contained val
o->m | (*o).m | bool(o) | | | |
o == o2 | | | | | | deep
where:
o, o2 -- lvalues of type optional<T>
OT -- type of optional<T>
v -- lvalue of type T
--
------=_Part_379_16016697.1356024172096
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;">I think he expected the re=
st of the operations to also appear in the table(s)
<br>In particular, operator * would be pointer-like, for example
<br>
<br>Andrzej, could you update the table accordingly?
<br></blockquote><div><br>Would the following table do?<br><br><span style=
=3D"font-family: courier new,monospace;">expr | axiom&nbs=
p; | pre | post=
&nb=
sp; | ret | ret| rem<br> &nb=
sp; | &nbs=
p; | | &nb=
sp; =
| type | val|<br>--------+------------=
--+---------+---------------------+------+----+-------<br>OT{} &=
nbsp; | OT{nullopt} | =
| &=
nbsp; | &n=
bsp; | | disengaged<br>OT{v} | &nb=
sp; | &nbs=
p; |  =
; &n=
bsp; | | | engaged, s=
tores v<br>OT{o} | &nb=
sp; | &nbs=
p; |  =
; | =
| | same engagement/val<br>o =3D o2 |&=
nbsp; &nbs=
p; | | o =3D=3D o2 &nb=
sp; | OT&&n=
bsp; | o |<br> |  =
; | =
| bool(o) =3D=3D bool(o2) | OT&a=
mp; | o |<br> | =
|&=
nbsp; | if(o) *o =3D=3D *o2 =
| OT& | o |<br>o =3D v |&nbs=
p; =
| | bool(o) =3D=3D true&nbs=
p; | OT& | o |<br>  =
; | =
| =
| *o =3D=3D v &n=
bsp; | OT& | o |<br>bool(o) | o !=3D nullopt | &=
nbsp; | &n=
bsp;  =
; | bool | | engaged?<br>*o =
| &=
nbsp; | bool(o) | &nbs=
p; =
| T& | | contained val<br>o->m &n=
bsp; | (*o).m | bool(o) | &n=
bsp;  =
; | |&nbs=
p; |<br>o =3D=3D o2 | =
| &=
nbsp; | &n=
bsp; | &nb=
sp; | | deep </span><br><br>where:<br><br>o, =
o2 -- lvalues of type optional<T><br>OT -- type of optional<T><=
br>v -- lvalue of type T<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_379_16016697.1356024172096--
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Thu, 20 Dec 2012 10:56:46 -0800
Raw View
--e89a8ff1c60a3531a304d14d4c16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Dec 20, 2012 at 9:22 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:
>
>> I think he expected the rest of the operations to also appear in the
>> table(s)
>> In particular, operator * would be pointer-like, for example
>>
>> Andrzej, could you update the table accordingly?
>
>
> Would the following table do?
Perhaps:
pointer / | expr | axiom | pre | post | ret |
ret| rem
object | | | | | type |
val|
----------+---------+--------------+---------+---------------------+----
--+----+-------
pointer | OT{} | OT{nullopt} | | |
| | disengaged
object | OT{v} | | | |
| | engaged, stores v
object | OT{o} | | | |
| | same engagement/val
object | o =3D o2 | | | o =3D=3D o2 | =
OT& |
o |
| | | | bool(o) =3D=3D bool(o2) | OT=
& |
o |
| | | | if(o) *o =3D=3D *o2 | OT=
& |
o |
object | o =3D v | | | bool(o) =3D=3D true | =
OT& |
o |
| | | | *o =3D=3D v | OT=
& |
o |
pointer | bool(o) | o !=3D nullopt | | | bool
| | engaged?
pointer | *o | | bool(o) | | T&
| | contained val
pointer | o->m | (*o).m | bool(o) | |
| |
object | o =3D=3D o2 | | | |
| | deep
object | hash(o) | o=3D=3Do2 =3D=3D> | | =
|
| | deep
| | hash(o)=3D=3Dhash(o2) | | =
|
|
(Personally, I think we should drop optional<T&> and adopt the rest of
optional<T>. The only argument for optional<T&> over just using T* is that
generic code might benefit (addressof and "maybe this raw pointer is owned"
aren't sufficient IMO), but optional<T&> is non-uniform in enough ways that
I'd expect template authors to have to consider references specially anyway
(otherwise, it might happen to work, but it might also happen to be a bug).
We could always add the specialization later if people wind up needing it,
and the requests that lead us to adopt it later would drive the interface.
Still, I'd rather adopt both than lose both.)
> where:
>
> o, o2 -- lvalues of type optional<T>
> OT -- type of optional<T>
> v -- lvalue of type T
>
> --
>
>
>
--=20
--e89a8ff1c60a3531a304d14d4c16
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z
aXplOjEwcHQiPjxkaXYgZGlyPSJsdHIiPk9uIFRodSwgRGVjIDIwLCAyMDEyIGF0IDk6MjIgQU0s
IEFuZHJ6ZWogS3J6ZW1pZcWEc2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWtyemVtaTFAZ21haWwu
Y29tIj5ha3J6ZW1pMUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4KJmd0OyZn
dDsgSSB0aGluayBoZSBleHBlY3RlZCB0aGUgcmVzdCBvZiB0aGUgb3BlcmF0aW9ucyB0byBhbHNv
IGFwcGVhciBpbiB0aGU8YnI+Jmd0OyZndDsgdGFibGUocyk8YnI+Jmd0OyZndDsgSW4gcGFydGlj
dWxhciwgb3BlcmF0b3IgKiB3b3VsZCBiZSBwb2ludGVyLWxpa2UsIGZvciBleGFtcGxlPGJyPiZn
dDsmZ3Q7PGJyPiZndDsmZ3Q7IEFuZHJ6ZWosIGNvdWxkIHlvdSB1cGRhdGUgdGhlIHRhYmxlIGFj
Y29yZGluZ2x5Pzxicj4KCiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IFdvdWxkIHRoZSBmb2xsb3dpbmcg
dGFibGUgZG8/PGJyPjxicj5QZXJoYXBzOjxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiYjMzk7Y291cmllciBuZXcmIzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPnBvaW50ZXIg
LyB8IGV4cHLCoMKgwqAgfCBheGlvbcKgwqDCoMKgwqDCoMKgIHwgcHJlwqDCoMKgwqAgfCBwb3N0
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgcmV0wqAgfCByZXR8IHJlbTwvc3Bhbj48
YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxtb25vc3BhY2U7Zm9u
dC1zaXplOjEzcHgiPgoKPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcm
IzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPm9iamVjdCDCoCDCoHwgwqAgwqAgwqAgwqAg
fMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgdHlwZSB8IHZhbHw8L3NwYW4+PGJyIHN0
eWxlPSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2ZvbnQtc2l6
ZToxM3B4Ij4KCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTss
bW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij4tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0t
LS0tLSstLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBu
ZXcmIzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPi0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
LS0rLS0tLTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYj
Mzk7LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+LS0rLS0tLSstLS0tLS0tPC9zcGFuPjxiciBz
dHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZTtmb250LXNp
emU6MTNweCI+Cgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7
LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+cG9pbnRlciDCoCB8IE9Ue33CoMKgwqAgfCBPVHtu
dWxsb3B0fcKgIHzCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgIHzCoMKgwqAgfCBkaXNlbmdhZ2VkPC9zcGFuPjxiciBz
dHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZTtmb250LXNp
emU6MTNweCI+Cgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7
LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+b2JqZWN0IMKgIMKgfCBPVHt2fcKgwqAgfMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgIHzCoMKgwqAgfCBlbmdhZ2VkLCBz
dG9yZXMgdjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5
Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPgoKPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYj
Mzk7Y291cmllciBuZXcmIzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPm9iamVjdCDCoCDC
oHzCoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7
LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+T1R7b33CoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCB8wqDCoMKgwqDCoCB8wqDCoMKgIHwgc2FtZSBlbmdhZ2VtZW50L3ZhbDwvc3Bh
bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxtb25vc3BhY2U7
Zm9udC1zaXplOjEzcHgiPgoKPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBu
ZXcmIzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPm9iamVjdCDCoCDCoHzCoDwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZTtm
b250LXNpemU6MTNweCI+byA9IG8ywqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKg
wqDCoMKgwqDCoMKgIHwgbyA9PSBvMsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IE9UJmFtcDvC
oCB8IG/CoCB8PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYj
Mzk7LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+Cgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+wqAgwqAgwqAg
wqAgwqAgfMKgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3
JiMzOTssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij7CoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqAgfCBib29sKG8pID09IGJvb2wobzIp
IHwgT1QmYW1wO8KgIHwgb8KgIHw8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2Nv
dXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij4KCjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4
Ij7CoCDCoCDCoCDCoCDCoCB8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2Nv
dXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij7CoCDCoCDCoCDCoCDCoHzC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoCB8IGlmKG8pICpvID09
ICpvMsKgwqDCoMKgIHwgT1QmYW1wO8KgIHwgb8KgIHw8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZh
bWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij4KCjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2Zv
bnQtc2l6ZToxM3B4Ij5vYmplY3QgwqAgwqB8wqA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPm8gPSB2
wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqAgfCBib29s
KG8pID09IHRydWXCoMKgwqDCoCB8IE9UJmFtcDvCoCB8IG/CoCB8PC9zcGFuPjxiciBzdHlsZT0i
Zm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZTtmb250LXNpemU6MTNw
eCI+Cgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9z
cGFjZTtmb250LXNpemU6MTNweCI+wqAgwqAgwqAgwqAgwqAgfDwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZTtmb250LXNpemU6MTNw
eCI+wqAgwqAgwqAgwqAgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDC
oMKgwqAgfCAqbyA9PSB2wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgT1QmYW1wO8KgIHwgb8Kg
IHw8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9u
b3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij4KCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2Nv
dXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij5wb2ludGVyIMKgIHzCoDwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9z
cGFjZTtmb250LXNpemU6MTNweCI+Ym9vbChvKSB8IG8gIT0gbnVsbG9wdCB8wqDCoMKgwqDCoMKg
wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IGJvb2wgfMKg
wqDCoCB8IGVuZ2FnZWQ/PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVy
IG5ldyYjMzk7LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+Cgo8c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZTtmb250LXNpemU6MTNweCI+cG9p
bnRlciDCoCB8wqA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBu
ZXcmIzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPipvwqDCoMKgwqDCoCB8wqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgfCBib29sKG8pIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHwgVCZhbXA7wqDCoCB8wqDCoMKgIHwgY29udGFpbmVkIHZhbDwvc3Bhbj48
YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxtb25vc3BhY2U7Zm9u
dC1zaXplOjEzcHgiPgoKPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcm
IzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPnBvaW50ZXIgwqAgfMKgPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlO2ZvbnQt
c2l6ZToxM3B4Ij5vLSZndDttwqDCoMKgIHwgKCpvKS5twqDCoMKgwqDCoMKgIHwgYm9vbChvKSB8
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoCB8wqDC
oMKgIHw8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTss
bW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4Ij4KCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTNweDtm
b250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlIj5vYmplY3QgwqAgwqB8
wqA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OiYjMzk7Y291
cmllciBuZXcmIzM5Oyxtb25vc3BhY2UiPm8gPT0gbzIgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHzCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIHzCoMKgwqDCoMKgIHzCoMKgwqAgfCBkZWVwwqA8L3NwYW4+PGJyPgoKPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxtb25v
c3BhY2UiPm9iamVjdCDCoCDCoHwgaGFzaCg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
M3B4O2ZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxtb25vc3BhY2UiPm8pIHwgbz09
bzIgPT0mZ3Q7IMKgIMKgfMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqAgfMKgwqDCoCB8IGRlZXDCoDwvc3Bhbj48ZGl2
PgoKPGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+wqAgwqAgwqAgwqAgwqAgfCDC
oCDCoCDCoCDCoCB8wqA8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmll
ciBuZXcmIzM5Oyxtb25vc3BhY2U7Zm9udC1zaXplOjEzcHgiPmhhc2gobyk9PWhhc2gobzIpIMKg
IMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgfCDCoCDCoHw8
L3NwYW4+PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+PGJyPgoKPC9mb250Pjxi
cj48YnI+KFBlcnNvbmFsbHksIEkgdGhpbmsgd2Ugc2hvdWxkIGRyb3Agb3B0aW9uYWwmbHQ7VCZh
bXA7Jmd0OyBhbmQgYWRvcHQgdGhlIHJlc3Qgb2Ygb3B0aW9uYWwmbHQ7VCZndDsuIFRoZSBvbmx5
IGFyZ3VtZW50IGZvciBvcHRpb25hbCZsdDtUJmFtcDsmZ3Q7IG92ZXIganVzdCB1c2luZyBUKiBp
cyB0aGF0IGdlbmVyaWMgY29kZSBtaWdodCBiZW5lZml0IChhZGRyZXNzb2YgYW5kICZxdW90O21h
eWJlIHRoaXMgcmF3IHBvaW50ZXIgaXMgb3duZWQmcXVvdDsgYXJlbiYjMzk7dCBzdWZmaWNpZW50
IElNTyksIGJ1dCBvcHRpb25hbCZsdDtUJmFtcDsmZ3Q7IGlzIG5vbi11bmlmb3JtIGluIGVub3Vn
aCB3YXlzIHRoYXQgSSYjMzk7ZCBleHBlY3QgdGVtcGxhdGUgYXV0aG9ycyB0byBoYXZlIHRvIGNv
bnNpZGVyIHJlZmVyZW5jZXMgc3BlY2lhbGx5IGFueXdheSAob3RoZXJ3aXNlLCBpdCBtaWdodCBo
YXBwZW4gdG8gd29yaywgYnV0IGl0IG1pZ2h0IGFsc28gaGFwcGVuIHRvIGJlIGEgYnVnKS4gV2Ug
Y291bGQgYWx3YXlzIGFkZCB0aGUgc3BlY2lhbGl6YXRpb24gbGF0ZXIgaWYgcGVvcGxlIHdpbmQg
dXAgbmVlZGluZyBpdCwgYW5kIHRoZSByZXF1ZXN0cyB0aGF0IGxlYWQgdXMgdG8gYWRvcHQgaXQg
bGF0ZXIgd291bGQgZHJpdmUgdGhlIGludGVyZmFjZS48L2Rpdj4KCjxkaXY+PGJyPjwvZGl2Pjxk
aXY+U3RpbGwsIEkmIzM5O2QgcmF0aGVyIGFkb3B0IGJvdGggdGhhbiBsb3NlIGJvdGguKTxicj48
YnI+PGRpdj4mZ3Q7IHdoZXJlOjxicj4mZ3Q7PGJyPiZndDsgbywgbzIgLS0gbHZhbHVlcyBvZiB0
eXBlIG9wdGlvbmFsJmx0O1QmZ3Q7PGJyPiZndDsgT1QgLS0gdHlwZSBvZiBvcHRpb25hbCZsdDtU
Jmd0Ozxicj4mZ3Q7IHYgLS0gbHZhbHVlIG9mIHR5cGUgVDxicj4KCiZndDs8YnI+Jmd0OyAtLTxi
cj4mZ3Q7IMKgPGJyPiZndDsgwqA8YnI+Jmd0OyDCoDxicj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+
PC9kaXY+Cg0KPHA+PC9wPg0KDQotLSA8YnIgLz4NCiZuYnNwOzxiciAvPg0KJm5ic3A7PGJyIC8+
DQombmJzcDs8YnIgLz4NCg==
--e89a8ff1c60a3531a304d14d4c16--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 20 Dec 2012 16:36:28 -0300
Raw View
On Thu, Dec 20, 2012 at 4:56 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>
> Perhaps:
>
Looks great!
Though I don't think the first row should be considered as pointer-like.
Specially given that we introduced nullopt instead of just using
nullptr precisely to avoid that.
>
> (Personally, I think we should drop optional<T&> and adopt the rest of
> optional<T>. The only argument for optional<T&> over just using T* is that
> generic code might benefit (addressof and "maybe this raw pointer is owned"
> aren't sufficient IMO), but optional<T&> is non-uniform in enough ways that
> I'd expect template authors to have to consider references specially anyway
> (otherwise, it might happen to work, but it might also happen to be a bug).
> We could always add the specialization later if people wind up needing it,
> and the requests that lead us to adopt it later would drive the interface.
>
> Still, I'd rather adopt both than lose both.)
>
I must have said this a hundred times already but:
(1) First off, I believe C++ is a fantastic language and I never
minded it being complex and having some subtle rules. It's balance of
control over runtime performance and source code beauty is
unparalleled, and is the reason why I choose to use C++ whenever I
can. Thus, I will always prefer to have a feature even if it has to be
well understood over not have it. I if wanted to safely program
without having to think too much about what I'm doing I'd use
something else (and I did that several times)
(2) IMO the only issue with optional<T&> and it's two possible
semantics are expectations. There is nothing inherently wrong or even
inconsistent *on itself* about it (for any of the two choices of
semantics). Is just that we humans think by analogy and drawing one
here is difficult, as if optional<T&> were a Platypus. If one insists
on viewing it as either a duck or a beaver, there is a problem. But
IMO the problem is in *doing that* as opposed to in optional<T&>
itself. Personally, I never understood why it has to be "pointer-like"
OR "value-like", and can't just be one for some operations and the
other for the rest.
(3) Going back to (1), I fail even more to see why it's so important
that optional<T&> be like this or like that, but never both, in the
context of C++, because from all languages, C++ is itself hybrid, and
by design. What is important to me is to have a feature that serves a
general purpose, is well defined and works consistently *with respect
to itself*
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 21 Dec 2012 00:36:30 -0800 (PST)
Raw View
------=_Part_71_9496540.1356078990787
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 20 grudnia 2012 19:56:46 UTC+1 u=BFytkownik Jeffrey Yasski=
n=20
napisa=B3:
>
> On Thu, Dec 20, 2012 at 9:22 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:
> >
> >> I think he expected the rest of the operations to also appear in the
> >> table(s)
> >> In particular, operator * would be pointer-like, for example
> >>
> >> Andrzej, could you update the table accordingly?
> >
> >
> > Would the following table do?
>
> Perhaps:
>
> pointer / | expr | axiom | pre | post | ret =
=20
> | ret| rem
> object | | | | | type=
=20
> | val|
> ----------+---------+--------------+---------+---------------------+----
> --+----+-------
> pointer | OT{} | OT{nullopt} | | | =
=20
> | | disengaged
> object | OT{v} | | | | =
=20
> | | engaged, stores v
> object | OT{o} | | | | =
=20
> | | same engagement/val
> object | o =3D o2 | | | o =3D=3D o2 =
| OT& =20
> | o |
> | | | | bool(o) =3D=3D bool(o2) | =
OT& =20
> | o |
> | | | | if(o) *o =3D=3D *o2 | =
OT& =20
> | o |
> object | o =3D v | | | bool(o) =3D=3D true =
| OT& =20
> | o |
> | | | | *o =3D=3D v | =
OT& =20
> | o |
> pointer | bool(o) | o !=3D nullopt | | | bo=
ol=20
> | | engaged?
> pointer | *o | | bool(o) | | T& =
=20
> | | contained val
> pointer | o->m | (*o).m | bool(o) | | =
=20
> | |
> object | o =3D=3D o2 | | | | =
=20
> | | deep=20
> object | hash(o) | o=3D=3Do2 =3D=3D> | | =
| =20
> | | deep=20
> | | hash(o)=3D=3Dhash(o2) | | =
=20
> | |
>
I would be reluctant to provide this column "pointer/reference" into the=20
table in the proposal. I am not sure what it is supposed to help with.=20
Does it refer to pointer's semantics or only pointer's syntax?=20
Why do you say the default constructor is "pointer"? Both pointers and=20
objects have default constructor and even for non-pointer objects default=
=20
constructor often initializes the object to a null-state.
Why are you saying hashing is "object"? Pointers can be hashed as well,=20
maintaining the same property o=3D=3Do2 =3D=3D> hash(o)=3D=3Dhash(o2). Is i=
t because of=20
this "deep"? But if so, does "deep" alone not suffice to describe the=20
semantics? Does this "object"/"pointer" add anything to the table?
Pointers are objects...
--=20
------=_Part_71_9496540.1356078990787
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 20 grudnia 2012 19:56:46 UTC+1 u=BFytkownik Jeffre=
y Yasskin napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:10pt"><div dir=3D"ltr"=
>On Thu, Dec 20, 2012 at 9:22 AM, Andrzej Krzemie=F1ski <<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"cKlG2EwFCNcJ">akrz...@g=
mail.com</a>> wrote:<br>><br>
>> I think he expected the rest of the operations to also appear in t=
he<br>>> table(s)<br>>> In particular, operator * would be poin=
ter-like, for example<br>>><br>>> Andrzej, could you update the=
table accordingly?<br>
><br>><br>> Would the following table do?<br><br>Perhaps:<br><br><=
span style=3D"font-family:'courier new',monospace;font-size:13px">pointer /=
| expr | axiom =
| pre | post &n=
bsp; | ret | ret| rem=
</span><br style=3D"font-family:'courier new',monospace;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">object &=
nbsp; | | &n=
bsp; | &nb=
sp; | &nbs=
p; | type=
| val|</span><br style=3D"font-family:'courier new',monospace;font-size:13=
px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">--------=
--+---------+---------<wbr>-----+------</span><span style=3D"font-family:'c=
ourier new',monospace;font-size:13px">---+--------------<wbr>-------+----</=
span><span style=3D"font-family:'courier new',monospace;font-size:13px">--+=
----+-------</span><br style=3D"font-family:'courier new',monospace;font-si=
ze:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">pointer =
| OT{} | OT{nullopt} | &nbs=
p; |  =
; |=
| | disengaged</span><br s=
tyle=3D"font-family:'courier new',monospace;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">object &=
nbsp; | OT{v} | =
| &=
nbsp; | &n=
bsp; | &nb=
sp; | | engaged, stores v</span><br style=3D"=
font-family:'courier new',monospace;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">object &=
nbsp; | </span><span style=3D"font-family:'courier new',monospac=
e;font-size:13px">OT{o} | &n=
bsp; | &nb=
sp; | &nbs=
p; |  =
; | | same engagement/val</span><br sty=
le=3D"font-family:'courier new',monospace;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">object &=
nbsp; | </span><span style=3D"font-family:'courier new',monospac=
e;font-size:13px">o =3D o2 |  =
; | =
| o =3D=3D o2 &=
nbsp; | OT& | o |</span><br style=3D"font=
-family:'courier new',monospace;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px"> &=
nbsp; | </span><span style=3D"font-family:'courie=
r new',monospace;font-size:13px"> =
| &=
nbsp; | | bool(o) =3D=3D bo=
ol(o2) | OT& | o |</span><br style=3D"font-family:'courier =
new',monospace;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px"> &=
nbsp; |</span><span style=3D"font-family:'courier new'=
,monospace;font-size:13px"> | &=
nbsp; | &n=
bsp; | if(o) *o =3D=3D *o2 &=
nbsp; | OT& | o |</span><br style=3D"font-family:'cou=
rier new',monospace;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">object &=
nbsp; | </span><span style=3D"font-family:'courier new',monospac=
e;font-size:13px">o =3D v | =
| &=
nbsp; | bool(o) =3D=3D true | OT&&n=
bsp; | o |</span><br style=3D"font-family:'courier new',monospace;fon=
t-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px"> &=
nbsp; |</span><span style=3D"font-family:'courier new'=
,monospace;font-size:13px"> | &=
nbsp; | &n=
bsp; | *o =3D=3D v &nb=
sp; | OT& | o&nbs=
p; |</span><br style=3D"font-family:'courier new',monospace;font-size:13px"=
>
<span style=3D"font-family:'courier new',monospace;font-size:13px">pointer =
| </span><span style=3D"font-family:'courier new',monospace;fon=
t-size:13px">bool(o) | o !=3D nullopt | =
| &=
nbsp; | bool | &=
nbsp; | engaged?</span><br style=3D"font-family:'courier new',monospa=
ce;font-size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">pointer =
| </span><span style=3D"font-family:'courier new',monospace;fon=
t-size:13px">*o | &nbs=
p; | bool(o) | &=
nbsp; &nbs=
p; | T& | |=
contained val</span><br style=3D"font-family:'courier new',monospace;font-=
size:13px">
<span style=3D"font-family:'courier new',monospace;font-size:13px">pointer =
| </span><span style=3D"font-family:'courier new',monospace;fon=
t-size:13px">o->m | (*o).m &nbs=
p; | bool(o) | &=
nbsp; | &n=
bsp; | |</span><br style=3D"font-family=
:'courier new',monospace;font-size:13px">
<span style=3D"font-size:13px;font-family:'courier new',monospace">object &=
nbsp; | </span><span style=3D"font-size:13px;font-family:'courie=
r new',monospace">o =3D=3D o2 | &n=
bsp; | &nb=
sp; | &nbs=
p; |  =
; | | deep </span><br>
<span style=3D"font-size:13px;font-family:'courier new',monospace">object &=
nbsp; | hash(</span><span style=3D"font-size:13px;font-family:'courie=
r new',monospace">o) | o=3D=3Do2 =3D=3D> |  =
; | =
&nb=
sp; | | | deep </span>=
<div>
<font face=3D"courier new, monospace"> | =
| </font><span style=3D"font-family:'couri=
er new',monospace;font-size:13px">hash(o)=3D=3Dhash(o2)  =
;| | =
| |</span><br></div></div></div></blockquo=
te><div><br>I would be reluctant to provide this column "pointer/reference"=
into the table in the proposal. I am not sure what it is supposed to help =
with. <br><br>Does it refer to pointer's semantics or only pointer's syntax=
? <br><br>Why do you say the default constructor is "pointer"? Both pointer=
s and objects have default constructor and even for non-pointer objects def=
ault constructor often initializes the object to a null-state.<br><br>Why a=
re you saying hashing is "object"? Pointers can be hashed as well, maintain=
ing the same property <span style=3D"font-family:'courier new',monospace;fo=
nt-size:13px"><span style=3D"font-size:13px;font-family:'courier new',monos=
pace">o=3D=3Do2 =3D=3D> </span>hash(o)=3D=3Dhash(o2)</span>. Is it becau=
se of this "deep"? But if so, does "deep" alone not suffice to describe the=
semantics? Does this "object"/"pointer" add anything to the table?<br><br>=
Pointers are objects...<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_71_9496540.1356078990787--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 21 Dec 2012 04:09:22 -0800 (PST)
Raw View
------=_Part_200_28221767.1356091763060
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 20 grudnia 2012 19:56:46 UTC+1 u=BFytkownik Jeffrey Yasski=
n=20
napisa=B3:
>
> (Personally, I think we should drop optional<T&> and adopt the rest of=20
> optional<T>. The only argument for optional<T&> over just using T* is tha=
t=20
> generic code might benefit (addressof and "maybe this raw pointer is owne=
d"=20
> aren't sufficient IMO), but optional<T&> is non-uniform in enough ways th=
at=20
> I'd expect template authors to have to consider references specially anyw=
ay=20
> (otherwise, it might happen to work, but it might also happen to be a bug=
).=20
> We could always add the specialization later if people wind up needing it=
,=20
> and the requests that lead us to adopt it later would drive the interface=
..
>
> Still, I'd rather adopt both than lose both.)
>
I have opened a separate thread on optional references:https://groups.googl=
e.com/a/isocpp.org/d/topic/std-proposals/rKjpmkeCSyo/discussion
=20
--=20
------=_Part_200_28221767.1356091763060
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 20 grudnia 2012 19:56:46 UTC+1 u=BFytkownik Jeffre=
y Yasskin napisa=B3:<br><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:10pt"><div dir=3D"=
ltr"><div><br>(Personally, I think we should drop optional<T&> an=
d adopt the rest of optional<T>. The only argument for optional<T&=
amp;> over just using T* is that generic code might benefit (addressof a=
nd "maybe this raw pointer is owned" aren't sufficient IMO), but optional&l=
t;T&> is non-uniform in enough ways that I'd expect template authors=
to have to consider references specially anyway (otherwise, it might happe=
n to work, but it might also happen to be a bug). We could always add the s=
pecialization later if people wind up needing it, and the requests that lea=
d us to adopt it later would drive the interface.</div>
<div><br></div><div>Still, I'd rather adopt both than lose both.)<br></div>=
</div></div></blockquote><div><br>I have opened a separate thread on option=
al references:<a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std=
-proposals/rKjpmkeCSyo/discussion"> https://groups.google.com/a/isocpp.org/=
d/topic/std-proposals/rKjpmkeCSyo/discussion</a><br> <br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_200_28221767.1356091763060--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 19 Dec 2012 12:54:32 -0500
Raw View
On Tue, Dec 18, 2012 at 3:21 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
>
> Actually "reference-like" objects are what Java and .NET languages heavil=
y use.
> People learn to handle this.
>
I think you are arguing against yourself here. The
reference-like-by-default nature of Java is the number one source of
bugs. (Why did my object change? Oh, I didn't realize it was being
shared...) At least that's been my experience in a large java
codebase.
Tony
--=20
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 20 Dec 2012 23:44:27 +0100
Raw View
> (2) IMO the only issue with optional<T&> and it's two possible
> semantics are expectations. There is nothing inherently wrong or even
> inconsistent *on itself* about it (for any of the two choices of
> semantics). Is just that we humans think by analogy and drawing one
> here is difficult, as if optional<T&> were a Platypus. If one insists
> on viewing it as either a duck or a beaver, there is a problem. But
> IMO the problem is in *doing that* as opposed to in optional<T&>
> itself. Personally, I never understood why it has to be "pointer-like"
> OR "value-like", and can't just be one for some operations and the
> other for the rest.
Agreed, however as I have used boost optional I have some expectations.
So we should have some user experience here already...
> (3) Going back to (1), I fail even more to see why it's so important
> that optional<T&> be like this or like that, but never both, in the
> context of C++, because from all languages, C++ is itself hybrid, and
> by design. What is important to me is to have a feature that serves a
> general purpose, is well defined and works consistently *with respect
> to itself*
This is true, but I don't really see why we would want pointer semantics
either, as we have pointers already.
Then again, only place where I have used boost::optional<T&> is output
parameter..
Mikael
--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sat, 22 Dec 2012 14:28:29 +0100
Raw View
2012/12/19 Tony V E <tvaneerd@gmail.com>:
> On Tue, Dec 18, 2012 at 3:21 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>>
>> Actually "reference-like" objects are what Java and .NET languages heavi=
ly use.
>> People learn to handle this.
>>
>
> I think you are arguing against yourself here.
No, I don't think so.
First, my response was intended to point out the omni-presence of
reference-like/pointer-like types in C++ (including tuples and pairs
with reference member types) as a counter argument for why this should
be very different when considering optional with reference types.
Second, the comparison with languages that are used in large
commercial code bases with inherent reference-like values points out
that you can create such programs with them.
> The reference-like-by-default nature of Java is the number one source of
> bugs. (Why did my object change? Oh, I didn't realize it was being
> shared...) At least that's been my experience in a large java
> codebase.
I'm not an extreme fan of references all the place nor do I intent to
start a heated debate of one philosophy over the other.
Please lets come back to the point that we speak of a very special
species - the partial specialization optional<T&> and not of
optional<T> in general.
Putting these arguments together I don't see a contradiction in my reasonin=
g.
- Daniel
--=20
.