My own point of view:

If optional<T> is an extended type T, then:

optional<int> x = 0;  // implicitly convertible
optional<int>(3) == 3;  // since T is a sub-range of optional<T>
optional<int>(nullopt) == optional<int>(nullopt);  // same extended value

If optional<T> is a T with two states, then:

optional<int> x(0);  // explicitly convertible
optional<int>(3) == make_optional(3);  // since T is not "T with states"
optional<int>(nullopt) != optional<int>(nullopt);  // meaningless states

Comments wanted.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 24 January 2013 15:25, Zhihao Yuan <lichray@gmail.com> wrote:
> My own point of view:
> If optional<T> is an extended type T, then:
> optional<int> x = 0;  // implicitly convertible
> optional<int>(3) == 3;  // since T is a sub-range of optional<T>
> optional<int>(nullopt) == optional<int>(nullopt);  // same extended value
> If optional<T> is a T with two states, then:
> optional<int> x(0);  // explicitly convertible
> optional<int>(3) == make_optional(3);  // since T is not "T with states"
> optional<int>(nullopt) != optional<int>(nullopt);  // meaningless states
> Comments wanted.

I initially thought implicit conversions from T to optional<T> are a bad idea.
I have since cured that problem in my head, there's no 'danger' involved in
it. boost::optional has such implicit conversions, and I see no reason
to do it differently for std::optional.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 7:38 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> I have since cured that problem in my head, there's no 'danger' involved in
> it.

The danger already shows up.

Quoting from the proposal:

  "Such implicit conversions impose some risk of introducing bugs,
   and in fact in order to avoid one such possible bug we had to 'poison'
   comparisons between optional<T> and T."

And a carefully specified comparison logic is under discussion.

> boost::optional has such implicit conversions, and I see no reason
> to do it differently for std::optional.

This is convincible to some (or many) people, but not me.
Not all Boost practices are good.  They are not good just because
they exists for several years.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 24/01/13 13:52, Zhihao Yuan wrote:
> On Thu, Jan 24, 2013 at 7:38 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> I have since cured that problem in my head, there's no 'danger' involved in
>> it.
> The danger already shows up.
>
> Quoting from the proposal:
>
>    "Such implicit conversions impose some risk of introducing bugs,
>     and in fact in order to avoid one such possible bug we had to 'poison'
>     comparisons between optional<T> and T."
>
> And a carefully specified comparison logic is under discussion.
>
>> boost::optional has such implicit conversions, and I see no reason
>> to do it differently for std::optional.
> This is convincible to some (or many) people, but not me.
> Not all Boost practices are good.  They are not good just because
> they exists for several years.

True. But looking at the boost mailing list and bug reports, there does
not appear (from what I could find, and remember) to have been any
complaints about this. We certainly shouldn't ignore implementation
experience.

I have written quite a lot of code with boost::optional, it is very
common to make an optional<T> from a T, in 'return' statements for
example. Having to add an explicit cast to all of those would annoy me.

Chris

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 8:05 AM, Chris Jefferson
<chris@bubblescope.net> wrote:> True. But looking at the boost mailing
list and bug reports, there does not
> I have written quite a lot of code with boost::optional, it is very common
> to make an optional<T> from a T, in 'return' statements for example. Having
> to add an explicit cast to all of those would annoy me.

Jeffery proposed a convert() utility to solve a problem like this:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3521.html

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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



W dniu czwartek, 24 stycznia 2013 14:52:22 UTC+1 u=BFytkownik Zhihao Yuan=
=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 7:38 AM, Ville Voutilainen=20
> <ville.vo...@gmail.com <javascript:>> wrote:=20
> > I have since cured that problem in my head, there's no 'danger' involve=
d=20
> in=20
> > it.=20
>
> The danger already shows up.=20
>
> Quoting from the proposal:=20
>
>   "Such implicit conversions impose some risk of introducing bugs,=20
>    and in fact in order to avoid one such possible bug we had to 'poison'=
=20
>    comparisons between optional<T> and T."=20
>
> And a carefully specified comparison logic is under discussion.=20
>

The perceived danger is the opinion of the authors (myself included).=20
Others in the forum do not necessarily share this opinion.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_795_20531310.1359037320435
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 24 stycznia 2013 14:52:22 UTC+1 u=BFytkownik Zhiha=
o Yuan napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 2=
4, 2013 at 7:38 AM, Ville Voutilainen
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
M5WyFuZcwtAJ">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt; I have since cured that problem in my head, there's no 'danger' in=
volved in
<br>&gt; it.
<br>
<br>The danger already shows up.
<br>
<br>Quoting from the proposal:
<br>
<br>&nbsp; "Such implicit conversions impose some risk of introducing bugs,
<br>&nbsp; &nbsp;and in fact in order to avoid one such possible bug we had=
 to 'poison'
<br>&nbsp; &nbsp;comparisons between optional&lt;T&gt; and T."
<br>
<br>And a carefully specified comparison logic is under discussion.
<br></blockquote><div><br>The perceived danger is the opinion of the author=
s (myself included). Others in the forum do not necessarily share this opin=
ion.<br></div>

<p></p>

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

------=_Part_795_20531310.1359037320435--

.

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



W dniu czwartek, 24 stycznia 2013 14:25:49 UTC+1 u=BFytkownik Zhihao Yuan=
=20
napisa=B3:
>
> My own point of view:=20
>
> If optional<T> is an extended type T, then:=20
>
> optional<int> x =3D 0;  // implicitly convertible=20
> optional<int>(3) =3D=3D 3;  // since T is a sub-range of optional<T>=20
> optional<int>(nullopt) =3D=3D optional<int>(nullopt);  // same extended v=
alue=20
>
> If optional<T> is a T with two states, then:=20
>
> optional<int> x(0);  // explicitly convertible=20
> optional<int>(3) =3D=3D make_optional(3);  // since T is not "T with stat=
es"=20
> optional<int>(nullopt) !=3D optional<int>(nullopt);  // meaningless state=
s=20
>
> Comments wanted.=20
>

Terms "extended type" and "a type with two states" are very confusing for=
=20
me. I am not sure what you mean. Instead, if you asked -- in the spirit of=
=20
n2479 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2479.pdf>--=
 what the set of salient attributes of optional<T> is, the answer is easy.

The salient attributes are:

   1. The engaged/disengaged state
   2. If the optional object is engaged, the value of its 'contained value'=
..
  =20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_255_1430167.1359045260816
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 24 stycznia 2013 14:25:49 UTC+1 u=BFytkownik Zhiha=
o Yuan napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">My own point =
of view:
<br>
<br>If optional&lt;T&gt; is an extended type T, then:
<br>
<br>optional&lt;int&gt; x =3D 0; &nbsp;// implicitly convertible
<br>optional&lt;int&gt;(3) =3D=3D 3; &nbsp;// since T is a sub-range of opt=
ional&lt;T&gt;
<br>optional&lt;int&gt;(nullopt) =3D=3D optional&lt;int&gt;(nullopt); &nbsp=
;// same extended value
<br>
<br>If optional&lt;T&gt; is a T with two states, then:
<br>
<br>optional&lt;int&gt; x(0); &nbsp;// explicitly convertible
<br>optional&lt;int&gt;(3) =3D=3D make_optional(3); &nbsp;// since T is not=
 "T with states"
<br>optional&lt;int&gt;(nullopt) !=3D optional&lt;int&gt;(nullopt); &nbsp;/=
/ meaningless states
<br>
<br>Comments wanted.
<br></blockquote><div><br>Terms "extended type" and "a type with two states=
" are very confusing for me. I am not sure what you mean. Instead, if you a=
sked -- in the spirit of <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2007/n2479.pdf ">n2479</a> -- what the set of salient attribute=
s of optional&lt;T&gt; is, the answer is easy.<br><br>The salient attribute=
s are:<br><ol><li>The engaged/disengaged state</li><li>If the optional obje=
ct is engaged, the value of its 'contained value'.<br></li></ol></div>

<p></p>

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

------=_Part_255_1430167.1359045260816--

.

On Thu, Jan 24, 2013 at 6:15 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 8:05 AM, Chris Jefferson
> <chris@bubblescope.net> wrote:> True. But looking at the boost mailing
> list and bug reports, there does not
>> I have written quite a lot of code with boost::optional, it is very common
>> to make an optional<T> from a T, in 'return' statements for example. Having
>> to add an explicit cast to all of those would annoy me.
>
> Jeffery proposed a convert() utility to solve a problem like this:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3521.html

That proposal is for types that have a good reason to make their
conversions explicit. optional<T> has good reasons to make its
conversion implicit, and if convert() is adopted, those reasons
wouldn't go away.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 12:01 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> optional<T> has good reasons to make its
> conversion implicit, and if convert() is adopted, those reasons

My reason to support explicit conversion is a logical reason.
Think of type T with possible values { a, b, c }, and U with
possible values { a, b, c, x }, we can say T is-a U, since T can
be used everywhere U can be used.  And in such a case,
an implicit conversion from T to U is logically.

But optional<T> should be different.  In type theory, it's
T' build upon T, with possible values { a', b', c', None }.  An
implicit conversion should not be allowed here.  And no
existing functional programming language has an logic
such that to use T instead of `Some T`.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 10:13 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 12:01 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> optional<T> has good reasons to make its
>> conversion implicit, and if convert() is adopted, those reasons
>
> My reason to support explicit conversion is a logical reason.
> Think of type T with possible values { a, b, c }, and U with
> possible values { a, b, c, x }, we can say T is-a U, since T can
> be used everywhere U can be used.  And in such a case,
> an implicit conversion from T to U is logically.
>
> But optional<T> should be different.  In type theory, it's
> T' build upon T, with possible values { a', b', c', None }.  An
> implicit conversion should not be allowed here.  And no
> existing functional programming language has an logic
> such that to use T instead of `Some T`.

Which functional languages have user-defined implicit conversions at all?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 12:15 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> Which functional languages have user-defined implicit conversions at all?

Scala.
http://stackoverflow.com/questions/1746359/could-should-an-implicit-conversion-from-t-to-optiont-be-added-created-in-scal

Both side have their market.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 12:35 PM, Zhihao Yuan <lichray@gmail.com> wrote:
>> Which functional languages have user-defined implicit conversions at all?
>
> Scala.

Besides, let me say a few words about implicit conversion.
An implicit conversion from T to U should ensure that T is-a
U, the possible values of T is a subset of the possible values
of U, T -> U holds a partial-order relation.

And you will see any implicit conversion violating the above
statements is a flaw.

Narrowing conversion.  Int type T can be converted to int type
U even if T has a larger range.  One of the criticism of C++'s
type safety.

char const* to std::string.  Pointer is not a collection of chars,
while std::string is.  So `string(strdup("aha"))` result in a memory
leak.  And such a conversion implies the `array to pointer`
conversion, which makes  "nu\0\l" lost everything after '\0'.

"Those are C's probem/C has NUL-terminated strings from the
stone age. "  OK.  I'm not trying to argue these.  But keep this
in mind:  an implicit conversion from T to U without T <= U
is a flaw.

Let's go back to `std::optional`.  So that's why I ask, what is
optional<T>.  A T with a larger range, or a T with two states.
If (1), then an implicit conversion is OK, but I suggest that
to ensure "undefined == undefined" (JavaScript), or
"None == None" (Python).  Although I don't like it, and I don't
think it's safe, but this is *the* extended value.

If optional<T> is a T with two states, things go easy.  We have
numerous successful use cases in the functional programming
area.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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



W dniu czwartek, 24 stycznia 2013 20:17:55 UTC+1 u=BFytkownik Zhihao Yuan=
=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 12:35 PM, Zhihao Yuan <lic...@gmail.com<javascrip=
t:>>=20
> wrote:=20
> >> Which functional languages have user-defined implicit conversions at=
=20
> all?=20
> >=20
> > Scala.=20
>
> Besides, let me say a few words about implicit conversion.=20
> An implicit conversion from T to U should ensure that T is-a=20
> U, the possible values of T is a subset of the possible values=20
> of U, T -> U holds a partial-order relation.=20
>
> And you will see any implicit conversion violating the above=20
> statements is a flaw.=20
>
> Narrowing conversion.  Int type T can be converted to int type=20
> U even if T has a larger range.  One of the criticism of C++'s=20
> type safety.=20
>
> char const* to std::string.  Pointer is not a collection of chars,=20
> while std::string is.  So `string(strdup("aha"))` result in a memory=20
> leak.  And such a conversion implies the `array to pointer`=20
> conversion, which makes  "nu\0\l" lost everything after '\0'.=20
>
> "Those are C's probem/C has NUL-terminated strings from the=20
> stone age. "  OK.  I'm not trying to argue these.  But keep this=20
> in mind:  an implicit conversion from T to U without T <=3D U=20
> is a flaw.=20
>
> Let's go back to `std::optional`.  So that's why I ask, what is=20
> optional<T>.  A T with a larger range, or a T with two states.=20
> If (1), then an implicit conversion is OK, but I suggest that=20
> to ensure "undefined =3D=3D undefined" (JavaScript), or=20
> "None =3D=3D None" (Python).  Although I don't like it, and I don't=20
> think it's safe, but this is *the* extended value.=20
>
> If optional<T> is a T with two states, things go easy.  We have=20
> numerous successful use cases in the functional programming=20
> area.=20
>

Ok, now the question is clearer, although the "T with two states" kills me.=
=20
The design of boost::optional and now std::optional is to allow your option=
=20
1 (nullopt is just one other value of T) wherever it is reasonably safe:

optional<int> i =3D 0;
optional<int> j =3D nullopt;

i =3D 0;
j =3D nullopt;

i =3D=3D 0;
i =3D=3D nullopt;

the mixed equality comparison is allowed in boost::optional and allowing it=
=20
in std::optional is still under discussion. We cannot allow this uniformity=
=20
for reading the optional value though. Also the semantics of operator=3D=3D=
 and=20
operator< clearly indicate the "one additional value of T". I am not sure=
=20
if this answers your question.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_440_15232459.1359055844694
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 24 stycznia 2013 20:17:55 UTC+1 u=BFytkownik Zhiha=
o Yuan napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 2=
4, 2013 at 12:35 PM, Zhihao Yuan &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Y04XOOXNVrsJ">lic...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; Which functional languages have user-defined implicit conversi=
ons at all?
<br>&gt;
<br>&gt; Scala.
<br>
<br>Besides, let me say a few words about implicit conversion.
<br>An implicit conversion from T to U should ensure that T is-a
<br>U, the possible values of T is a subset of the possible values
<br>of U, T -&gt; U holds a partial-order relation.
<br>
<br>And you will see any implicit conversion violating the above
<br>statements is a flaw.
<br>
<br>Narrowing conversion. &nbsp;Int type T can be converted to int type
<br>U even if T has a larger range. &nbsp;One of the criticism of C++'s
<br>type safety.
<br>
<br>char const* to std::string. &nbsp;Pointer is not a collection of chars,
<br>while std::string is. &nbsp;So `string(strdup("aha"))` result in a memo=
ry
<br>leak. &nbsp;And such a conversion implies the `array to pointer`
<br>conversion, which makes &nbsp;"nu\0\l" lost everything after '\0'.
<br>
<br>"Those are C's probem/C has NUL-terminated strings from the
<br>stone age. " &nbsp;OK. &nbsp;I'm not trying to argue these. &nbsp;But k=
eep this
<br>in mind: &nbsp;an implicit conversion from T to U without T &lt;=3D U
<br>is a flaw.
<br>
<br>Let's go back to `std::optional`. &nbsp;So that's why I ask, what is
<br>optional&lt;T&gt;. &nbsp;A T with a larger range, or a T with two state=
s.
<br>If (1), then an implicit conversion is OK, but I suggest that
<br>to ensure "undefined =3D=3D undefined" (JavaScript), or
<br>"None =3D=3D None" (Python). &nbsp;Although I don't like it, and I don'=
t
<br>think it's safe, but this is *the* extended value.
<br>
<br>If optional&lt;T&gt; is a T with two states, things go easy. &nbsp;We h=
ave
<br>numerous successful use cases in the functional programming
<br>area.
<br></blockquote><div><br>Ok, now the question is clearer, although the "T =
with two states" kills me. The design of boost::optional and now std::optio=
nal is to allow your option 1 (nullopt is just one other value of T) wherev=
er it is reasonably safe:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">optional</span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>optional</span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> j </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> nullopt</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br>i </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>j </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> nullopt</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br>i </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>i </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> nullopt</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></div></code></div><br>the mixed equality comparison is allowed=
 in boost::optional and allowing it in std::optional is still under discuss=
ion. We cannot allow this uniformity for reading the optional value though.=
 Also the semantics of operator=3D=3D and operator&lt; clearly indicate the=
 "one additional value of T". I am not sure if this answers your question.<=
br></div>

<p></p>

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

------=_Part_440_15232459.1359055844694--

.

On Thu, Jan 24, 2013 at 1:30 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> i =3D=3D nullopt;

  j =3D=3D nullopt, I suppose?

> The design of boost::optional and now std::optional is to allow your opti=
on 1
> (nullopt is just one other value of T) wherever it is reasonably safe:

OK.  Although it less safe then a strong "Option type", it's safer than
null, undefined, etc., thanks to template.  I'd like to hear some good
news from the next meeting :)


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On Thu, Jan 24, 2013 at 12:22 PM, Andrzej Krzemie=F1ski
<akrzemi1@gmail.com> wrote:
>
>
> W dniu czwartek, 24 stycznia 2013 14:52:22 UTC+1 u=BFytkownik Zhihao Yuan
> napisa=B3:
>>
>> On Thu, Jan 24, 2013 at 7:38 AM, Ville Voutilainen
>> <ville.vo...@gmail.com> wrote:
>> > I have since cured that problem in my head, there's no 'danger' involv=
ed
>> > in
>> > it.
>>
>> The danger already shows up.
>>
>> Quoting from the proposal:
>>
>>   "Such implicit conversions impose some risk of introducing bugs,
>>    and in fact in order to avoid one such possible bug we had to 'poison=
'
>>    comparisons between optional<T> and T."
>>
>> And a carefully specified comparison logic is under discussion.
>
>
> The perceived danger is the opinion of the authors (myself included).

To be honest, it is more that I was sold into it :)

Again if it where entirely up to me, I would put this back in as well
as mixed comparison operators.

So, it's once a again more of a matter of gauging the probable
reaction among voting committee members.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On Fri, Jan 25, 2013 at 7:07 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 12:22 PM, Andrzej Krzemie=F1ski
> <akrzemi1@gmail.com> wrote:
>>
>>
>> W dniu czwartek, 24 stycznia 2013 14:52:22 UTC+1 u=BFytkownik Zhihao Yua=
n
>> napisa=B3:
>>>
>>> On Thu, Jan 24, 2013 at 7:38 AM, Ville Voutilainen
>>> <ville.vo...@gmail.com> wrote:
>>> > I have since cured that problem in my head, there's no 'danger' invol=
ved
>>> > in
>>> > it.
>>>
>>> The danger already shows up.
>>>
>>> Quoting from the proposal:
>>>
>>>   "Such implicit conversions impose some risk of introducing bugs,
>>>    and in fact in order to avoid one such possible bug we had to 'poiso=
n'
>>>    comparisons between optional<T> and T."
>>>
>>> And a carefully specified comparison logic is under discussion.
>>
>>
>> The perceived danger is the opinion of the authors (myself included).
>
> To be honest, it is more that I was sold into it :)
>
> Again if it where entirely up to me, I would put this back in as well
> as mixed comparison operators.
>
> So, it's once a again more of a matter of gauging the probable
> reaction among voting committee members.
>

In my opinion:

- There's a precedent in other languages for a ".get(default_value)".
Why don't we have this for optional instead?

- Why are we forcing pointer semantics on optional? Maybe there's a
different concept here at play.

- As a value type I would be very leery of mixing comparison
operators. Think about how NaN already works in terms of comparison
with float/doubles. It would be surprising to have an optional value
be comparable to a non-optional value.

- Implicit conversion: no confusion here, it's convenient and simple.
If a function takes a optional<T> and you gave it '{}' then you should
expect a default-constructed optional<T> (disengaged). It doesn't make
sense for that optional to be comparable to a non-optional (or
actually even to another optional). The values very well may be
comparable in which case you just compare the values if there are
values to compare.

All I'm reading so far as been "I don't like this" or "I don't prefer
this". I have not seen any sound logical reasoning to say that
anything thus far being presented is illogical or "does not make
sense".

--=20

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



.

On Thu, Jan 24, 2013 at 7:10 PM, Dean Michael Berris <dberris@google.com> wrote:
>
> In my opinion:
>
> - There's a precedent in other languages for a ".get(default_value)".
> Why don't we have this for optional instead?
>

opt.get(17) doesn't look like it is using a default to me.  Typically
get(17) is get the 17th element or lookup with key = 17, etc.


> - Why are we forcing pointer semantics on optional? Maybe there's a
> different concept here at play.
>

Because much of optional's interface is similar to pointers:  you
access the value with *opt and opt can be NULL.

That is the essential "problem" with optional.  Sometimes it acts
value-ish, sometimes pointer-ish.  It is like quantum physics -
sometimes a particle, sometimes a wave...

Tony

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Fri, Jan 25, 2013 at 3:56 PM, Tony V E <tvaneerd@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 7:10 PM, Dean Michael Berris <dberris@google.com> wrote:
>>
>> In my opinion:
>>
>> - There's a precedent in other languages for a ".get(default_value)".
>> Why don't we have this for optional instead?
>>
>
> opt.get(17) doesn't look like it is using a default to me.  Typically
> get(17) is get the 17th element or lookup with key = 17, etc.
>

Right. I was confused by Python's dict that has a method "get" which
takes the key and the default value to return if the key is not found.

>
>> - Why are we forcing pointer semantics on optional? Maybe there's a
>> different concept here at play.
>>
>
> Because much of optional's interface is similar to pointers:  you
> access the value with *opt and opt can be NULL.
>

Right, but that's a good thing right? Something you can copy around,
acts as a value, and gives you pointer semantics. It could be that the
answer is a standalone function that works with pointers, optionals,
and NullableProxy objects like:

template <class T, class NullableProxy>
T get(NullableProxy &&p, T&& t) {
  if (p) return *p;
  return std::forward<T>(t);
}

> That is the essential "problem" with optional.  Sometimes it acts
> value-ish, sometimes pointer-ish.  It is like quantum physics -
> sometimes a particle, sometimes a wave...
>

I thought it was always a value. Is there any confusion in that?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_131_14751153.1359096908050
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, January 24, 2013 8:56:08 PM UTC-8, Tony V E wrote:
>
> On Thu, Jan 24, 2013 at 7:10 PM, Dean Michael Berris <dbe...@google.com<javascript:>>
> wrote:
> >
> > In my opinion:
> >
> > - There's a precedent in other languages for a ".get(default_value)".
> > Why don't we have this for optional instead?
> >
>
> opt.get(17) doesn't look like it is using a default to me.  Typically
> get(17) is get the 17th element or lookup with key = 17, etc.
>
>
> > - Why are we forcing pointer semantics on optional? Maybe there's a
> > different concept here at play.
> >
>
> Because much of optional's interface is similar to pointers:  you
> access the value with *opt and opt can be NULL.
>
> That is the essential "problem" with optional.  Sometimes it acts
> value-ish, sometimes pointer-ish.  It is like quantum physics -
> sometimes a particle, sometimes a wave...
>

But it doesn't act like a pointer. Indeed, the *only* thing "pointer-ish"
about it is that it has an `operator*`. In every other way, it acts like a
value.

If it helps limit confusion, we could get rid of `operator*`.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<br><br>On Thursday, January 24, 2013 8:56:08 PM UTC-8, Tony V E wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 24, 2013 at 7:10 PM, D=
ean Michael Berris &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"TMEgzGYEbWYJ">dbe...@google.com</a>&gt; wrote:
<br>&gt;
<br>&gt; In my opinion:
<br>&gt;
<br>&gt; - There's a precedent in other languages for a ".get(default_value=
)".
<br>&gt; Why don't we have this for optional instead?
<br>&gt;
<br>
<br>opt.get(17) doesn't look like it is using a default to me. &nbsp;Typica=
lly
<br>get(17) is get the 17th element or lookup with key =3D 17, etc.
<br>
<br>
<br>&gt; - Why are we forcing pointer semantics on optional? Maybe there's =
a
<br>&gt; different concept here at play.
<br>&gt;
<br>
<br>Because much of optional's interface is similar to pointers: &nbsp;you
<br>access the value with *opt and opt can be NULL.
<br>
<br>That is the essential "problem" with optional. &nbsp;Sometimes it acts
<br>value-ish, sometimes pointer-ish. &nbsp;It is like quantum physics -
<br>sometimes a particle, sometimes a wave...
<br></blockquote><div><br>But it doesn't act like a pointer. Indeed, the *o=
nly* thing "pointer-ish" about it is that it has an `operator*`. In every o=
ther way, it acts like a value.</div><br>If it helps limit confusion, we co=
uld get rid of `operator*`.<br>

<p></p>

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

------=_Part_131_14751153.1359096908050--

.

On Fri, Jan 25, 2013 at 1:55 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Thursday, January 24, 2013 8:56:08 PM UTC-8, Tony V E wrote:
>>
>> On Thu, Jan 24, 2013 at 7:10 PM, Dean Michael Berris <dbe...@google.com>
>> wrote:
>> >
>> > In my opinion:
>> >
>> > - There's a precedent in other languages for a ".get(default_value)".
>> > Why don't we have this for optional instead?
>> >
>>
>> opt.get(17) doesn't look like it is using a default to me.  Typically
>> get(17) is get the 17th element or lookup with key = 17, etc.
>>
>>
>> > - Why are we forcing pointer semantics on optional? Maybe there's a
>> > different concept here at play.
>> >
>>
>> Because much of optional's interface is similar to pointers:  you
>> access the value with *opt and opt can be NULL.
>>
>> That is the essential "problem" with optional.  Sometimes it acts
>> value-ish, sometimes pointer-ish.  It is like quantum physics -
>> sometimes a particle, sometimes a wave...
>
>
> But it doesn't act like a pointer. Indeed, the *only* thing "pointer-ish"
> about it is that it has an `operator*`. In every other way, it acts like a
> value.

And can be NULL.

It has value semantics, for the most part (ie besides the null), but
pointer syntax.

That's not necessarily wrong, but I do think it is and the heart of
many of the questions/issues.

>
> If it helps limit confusion, we could get rid of `operator*`.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_144_19398978.1359145236245
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 25, 2013 8:05:06 AM UTC-8, Tony V E wrote:
>
> On Fri, Jan 25, 2013 at 1:55 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> >
> >
> > On Thursday, January 24, 2013 8:56:08 PM UTC-8, Tony V E wrote:
> >>
> >> On Thu, Jan 24, 2013 at 7:10 PM, Dean Michael Berris <dbe...@google.com>
>
> >> wrote:
> >> >
> >> > In my opinion:
> >> >
> >> > - There's a precedent in other languages for a ".get(default_value)".
> >> > Why don't we have this for optional instead?
> >> >
> >>
> >> opt.get(17) doesn't look like it is using a default to me.  Typically
> >> get(17) is get the 17th element or lookup with key = 17, etc.
> >>
> >>
> >> > - Why are we forcing pointer semantics on optional? Maybe there's a
> >> > different concept here at play.
> >> >
> >>
> >> Because much of optional's interface is similar to pointers:  you
> >> access the value with *opt and opt can be NULL.
> >>
> >> That is the essential "problem" with optional.  Sometimes it acts
> >> value-ish, sometimes pointer-ish.  It is like quantum physics -
> >> sometimes a particle, sometimes a wave...
> >
> >
> > But it doesn't act like a pointer. Indeed, the *only* thing
> "pointer-ish"
> > about it is that it has an `operator*`. In every other way, it acts like
> a
> > value.
>
> And can be NULL.
>

No, it can be *empty*, not NULL. `optional` is a container.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<br><br>On Friday, January 25, 2013 8:05:06 AM UTC-8, Tony V E wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 25, 2013 at 1:55 AM, Nic=
ol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"Ep4hNJEqEYIJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Thursday, January 24, 2013 8:56:08 PM UTC-8, Tony V E wrote:
<br>&gt;&gt;
<br>&gt;&gt; On Thu, Jan 24, 2013 at 7:10 PM, Dean Michael Berris &lt;<a>db=
e...@google.com</a>&gt;
<br>&gt;&gt; wrote:
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; In my opinion:
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; - There's a precedent in other languages for a ".get(defa=
ult_value)".
<br>&gt;&gt; &gt; Why don't we have this for optional instead?
<br>&gt;&gt; &gt;
<br>&gt;&gt;
<br>&gt;&gt; opt.get(17) doesn't look like it is using a default to me. &nb=
sp;Typically
<br>&gt;&gt; get(17) is get the 17th element or lookup with key =3D 17, etc=
..
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; &gt; - Why are we forcing pointer semantics on optional? Maybe=
 there's a
<br>&gt;&gt; &gt; different concept here at play.
<br>&gt;&gt; &gt;
<br>&gt;&gt;
<br>&gt;&gt; Because much of optional's interface is similar to pointers: &=
nbsp;you
<br>&gt;&gt; access the value with *opt and opt can be NULL.
<br>&gt;&gt;
<br>&gt;&gt; That is the essential "problem" with optional. &nbsp;Sometimes=
 it acts
<br>&gt;&gt; value-ish, sometimes pointer-ish. &nbsp;It is like quantum phy=
sics -
<br>&gt;&gt; sometimes a particle, sometimes a wave...
<br>&gt;
<br>&gt;
<br>&gt; But it doesn't act like a pointer. Indeed, the *only* thing "point=
er-ish"
<br>&gt; about it is that it has an `operator*`. In every other way, it act=
s like a
<br>&gt; value.
<br>
<br>And can be NULL.<br></blockquote><div><br>No, it can be <i>empty</i>, n=
ot NULL. `optional` is a container.<br></div><br>

<p></p>

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

------=_Part_144_19398978.1359145236245--

.

On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> And can be NULL.
>
>
> No, it can be empty, not NULL. `optional` is a container.
>

Well, the container perspective is one way of looking at it, but not
the only one.  Many people have called the concept NullableProxy, and
C# calls their closely related thing Nullable<T>, and it converts to
bool so that if (opt) works, whereas if (container) doesn't, and the
empty optional constructor is called nullopt, not emptyopt,...

Do you think we should back away from all the pointer-ish interface
parts and move more towards container-ish?  Should *opt be opt[0]
instead?  (I'm not being sarcastic, I've really been trying to find
syntax that is more container-ish).

I agree that it is not reference semantics, thus it is drastically
different than pointers in a important, fundamental way, but it does
share other semantics with pointers.  Or, I think equivalently,
pointers share some semantics with containers.  The "empty or not"
semantic.  Just not the ownership semantics.

Is there a difference between empty and null?

Tony

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Fri, Jan 25, 2013 at 5:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> Is there a difference between empty and null?
>

That sounds like I'm being a troll. (particularly since I was just
arguing that null != empty for string_ref.)  Maybe it would be better
as:

Is there a difference between empty and null?  Probably.  Is there
commonality between empty and null?  Probably.  Are there important
differences in this case, and/or is optional's
flexibility-of-perspective a feature?


Tony

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_265_32343032.1359156131821
Content-Type: text/plain; charset=ISO-8859-1

On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:
>
> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> >> And can be NULL.
> >
> >
> > No, it can be empty, not NULL. `optional` is a container.
> >
>
> Well, the container perspective is one way of looking at it, but not
> the only one.  Many people have called the concept NullableProxy, and
> C# calls their closely related thing Nullable<T>, and it converts to
> bool so that if (opt) works, whereas if (container) doesn't, and the
> empty optional constructor is called nullopt, not emptyopt,...
>
> Do you think we should back away from all the pointer-ish interface
> parts and move more towards container-ish?  Should *opt be opt[0]
> instead?  (I'm not being sarcastic, I've really been trying to find
> syntax that is more container-ish).
>

No it should not. I'm not particularly enamoured with `operator*`, but
`operator[]` makes no sense at all. Why not just `value` (or `get` for
those who like that)? Do we really need an operator at all?

There is no "all the pointer-ish interface"; there's only `operator*`.
That's the only part of optional that is like a pointer (OK, the `explicit
operator bool` too, but that's hardly unique to pointers); everything else
works differently from pointers.

These bikeshed issues are getting kinda out of control. The whole
Nullable/NullableProxy/etc stuff to me seems to be overcomplicating what is
really a very simple discussion. I need to return a value or return
nothing, and the user needs to be able to detect this. I want that thing I
return to have value semantics. End of story.

If people want to come along later and adapt the interface for some generic
`NullableProxy` concept, feel free. But the interface we use for optional
should be doing what we need optional to do. No more, no less. The concept
can adapt the interface as needed.

I agree that it is not reference semantics, thus it is drastically
> different than pointers in a important, fundamental way, but it does
> share other semantics with pointers.  Or, I think equivalently,
> pointers share some semantics with containers.  The "empty or not"
> semantic.  Just not the ownership semantics.
>
> Is there a difference between empty and null?
>

Yes: `optional<T*>` exists. Such an object has 3 possible states: the
optional could be empty. The optional could contain a valid pointer. Or the
optional could contain *nullptr*.

That's why we should not consider them the same. To me, "null" means "a
pointer which has no value and cannot be derefenced". If you say that an
`optional<T*>` is "null", my assumption is that you're talking about what
is stored within the optional and not the state of the optional itself.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas=
 &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"LNB=
oVr49mZEJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; And can be NULL.
<br>&gt;
<br>&gt;
<br>&gt; No, it can be empty, not NULL. `optional` is a container.
<br>&gt;
<br>
<br>Well, the container perspective is one way of looking at it, but not
<br>the only one. &nbsp;Many people have called the concept NullableProxy, =
and
<br>C# calls their closely related thing Nullable&lt;T&gt;, and it converts=
 to
<br>bool so that if (opt) works, whereas if (container) doesn't, and the
<br>empty optional constructor is called nullopt, not emptyopt,...
<br>
<br>Do you think we should back away from all the pointer-ish interface
<br>parts and move more towards container-ish? &nbsp;Should *opt be opt[0]
<br>instead? &nbsp;(I'm not being sarcastic, I've really been trying to fin=
d
<br>syntax that is more container-ish).<br></blockquote><div><br>No it shou=
ld not. I'm not particularly enamoured with `operator*`, but `operator[]` m=
akes no sense at all. Why not just `value` (or `get` for those who like tha=
t)? Do we really need an operator at all?<br><br>There is no "all the point=
er-ish interface"; there's only `operator*`. That's the only part of option=
al that is like a pointer (OK, the `explicit operator bool` too, but that's=
 hardly unique to pointers); everything else works differently from pointer=
s.<br><br>These bikeshed issues are getting kinda out of control. The whole=
 Nullable/NullableProxy/etc stuff to me seems to be overcomplicating what i=
s really a very simple discussion. I need to return a value or return nothi=
ng, and the user needs to be able to detect this. I want that thing I retur=
n to have value semantics. End of story.<br><br>If people want to come alon=
g later and adapt the interface for some generic `NullableProxy` concept, f=
eel free. But the interface we use for optional should be doing what we nee=
d optional to do. No more, no less. The concept can adapt the interface as =
needed.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
I agree that it is not reference semantics, thus it is drastically
<br>different than pointers in a important, fundamental way, but it does
<br>share other semantics with pointers. &nbsp;Or, I think equivalently,
<br>pointers share some semantics with containers. &nbsp;The "empty or not"
<br>semantic. &nbsp;Just not the ownership semantics.
<br>
<br>Is there a difference between empty and null?<br></blockquote><div><br>=
Yes: `optional&lt;T*&gt;` exists. Such an object has 3 possible states: the=
 optional could be empty. The optional could contain a valid pointer. Or th=
e optional could contain <i>nullptr</i>.<br><br>That's why we should not co=
nsider them the same. To me, "null" means "a pointer which has no value and=
 cannot be derefenced". If you say that an `optional&lt;T*&gt;` is "null", =
my assumption is that you're talking about what is stored within the option=
al and not the state of the optional itself.<br></div>

<p></p>

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

------=_Part_265_32343032.1359156131821--

.

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



W dniu pi=B1tek, 25 stycznia 2013 23:09:20 UTC+1 u=BFytkownik Tony V E napi=
sa=B3:
>
> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com<javascrip=
t:>>=20
> wrote:=20
> >> And can be NULL.=20
> >=20
> >=20
> > No, it can be empty, not NULL. `optional` is a container.=20
> >=20
>
> Well, the container perspective is one way of looking at it, but not=20
> the only one.  Many people have called the concept NullableProxy, and=20
> C# calls their closely related thing Nullable<T>, and it converts to=20
> bool so that if (opt) works, whereas if (container) doesn't, and the=20
> empty optional constructor is called nullopt, not emptyopt,...=20
>
> Do you think we should back away from all the pointer-ish interface=20
> parts and move more towards container-ish?  Should *opt be opt[0]=20
> instead?  (I'm not being sarcastic, I've really been trying to find=20
> syntax that is more container-ish).=20
>
> I agree that it is not reference semantics, thus it is drastically=20
> different than pointers in a important, fundamental way, but it does=20
> share other semantics with pointers.  Or, I think equivalently,=20
> pointers share some semantics with containers.  The "empty or not"=20
> semantic.  Just not the ownership semantics.=20
>
> Is there a difference between empty and null?=20
>

These questions are really interesting. I do not want to answer them too=20
hastily. There is also one practical aspect that needs to be considered.=20
Regardless of what optional _is_, its primary use case (there are quite=20
many secondary use cases) is this: a function returns to you an optional=20
object (it owns the value). You *check if* there is a 'real' value, and if=
=20
so, consume it. The "check if" part is very important and frequent, so we=
=20
need to offer convenience here. The contextual conversion to bool works=20
very well with an if-statement, so I consider it a "must" in the interface.

"Check if there is a 'real' value, and if so, consume it." -- I guess this=
=20
is the essence of NullableProxy. You do not even need an explicit "null".=
=20
The way I see it, both pointers and optional model the concept. The former=
=20
do it with "shallow" copy/value semantics (or reference semantics), whereas=
=20
optional does it with deep copy/value semantics.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_718_13654870.1359184400406
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu pi=B1tek, 25 stycznia 2013 23:09:20 UTC+1 u=BFytkownik Tony =
V E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 25, =
2013 at 3:20 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"LNBoVr49mZEJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; And can be NULL.
<br>&gt;
<br>&gt;
<br>&gt; No, it can be empty, not NULL. `optional` is a container.
<br>&gt;
<br>
<br>Well, the container perspective is one way of looking at it, but not
<br>the only one. &nbsp;Many people have called the concept NullableProxy, =
and
<br>C# calls their closely related thing Nullable&lt;T&gt;, and it converts=
 to
<br>bool so that if (opt) works, whereas if (container) doesn't, and the
<br>empty optional constructor is called nullopt, not emptyopt,...
<br>
<br>Do you think we should back away from all the pointer-ish interface
<br>parts and move more towards container-ish? &nbsp;Should *opt be opt[0]
<br>instead? &nbsp;(I'm not being sarcastic, I've really been trying to fin=
d
<br>syntax that is more container-ish).
<br>
<br>I agree that it is not reference semantics, thus it is drastically
<br>different than pointers in a important, fundamental way, but it does
<br>share other semantics with pointers. &nbsp;Or, I think equivalently,
<br>pointers share some semantics with containers. &nbsp;The "empty or not"
<br>semantic. &nbsp;Just not the ownership semantics.
<br>
<br>Is there a difference between empty and null?
<br></blockquote><div><br>These questions are really interesting. I do not =
want to answer them too hastily. There is also one practical aspect that ne=
eds to be considered. Regardless of what optional _is_, its primary use cas=
e (there are quite many secondary use cases) is this: a function returns to=
 you an optional object (it owns the value). You <b>check if</b> there is a=
 'real' value, and if so, consume it. The "check if" part is very important=
 and frequent, so we need to offer convenience here. The contextual convers=
ion to bool works very well with an if-statement, so I consider it a "must"=
 in the interface.<br><br>"Check if there is a 'real' value, and if so, con=
sume it." -- I guess this is the essence of NullableProxy. You do not even =
need an explicit "null". The way I see it, both pointers and optional model=
 the concept. The former do it with "shallow" copy/value semantics (or refe=
rence semantics), whereas optional does it with deep copy/value semantics. =
<br></div>

<p></p>

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

------=_Part_718_13654870.1359184400406--

.

------=_Part_710_4639801.1359194976098
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, January 26, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:
>
> On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:
>>
>> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > ...
>> Do you think we should back away from all the pointer-ish interface
>> parts and move more towards container-ish?
>>
>
"We" are reading the 3rd revision of the document describing the facility
which has been in heavy use for a while and which has already been
submitted for standardization. "we should back away from all the
pointer-ish interface"... Is it a serious question or a tease?



> No it should not. I'm not particularly enamoured with `operator*`, but
> `operator[]` makes no sense at all. Why not just `value` (or `get` for
> those who like that)? Do we really need an operator at all?
>

Uhm, because we need to dereference 'optional' and the language has a
dereferencing operator (op*) which happens to be used everywhere else to
dereference.


> There is no "all the pointer-ish interface"; there's only `operator*.
> That's the only part of optional that is like a pointer (OK, the `explicit
> operator bool` too, but that's hardly unique to pointers); everything else
> works differently from pointers.
>

There is nothing "pointer-ish" about the operator called a dereferencing
operator. Customization (oveloading) of that op* together with the other
dereferencing op->() is "important to a class of interesting programs" (as
Stroustrup puts it). Indeed, that interface (as many other concepts) has
been borrowed from C where these operators worked with pointers and C++
intentionally preserves C syntactic flavor. It does not make pointers claim
"ownership" of these operators. These operators are the standard interface
for the whole family of classes implementing the proxy concept/pattern...
and the pointer is just one -- the most basic and primitive --
implementation of that concept.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

On Saturday, January 26, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Friday, January 25, 2013 2:09:20 P=
M UTC-8, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jan=
 25, 2013 at 3:20 PM, Nicol Bolas &lt;<a>jmck...@gmail.com</a>&gt; wrote:
<br>&gt; ...
<br>
Do you think we should back away from all the pointer-ish interface
<br>parts and move more towards container-ish?&nbsp; <br></blockquote></blo=
ckquote><div><br>"We" are reading the 3rd revision of the document describi=
ng the facility which has been in heavy use for a while and which has alrea=
dy been submitted for standardization. "we should back away from all the po=
inter-ish interface"...
Is it a serious question or a tease?<br>&nbsp;<br></div><div>&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"></blockquote><div>No it should not. I'm not particularly enamoured =
with `operator*`, but `operator[]` makes no sense at all. Why not just `val=
ue` (or `get` for those who like that)? Do we really need an operator at al=
l?<br></div></blockquote><div><br>Uhm, because we need to dereference 'opti=
onal' and the language has a dereferencing operator (op*) which happens to =
be used everywhere else to dereference.&nbsp; <br>&nbsp;</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div>There is no "all the pointer-ish inter=
face"; there's only `operator*. That's the only part of optional that is li=
ke a pointer (OK, the `explicit operator bool` too, but that's hardly uniqu=
e to pointers); everything else works differently from pointers.<br></div><=
/blockquote><div><br>There is nothing "pointer-ish" about the operator call=
ed a dereferencing operator. Customization (oveloading) of that op* togethe=
r with the other dereferencing op-&gt;() is "important to a class of intere=
sting programs" (as Stroustrup puts it). Indeed, that interface (as many ot=
her concepts) has been borrowed from C where these operators worked with po=
inters and C++ intentionally preserves C syntactic flavor. It does not make=
 pointers claim "ownership" of these operators. These operators are the sta=
ndard interface for the whole family of classes implementing the proxy conc=
ept/pattern... and the pointer is just one -- the most basic and primitive =
-- implementation of that concept. <br>&nbsp;</div><br>

<p></p>

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

------=_Part_710_4639801.1359194976098--

.

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



2013. janu=E1r 26., szombat 0:22:11 UTC+1 id=F5pontban Nicol Bolas a k=F6ve=
tkez=F5t=20
=EDrta:
>
> Yes: `optional<T*>` exists. Such an object has 3 possible states: the=20
> optional could be empty. The optional could contain a valid pointer. Or t=
he=20
> optional could contain *nullptr*.
>
>
I'd argue that this is still two state: empty, or a valid pointer. nullptr =
*is=20
*a valid pointer value, or to be more exact, T*(nullptr) is.

Regards, Robert

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_826_8549850.1359204265818
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. janu=E1r 26., szombat 0:22:11 UTC+1 id=F5pontban Nicol Bolas =
a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yes: `=
optional&lt;T*&gt;` exists. Such an object has 3 possible states: the optio=
nal could be empty. The optional could contain a valid pointer. Or the opti=
onal could contain <i>nullptr</i>.<br><div><br></div></blockquote><div><br>=
I'd argue that this is still two state: empty, or a valid pointer. <span st=
yle=3D"font-family: courier new,monospace;">nullptr</span> <b><i>is </i></b=
>a valid pointer value, or to be more exact, <span style=3D"font-family: co=
urier new,monospace;">T*(nullptr)</span> is.<br><br>Regards, Robert<br></di=
v>

<p></p>

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

------=_Part_826_8549850.1359204265818--

.

------=_Part_769_9008552.1359204893136
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, January 26, 2013 2:09:36 AM UTC-8, Vladimir Batov wrote:
>
> On Saturday, January 26, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:
>>
>> On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:
>>>
>>> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>> > ...
>>> Do you think we should back away from all the pointer-ish interface
>>> parts and move more towards container-ish?
>>>
>>
> "We" are reading the 3rd revision of the document describing the facility
> which has been in heavy use for a while and which has already been
> submitted for standardization. "we should back away from all the
> pointer-ish interface"... Is it a serious question or a tease?
>
>
>
>> No it should not. I'm not particularly enamoured with `operator*`, but
>> `operator[]` makes no sense at all. Why not just `value` (or `get` for
>> those who like that)? Do we really need an operator at all?
>>
>
> Uhm, because we need to dereference 'optional' and the language has a
> dereferencing operator (op*) which happens to be used everywhere else to
> dereference.
>

That's called "assuming the conclusion" or "begging the question". The
question in this case being whether `optional` should be thought of as
being like a pointer. IE: that optional is a thing that can be dereferenced.

You don't dereference an optional any more than you dereference a
std::vector. You only dereference *references* (it's right there in the
name), and one of the most important aspects of optional is that it has *
value* semantics, not reference semantics. Optional is not a reference, so
it doesn't make sense to use reference-like operations on it.

Dereferencing an optional makes no more sense than dereferencing an integer.

There is no "all the pointer-ish interface"; there's only `operator*.
>> That's the only part of optional that is like a pointer (OK, the `explicit
>> operator bool` too, but that's hardly unique to pointers); everything else
>> works differently from pointers.
>>
>
> There is nothing "pointer-ish" about the operator called a dereferencing
> operator.
>

There is only one C++ type upon which applying uniary operator* results in
guaranteed dereferencing. And those are pointers.

Pointers may not be the only things you can use uniary operator* on, but
the user expectation of it is very clear: dereferencing a reference type.
std::ref is a reference type. std::unique_ptr is a reference type.

std::optional is not.

Customization (oveloading) of that op* together with the other
> dereferencing op->() is "important to a class of interesting programs" (as
> Stroustrup puts it).
>

No, the ability to fetch the value from an optional is important. Exactly
how you do that is dealer's choice.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<br><br>On Saturday, January 26, 2013 2:09:36 AM UTC-8, Vladimir Batov wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, January 26, 201=
3 10:22:11 AM UTC+11, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas=
 &lt;<a>jmck...@gmail.com</a>&gt; wrote:
<br>&gt; ...
<br>
Do you think we should back away from all the pointer-ish interface
<br>parts and move more towards container-ish?&nbsp; <br></blockquote></blo=
ckquote><div><br>"We" are reading the 3rd revision of the document describi=
ng the facility which has been in heavy use for a while and which has alrea=
dy been submitted for standardization. "we should back away from all the po=
inter-ish interface"...
Is it a serious question or a tease?<br>&nbsp;<br></div><div>&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"></blockquote><div>No it should not. I'm not particularly enamoured with =
`operator*`, but `operator[]` makes no sense at all. Why not just `value` (=
or `get` for those who like that)? Do we really need an operator at all?<br=
></div></blockquote><div><br>Uhm, because we need to dereference 'optional'=
 and the language has a dereferencing operator (op*) which happens to be us=
ed everywhere else to dereference.<br></div></blockquote><div><br>That's ca=
lled "assuming the conclusion" or "begging the question". The question in t=
his case being whether `optional` should be thought of as being like a poin=
ter. IE: that optional is a thing that can be dereferenced.<br><br>You don'=
t dereference an optional any more than you dereference a std::vector. You =
only dereference <i>references</i> (it's right there in the name), and one =
of the most important aspects of optional is that it has <i>value</i> seman=
tics, not reference semantics. Optional is not a reference, so it doesn't m=
ake sense to use reference-like operations on it.<br><br>Dereferencing an o=
ptional makes no more sense than dereferencing an integer.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div>There is no "all the pointer-ish interface"; there's=
 only `operator*. That's the only part of optional that is like a pointer (=
OK, the `explicit operator bool` too, but that's hardly unique to pointers)=
; everything else works differently from pointers.<br></div></blockquote><d=
iv><br>There is nothing "pointer-ish" about the operator called a dereferen=
cing operator.</div></blockquote><div><br>There is only one C++ type upon w=
hich applying uniary operator* results in guaranteed dereferencing. And tho=
se are pointers.<br><br>Pointers may not be the only things you can use uni=
ary operator* on, but the user expectation of it is very clear: dereferenci=
ng a reference type. std::ref is a reference type. std::unique_ptr is a ref=
erence type.<br><br>std::optional is not.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div>Customization (oveloading) of that op* togeth=
er with the other dereferencing op-&gt;() is "important to a class of inter=
esting programs" (as Stroustrup puts it).</div></blockquote><div><br>No, th=
e ability to fetch the value from an optional is important. Exactly how you=
 do that is dealer's choice.</div>

<p></p>

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

------=_Part_769_9008552.1359204893136--

.

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



On Saturday, January 26, 2013 4:44:25 AM UTC-8, R=C3=B3bert D=C3=A1vid wrot=
e:
>
>
>
> 2013. janu=C3=A1r 26., szombat 0:22:11 UTC+1 id=C5=91pontban Nicol Bolas =
a=20
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>> Yes: `optional<T*>` exists. Such an object has 3 possible states: the=20
>> optional could be empty. The optional could contain a valid pointer. Or =
the=20
>> optional could contain *nullptr*.
>>
>>
> I'd argue that this is still two state: empty, or a valid pointer. nullpt=
r=20
> *is *a valid pointer value, or to be more exact, T*(nullptr) is.
>

This is exactly my point: that's why you can't have use "null" to mean=20
"empty optional." Because it might mean something else.

--=20

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



------=_Part_796_16203720.1359206995428
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, January 26, 2013 4:44:25 AM UTC-8, R=C3=B3bert D=C3=A1=
vid wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>2013. janu=
=C3=A1r 26., szombat 0:22:11 UTC+1 id=C5=91pontban Nicol Bolas a k=C3=B6vet=
kez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Yes: `optional=
&lt;T*&gt;` exists. Such an object has 3 possible states: the optional coul=
d be empty. The optional could contain a valid pointer. Or the optional cou=
ld contain <i>nullptr</i>.<br><div><br></div></blockquote><div><br>I'd argu=
e that this is still two state: empty, or a valid pointer. <span style=3D"f=
ont-family:courier new,monospace">nullptr</span> <b><i>is </i></b>a valid p=
ointer value, or to be more exact, <span style=3D"font-family:courier new,m=
onospace">T*(nullptr)</span> is.<br></div></blockquote><div><br>This is exa=
ctly my point: that's why you can't have use "null" to mean "empty optional=
.." Because it might mean something else.<br></div>

<p></p>

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

------=_Part_796_16203720.1359206995428--

.

------=_Part_959_7897526.1359223293547
Content-Type: text/plain; charset=ISO-8859-1

Op vrijdag 25 januari 2013 21:20:36 UTC+1 schreef Nicol Bolas het volgende:

> And can be NULL.
>
> No, it can be *empty*, not NULL. `optional` is a container.
>

Is it?
The C++ container concept has a lot of requirements that optional doesn't
meet.
 I think using operator* is natural.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<span style=3D"font-size: 13px;">Op vrijdag 25 januari 2013 21:20:36 UTC+1 =
schreef Nicol Bolas het volgende:</span><br><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><span style=3D"font-size: 13px;">And can be NULL.</span><br><=
div><br>No, it can be <i>empty</i>, not NULL. `optional` is a container.</d=
iv></blockquote><div><br></div><div>Is it?</div><div>The C++ container conc=
ept has a lot of requirements that optional doesn't meet.</div><div>&nbsp;I=
 think using operator* is natural.</div>

<p></p>

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

------=_Part_959_7897526.1359223293547--

.

--14dae93403471dcfa804d4375c95
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jan 26, 2013 at 11:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Saturday, January 26, 2013 2:09:36 AM UTC-8, Vladimir Batov wrote:
>>
>> On Saturday, January 26, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:
>>>
>>> On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:
>>>>
>>>> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com>
>>>> wrote:
>>>> > ...
>>>> Do you think we should back away from all the pointer-ish interface
>>>> parts and move more towards container-ish?
>>>>
>>>
>> "We" are reading the 3rd revision of the document describing the facility
>> which has been in heavy use for a while and which has already been
>> submitted for standardization. "we should back away from all the
>> pointer-ish interface"... Is it a serious question or a tease?
>>
>>
>>
>>> No it should not. I'm not particularly enamoured with `operator*`, but
>>> `operator[]` makes no sense at all. Why not just `value` (or `get` for
>>> those who like that)? Do we really need an operator at all?
>>>
>>
>> Uhm, because we need to dereference 'optional' and the language has a
>> dereferencing operator (op*) which happens to be used everywhere else to
>> dereference.
>>
>
> That's called "assuming the conclusion" or "begging the question".
>

Why beg the question when you can ask the question you are begging for? :-)
Seriously though I was trying to convey my impression that the thread
(which I considered the question to be the culmination of) went on such a
tangent that it somewhat lost *practical* value for the class under
consideration/discussion taking into account its current state progress so
far. I might be wrong as usual.

The question in this case being whether `optional` should be thought of as
> being like a pointer. IE: that optional is a thing that can be dereferenced.
>

I fail to see the practical value of trying so hard and squeezing
'optional' into Procrustean bed of some other concept be that a container,
a pointer, or anything else. We can debate endlessly similarities and
differences. However, 'optional' serves a certain need and exists for a
reason. If 'optional' was a container, then an existing container would do
just fine. If 'optional' was a pointer, then an existing pointer would be
used instead. Jack and Jill are similar from one angle and different from
another. Do we *have* to label Jack "a Jill with a dongle" and force him to
wear dress? I hope you get my drift.


> You don't dereference an optional any more than you dereference a
> std::vector. You only dereference *references* (it's right there in the
> name),
>

Uhm, I strongly feel that you treat naming and the language wa-a-a-y to
rigidly. You are not only "derail rails" and "debunk bunks". As for
"dereferencing" then it assumes indirection. In fact, Microsoft even
lists/names op* as ans indirection operator:

http://msdn.microsoft.com/en-us/library/fw63e3c3%28v=vs.71%29.aspx

Obviously, one can apply dereferencing/indirection everywhere it makes
sense. Most notably the proxy pattern which 'optional' is a representative
of.


> and one of the most important aspects of optional is that it has *value*semantics, not reference semantics. Optional is not a reference, so it
> doesn't make sense to use reference-like operations on it.
>

Well, again, I feel that for one reason or another you are forcing yourself
in a black&white world when real life is multi-faceted and multi-colored.


> Dereferencing an optional makes no more sense than dereferencing an
> integer.
>

Uhm, how does comparison with an 'integer' prove anything? Do 'optional'
and 'integer' have much in common? A real, say, horse has more in common
with a plastic figurine mimicking a horse. Still, I do not dare to say that
feeding a horse makes no more sense than feeding a plastic figurine.



>
> There is no "all the pointer-ish interface"; there's only `operator*.
>>> That's the only part of optional that is like a pointer (OK, the `explicit
>>> operator bool` too, but that's hardly unique to pointers); everything else
>>> works differently from pointers.
>>>
>>
>> There is nothing "pointer-ish" about the operator called a dereferencing
>> operator.
>>
>
> There is only one C++ type upon which applying uniary operator* results in
> guaranteed dereferencing. And those are pointers.
>

I am not sure how to respond to this one. I am quite lost about
"guaranteed" dereferencing and the statement is plain wrong in the context
of C++.



> Pointers may not be the only things you can use uniary operator* on, but
> the user expectation of it is very clear: dereferencing a reference type.
> std::ref is a reference type. std::unique_ptr is a reference type.
>

"user expectation of it is very clear"... I usually throw in the towel when
people start speaking for the whole humanity or considerable chunks of it.
I have no crystal ball or mystic powers to represent such a wide audience
and, therefore, cannot argue on such a high level. So, regretfully, I have
to give up arguing my point. It was fun though.



>
> std::optional is not.
>
> Customization (oveloading) of that op* together with the other
>> dereferencing op->() is "important to a class of interesting programs" (as
>> Stroustrup puts it).
>>
>
> No, the ability to fetch the value from an optional is important. Exactly
> how you do that is dealer's choice.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To post to this group, send email to std-proposals@isocpp.org.
> To unsubscribe from this group, send email to
> std-proposals+unsubscribe@isocpp.org.
>
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<div class=3D"gmail_quote">On Sat, Jan 26, 2013 at 11:54 PM, Nicol Bolas <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank=
">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div class=3D"im">On Saturday, January 26, 2013 2:09:36 AM UTC-8, Vladimir =
Batov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, January 26=
, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">
On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas &lt;=
<a>jmck...@gmail.com</a>&gt; wrote:
<br>&gt; ...
<br>
Do you think we should back away from all the pointer-ish interface
<br>parts and move more towards container-ish?=A0 <br></blockquote></blockq=
uote><div><br>&quot;We&quot; are reading the 3rd revision of the document d=
escribing the facility which has been in heavy use for a while and which ha=
s already been submitted for standardization. &quot;we should back away fro=
m all the pointer-ish interface&quot;...
Is it a serious question or a tease?<br>=A0<br></div><div>=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><div>No it should not. I&#39;m not particularly enamoured with=
 `operator*`, but `operator[]` makes no sense at all. Why not just `value` =
(or `get` for those who like that)? Do we really need an operator at all?<b=
r>
</div></blockquote><div><br>Uhm, because we need to dereference &#39;option=
al&#39; and the language has a dereferencing operator (op*) which happens t=
o be used everywhere else to dereference.<br></div></blockquote></div><div>
<br>That&#39;s called &quot;assuming the conclusion&quot; or &quot;begging =
the question&quot;. </div></blockquote><div><br>Why beg the question when y=
ou can ask the question you are begging for? :-) Seriously though I was try=
ing to convey my impression that the thread (which I considered the questio=
n to be the culmination of) went on such a tangent that it somewhat lost *p=
ractical* value for the class under consideration/discussion taking into ac=
count its current state progress so far. I might be wrong as usual.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div>The question in this case bei=
ng whether `optional` should be thought of as being like a pointer. IE: tha=
t optional is a thing that can be dereferenced.<br>
</div></blockquote><div><br>I fail to see the practical value of trying so =
hard and squeezing &#39;optional&#39; into Procrustean bed of some other co=
ncept be that a container, a pointer, or anything else. We can debate endle=
ssly similarities and differences. However, &#39;optional&#39; serves a cer=
tain need and exists for a reason. If &#39;optional&#39; was a container, t=
hen an existing container would do just fine. If &#39;optional&#39; was a p=
ointer, then an existing pointer would be used instead. Jack and Jill are s=
imilar from one angle and different from another. Do we *have* to label Jac=
k &quot;a Jill with a dongle&quot; and force him to wear dress? I hope you =
get my drift.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>You don&#39;t dereference an o=
ptional any more than you dereference a std::vector. You only dereference <=
i>references</i> (it&#39;s right there in the name), </div>
</blockquote><div><br>Uhm, I strongly feel that you treat naming and the la=
nguage wa-a-a-y to rigidly. You are not only &quot;derail rails&quot; and &=
quot;debunk bunks&quot;. As for &quot;dereferencing&quot; then it assumes i=
ndirection. In fact, Microsoft even lists/names op* as ans indirection oper=
ator:<br>
<br><a href=3D"http://msdn.microsoft.com/en-us/library/fw63e3c3%28v=3Dvs.71=
%29.aspx">http://msdn.microsoft.com/en-us/library/fw63e3c3%28v=3Dvs.71%29.a=
spx</a><br><br>Obviously, one can apply dereferencing/indirection everywher=
e it makes sense. Most notably the proxy pattern which &#39;optional&#39; i=
s a representative of.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>and one of the most import=
ant aspects of optional is that it has <i>value</i> semantics, not referenc=
e semantics. Optional is not a reference, so it doesn&#39;t make sense to u=
se reference-like operations on it.<br>
</div></blockquote><div><br>Well, again, I feel that for one reason or anot=
her you are forcing yourself in a black&amp;white world when real life is m=
ulti-faceted and multi-colored.=A0 <br>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div>Dereferencing an optional makes no more sense than dereferencing an in=
teger.<br></div></blockquote><div><br>Uhm, how does comparison with an &#39=
;integer&#39; prove anything? Do &#39;optional&#39; and &#39;integer&#39; h=
ave much in common? A real, say, horse has more in common with a plastic fi=
gurine mimicking a horse. Still, I do not dare to say that feeding a horse =
makes no more sense than feeding a plastic figurine.=A0 =A0 <br>
<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div><br></div><div class=3D"im=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
<div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>There is no &quot;a=
ll the pointer-ish interface&quot;; there&#39;s only `operator*. That&#39;s=
 the only part of optional that is like a pointer (OK, the `explicit operat=
or bool` too, but that&#39;s hardly unique to pointers); everything else wo=
rks differently from pointers.<br>
</div></blockquote><div><br>There is nothing &quot;pointer-ish&quot; about =
the operator called a dereferencing operator.</div></blockquote></div><div>=
<br>There is only one C++ type upon which applying uniary operator* results=
 in guaranteed dereferencing. And those are pointers.<br>
</div></blockquote><div><br>I am not sure how to respond to this one. I am =
quite lost about &quot;guaranteed&quot; dereferencing and the statement is =
plain wrong in the context of C++.<br><br>=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div>Pointers may not be the only things you can use uniary operator* on, b=
ut the user expectation of it is very clear: dereferencing a reference type=
.. std::ref is a reference type. std::unique_ptr is a reference type.<br>
</div></blockquote><div><br>&quot;user expectation of it is very clear&quot=
;... I usually throw in the towel when people start speaking for the whole =
humanity or considerable chunks of it. I have no crystal ball or mystic pow=
ers to represent such a wide audience and, therefore, cannot argue on such =
a high level. So, regretfully, I have to give up arguing my point. It was f=
un though.<br>
<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div><br>std::optional is not.<=
br><br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Customization (oveloading) of that op* together with the other derefer=
encing op-&gt;() is &quot;important to a class of interesting programs&quot=
; (as Stroustrup puts it).</div></blockquote></div><div><br>No, the ability=
 to fetch the value from an optional is important. Exactly how you do that =
is dealer&#39;s choice.</div>
<div class=3D"im">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div><div class=
=3D"im">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To unsubscribe from this group, send email to <a href=3D"mailto:std-proposa=
ls%2Bunsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@is=
ocpp.org</a>.<div class=3D"HOEnZb"><div class=3D"h5"><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br>

<p></p>

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

--14dae93403471dcfa804d4375c95--

.

On Sat, Jan 26, 2013 at 5:09 AM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> On Saturday, January 26, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:
>>
>> On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:
>>>
>>> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>> > ...
>>> Do you think we should back away from all the pointer-ish interface
>>> parts and move more towards container-ish?
>
>
> "We" are reading the 3rd revision of the document describing the facility
> which has been in heavy use for a while and which has already been submitted
> for standardization. "we should back away from all the pointer-ish
> interface"... Is it a serious question or a tease?
>

I'm not sure of your point, but if your point is that a lot of time
and effort has already been put in (and I suspect it has!) or that we
are too far along in the process:

I'd much rather put the extra effort in now than have thousands of
programmers deal with it post standardization.  Or worse yet, have a
feature that we still discuss changing _after_ standardization (ie
uniform initialization as just one example.  exported templates,...).

>
>>
>> No it should not. I'm not particularly enamoured with `operator*`, but
>> `operator[]` makes no sense at all. Why not just `value` (or `get` for those
>> who like that)? Do we really need an operator at all?
>
>
> Uhm, because we need to dereference 'optional' and the language has a
> dereferencing operator (op*) which happens to be used everywhere else to
> dereference.
>
>>
>> There is no "all the pointer-ish interface"; there's only `operator*.
>> That's the only part of optional that is like a pointer (OK, the `explicit
>> operator bool` too, but that's hardly unique to pointers); everything else
>> works differently from pointers.
>
>
> There is nothing "pointer-ish" about the operator called a dereferencing
> operator. Customization (oveloading) of that op* together with the other
> dereferencing op->() is "important to a class of interesting programs" (as
> Stroustrup puts it). Indeed, that interface (as many other concepts) has
> been borrowed from C where these operators worked with pointers and C++
> intentionally preserves C syntactic flavor. It does not make pointers claim
> "ownership" of these operators. These operators are the standard interface
> for the whole family of classes implementing the proxy concept/pattern...
> and the pointer is just one -- the most basic and primitive --
> implementation of that concept.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 26 January 2013 18:01, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Op vrijdag 25 januari 2013 21:20:36 UTC+1 schreef Nicol Bolas het volgende:
>
>> And can be NULL.
>>
>> No, it can be empty, not NULL. `optional` is a container.
>
>
> Is it?
> The C++ container concept has a lot of requirements that optional doesn't
> meet.

But it could easily be changed to meet them. 'Optional' is a container
(in the wider sense) with a maximum of 1 element. It is not in any
sense a pointer. In fact, std::optional probably should meet the basic
container requirements, as it would allow it to be used with generic
functions.

>  I think using operator* is natural.

But it does currently imply certain semantics. The current situation
is that if you write:

    auto x = y;
    *x = 2;

Then for any standard type this is equivalent to assigning '2' to
whatever y points to. By using 'operator*' in std::optional, the
semantics of 'operator*' will be changed. That shouldn't be done
lightly, especially since with templates and 'auto' a type is defined
by the functions and operators that it supports..

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 27 January 2013 22:27, Daniel James <dnljms@gmail.com> wrote:
>>  I think using operator* is natural.
> But it does currently imply certain semantics. The current situation
> is that if you write:
>
>     auto x = y;
>     *x = 2;
> Then for any standard type this is equivalent to assigning '2' to
> whatever y points to. By using 'operator*' in std::optional, the
> semantics of 'operator*' will be changed. That shouldn't be done
> lightly, especially since with templates and 'auto' a type is defined
> by the functions and operators that it supports..

What semantics does that change? The code assigns to what x points
to, x just happens to be optional<T>, which is intrusive and points to
the guts of itself. I don't see a semantic violation there.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 27 January 2013 20:46, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 27 January 2013 22:27, Daniel James <dnljms@gmail.com> wrote:
>>>  I think using operator* is natural.
>> But it does currently imply certain semantics. The current situation
>> is that if you write:
>>
>>     auto x = y;
>>     *x = 2;
>> Then for any standard type this is equivalent to assigning '2' to
>> whatever y points to. By using 'operator*' in std::optional, the
>> semantics of 'operator*' will be changed. That shouldn't be done
>> lightly, especially since with templates and 'auto' a type is defined
>> by the functions and operators that it supports..
>
> What semantics does that change? The code assigns to what x points
> to, x just happens to be optional<T>, which is intrusive and points to
> the guts of itself. I don't see a semantic violation there.

x and y point to different things with std::optional. Same code,
different results = semantic change.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 27 January 2013 22:48, Daniel James <dnljms@gmail.com> wrote:
>>>     auto x = y;
>>>     *x = 2;
>>> Then for any standard type this is equivalent to assigning '2' to
>>> whatever y points to. By using 'operator*' in std::optional, the
>>> semantics of 'operator*' will be changed. That shouldn't be done
>>> lightly, especially since with templates and 'auto' a type is defined
>>> by the functions and operators that it supports..
>> What semantics does that change? The code assigns to what x points
>> to, x just happens to be optional<T>, which is intrusive and points to
>> the guts of itself. I don't see a semantic violation there.
> x and y point to different things with std::optional. Same code,
> different results = semantic change.

Yes? x and y point to different things also if y is of the proposed
value_ptr type.
They point to different things if y is an auto_ptr. So there are
already exceptions
to this alleged rule, and chances are there's more exceptions coming.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 27 January 2013 20:55, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> Yes? x and y point to different things also if y is of the proposed
> value_ptr type.

Don't you think it's odd that value_ptr doesn't behave like a pointer?
That's because it isn't a pointer, it's a fixed size container (like
array). Calling it 'value_ptr' is like referring to 'std::vector' as
'value_ptr_with_length' - it's the implementation not the interface.

> They point to different things if y is an auto_ptr.

I'd forgotten about auto_ptr, but since it is deprecated, it's largely
irrelevant. I think everyone agrees that auto_ptr is not an example of
good design. IMO it actually supports my principle. The problem with
auto_ptr is that it doesn't follow the expected semantics.

> So there are
> already exceptions
> to this alleged rule, and chances are there's more exceptions coming.

IMO there shouldn't be. Thanks to templates, C++ has an odd mix of
structural and nominal typing. So when you have a type structure the
implies a certain behaviour, it means something. I don't think saving
a few characters is a good reason to break that. Anyone who does think
that it is should at least acknowledge that there is a trade off here.

Some people have referred to optional as a "nullable proxy". But it
isn't a proxy, it's a container (in the sense that it contains things,
not in the sense of the C++ definition - although it should be, for
things like flatMap).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Sun, Jan 27, 2013 at 9:27 PM, Daniel James <dnljms@gmail.com> wrote:
> But it could easily be changed to meet them. 'Optional' is a container
> (in the wider sense) with a maximum of 1 element. It is not in any
> sense a pointer. In fact, std::optional probably should meet the basic
> container requirements, as it would allow it to be used with generic
> functions.

It's a bit like static_vector with max_size 1, true. Though I'm not
sure what supporting a container interface really buys you.

>>  I think using operator* is natural.
>
> But it does currently imply certain semantics. The current situation
> is that if you write:
>
>     auto x = y;
>     *x = 2;
>
> Then for any standard type this is equivalent to assigning '2' to
> whatever y points to. By using 'operator*' in std::optional, the
> semantics of 'operator*' will be changed. That shouldn't be done
> lightly, especially since with templates and 'auto' a type is defined
> by the functions and operators that it supports..

Isn't that more of a problem with the constructor than with operator*?

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_497_8406806.1359323337682
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, January 27, 2013 1:39:27 PM UTC-8, Olaf van der Spek wrote:
>
> On Sun, Jan 27, 2013 at 9:27 PM, Daniel James <dnl...@gmail.com<javascript:>>
> wrote:
> > But it could easily be changed to meet them. 'Optional' is a container
> > (in the wider sense) with a maximum of 1 element. It is not in any
> > sense a pointer. In fact, std::optional probably should meet the basic
> > container requirements, as it would allow it to be used with generic
> > functions.
>
> It's a bit like static_vector with max_size 1, true. Though I'm not
> sure what supporting a container interface really buys you.
>
> >>  I think using operator* is natural.
> >
> > But it does currently imply certain semantics. The current situation
> > is that if you write:
> >
> >     auto x = y;
> >     *x = 2;
> >
> > Then for any standard type this is equivalent to assigning '2' to
> > whatever y points to. By using 'operator*' in std::optional, the
> > semantics of 'operator*' will be changed. That shouldn't be done
> > lightly, especially since with templates and 'auto' a type is defined
> > by the functions and operators that it supports..
>
> Isn't that more of a problem with the constructor than with operator*?


It's not a "problem" with the constructor. The constructor is doing exactly
what it is supposed to. The problem is with the expectation that
pointer-like things have reference semantics.

Optional is neither a container nor a pointer. It is its own type of thing,
and it should have whatever is appropriate for users of that type. We don't
want it to look too much like a pointer, lest users get the wrong idea. And
we don't want it to look too much like a container, for the same reason.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<br><br>On Sunday, January 27, 2013 1:39:27 PM UTC-8, Olaf van der Spek wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Jan 27, 2013 at 9:2=
7 PM, Daniel James &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"FNRN7xMS6l0J">dnl...@gmail.com</a>&gt; wrote:
<br>&gt; But it could easily be changed to meet them. 'Optional' is a conta=
iner
<br>&gt; (in the wider sense) with a maximum of 1 element. It is not in any
<br>&gt; sense a pointer. In fact, std::optional probably should meet the b=
asic
<br>&gt; container requirements, as it would allow it to be used with gener=
ic
<br>&gt; functions.
<br>
<br>It's a bit like static_vector with max_size 1, true. Though I'm not
<br>sure what supporting a container interface really buys you.
<br>
<br>&gt;&gt; &nbsp;I think using operator* is natural.
<br>&gt;
<br>&gt; But it does currently imply certain semantics. The current situati=
on
<br>&gt; is that if you write:
<br>&gt;
<br>&gt; &nbsp; &nbsp; auto x =3D y;
<br>&gt; &nbsp; &nbsp; *x =3D 2;
<br>&gt;
<br>&gt; Then for any standard type this is equivalent to assigning '2' to
<br>&gt; whatever y points to. By using 'operator*' in std::optional, the
<br>&gt; semantics of 'operator*' will be changed. That shouldn't be done
<br>&gt; lightly, especially since with templates and 'auto' a type is defi=
ned
<br>&gt; by the functions and operators that it supports..
<br>
<br>Isn't that more of a problem with the constructor than with operator*?<=
/blockquote><div><br>It's not a "problem" with the constructor. The constru=
ctor is doing exactly what it is supposed to. The problem is with the expec=
tation that pointer-like things have reference semantics.<br><br>Optional i=
s neither a container nor a pointer. It is its own type of thing, and it sh=
ould have whatever is appropriate for users of that type. We don't want it =
to look too much like a pointer, lest users get the wrong idea. And we don'=
t want it to look too much like a container, for the same reason.<br></div>

<p></p>

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

------=_Part_497_8406806.1359323337682--

.

On 27 January 2013 23:48, Nicol Bolas <jmckesson@gmail.com> wrote:
> It's not a "problem" with the constructor. The constructor is doing exactly
> what it is supposed to. The problem is with the expectation that
> pointer-like things have reference semantics.
> Optional is neither a container nor a pointer. It is its own type of thing,
> and it should have whatever is appropriate for users of that type. We don't
> want it to look too much like a pointer, lest users get the wrong idea. And
> we don't want it to look too much like a container, for the same reason.

I get no wrong ideas about optional or value_ptr or shared_ptr or unique_ptr,
despite their having operator*. I don't expect them to have pure reference
semantics. I have used various kinds of pointers as a substitute for having
a real optional, so in that sense I have no problem with optional being
somewhat pointer-like either.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Fri, Jan 25, 2013 at 4:17 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> Is there a difference between empty and null?
>>
> Is there a difference between empty and null?

There is difference, here are some real world examples:

1) see https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/Optional.h#L70
:

/// Note that the Optional class is basically the same as
/// Nullable. However, serializers may treat Nullable
/// and Optional differently. An example is XML serialization based
/// on XML Schema, where Optional would be used for an element with
/// minOccurs == 0, whereas Nullable would be used on an element with
/// nillable == true.

2) Another example is how different databases treat empty string,
see https://github.com/pocoproject/poco/blob/develop/Data/include/Poco/Data/AbstractSessionImpl.h#L99
:

/// Adds "emptyStringIsNull" feature and sets it to false. This
feature should be
/// set to true in order to modify the behavior of the databases that
distinguish
/// between zero-length character strings as nulls. Setting this
feature to true
/// shall disregard any difference between empty character strings and nulls,
/// causing the framework to treat them the same (i.e. behave like Oracle).

Alex

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 27 January 2013 21:39, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Sun, Jan 27, 2013 at 9:27 PM, Daniel James <dnljms@gmail.com> wrote:
>> But it could easily be changed to meet them. 'Optional' is a container
>> (in the wider sense) with a maximum of 1 element. It is not in any
>> sense a pointer. In fact, std::optional probably should meet the basic
>> container requirements, as it would allow it to be used with generic
>> functions.
>
> It's a bit like static_vector with max_size 1, true. Though I'm not
> sure what supporting a container interface really buys you.

It depends on how well the range algorithms works out. They might
provide a more elegant way to manipulate optionals than if statements,
similar to how a range algorithm can be more elegant than a for loop.
This has worked out well in other languages, for example in Scala:

http://www.scala-lang.org/api/current/index.html#scala.Option

It also allows for use in generic code, the classic example is
'flatten', which flattens a single layer of a nested container, e.g.
from vector<vector<int>> to vector<int>. If optional works as a range
then 'flatten' will also work for vector<optional<int>> resulting in a
vector that only contains the elements with values. This is
particularly useful when combined with 'transform', allowing you to
use a function which returns many values or optional values and then
flatten them into a single list. In functional languages this is
called 'flatMap' and is considered a fundamental building blocks. In
C++ such a function would have to have a different name (not sure
what, 'flat_transform' feels a bit off), and perhaps not be quite so
useful, but the point is that seeing optionals as ranges has a proven
track record.

>>>  I think using operator* is natural.
>>
>> But it does currently imply certain semantics. The current situation
>> is that if you write:
>>
>>     auto x = y;
>>     *x = 2;
>>
>> Then for any standard type this is equivalent to assigning '2' to
>> whatever y points to. By using 'operator*' in std::optional, the
>> semantics of 'operator*' will be changed. That shouldn't be done
>> lightly, especially since with templates and 'auto' a type is defined
>> by the functions and operators that it supports..
>
> Isn't that more of a problem with the constructor than with operator*?

The structural type implies certain behaviour. When a class has
'operator*' it should be expected to behave like a pointer, or if you
prefer, a proxy. Which implies that the constructor should also behave
like a pointer/proxy.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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



W dniu niedziela, 27 stycznia 2013 22:27:34 UTC+1 u=BFytkownik Daniel James=
=20
napisa=B3:
>
> On 27 January 2013 20:55, Ville Voutilainen <ville.vo...@gmail.com<javasc=
ript:>>=20
> wrote:=20
> > Yes? x and y point to different things also if y is of the proposed=20
> > value_ptr type.=20
>
> Don't you think it's odd that value_ptr doesn't behave like a pointer?=20
> That's because it isn't a pointer, it's a fixed size container (like=20
> array). Calling it 'value_ptr' is like referring to 'std::vector' as=20
> 'value_ptr_with_length' - it's the implementation not the interface.=20
>
> > They point to different things if y is an auto_ptr.=20
>
> I'd forgotten about auto_ptr, but since it is deprecated, it's largely=20
> irrelevant. I think everyone agrees that auto_ptr is not an example of=20
> good design. IMO it actually supports my principle. The problem with=20
> auto_ptr is that it doesn't follow the expected semantics.=20
>
> > So there are=20
> > already exceptions=20
> > to this alleged rule, and chances are there's more exceptions coming.=
=20
>
> IMO there shouldn't be. Thanks to templates, C++ has an odd mix of=20
> structural and nominal typing. So when you have a type structure the=20
> implies a certain behaviour, it means something. I don't think saving=20
> a few characters is a good reason to break that. Anyone who does think=20
> that it is should at least acknowledge that there is a trade off here.=20
>

This is how i see it. We all first learned how a raw pointer works, and we=
=20
keep in mind all its semantics. Then, we get shared_ptr, and it is=20
different than a raw pointer, but it is still significantly similar, that=
=20
we can still call it a pointer. Then, we have unique_ptr, which is even=20
more different. For instance, your example:

    auto x =3D y;=20
    *x =3D 2;=20

fails to compile if y is a unique_ptr. But it can still be thought of as a=
=20
pointer, because parts of the reasoning for raw pointers still applies to=
=20
unique_ptr. Now, optional is even less similar to a pointer, but it still=
=20
has some similarities. And there is enough similarities to have some=20
algorithms work both on pointers and optional. During these discussions I=
=20
was already able to identify at least four algorithms:

// Not entirely C++ syntax, but you get the idea

auto less_pointees(NullableProxy const& x, NullableProxy const& y)
{
  return (!y) ? false :(!x) ? true: *x < *y;
}

auto equal_pointees(NullableProxy const& x, NullableProxy const& y)
{
  return bool(x) !=3D bool(y) ? false : bool(x) =3D=3D false ? true : *x =
=3D=3D *y;
}

auto get_value_or(NullableProxy && np, U && val)
{
  return bool(np) ? *np : val; // + forward/move
}


auto to_pointer(NullableProxy && np)
{
  return bool(np) ? addressof(*np) : nullptr;
}


auto less_value(NullableProxy const& x, U && y)
{
  return (!x) ? true : *x < y;
}

Thus, because Identifying the common parts is useful, it is beneficial to=
=20
identify what aspects of pointers are relevant for "abstracting" type=20
requirements NullableProxy, and which aren't. And conversely, there are=20
some aspects of pointer semantics that are irrelevant (and can be dropped)=
=20
when abstracting the concept. We need operator* to express algorithms=20
common to NullablePrioxy concepts, but we are only interested in one aspect=
=20
of it: giving us the reference to the hidden value (regardless of where it=
=20
is located and how it is copied -- NullableProxies do not have to be=20
copyable or moveable). The other parts of the semantics of pointers are=20
dropped when abstracting.=20

operator* offers a couple of things. I do not think there is anything that=
=20
requires of us are using all of its semantics.=20

Typically you would expect of operator* (for multiplication) to be=20
commutative. Do you consider providing operator* for matrix multiplication=
=20
a design error then?



> Some people have referred to optional as a "nullable proxy". But it=20
> isn't a proxy, it's a container (in the sense that it contains things,=20
> not in the sense of the C++ definition - although it should be, for=20
> things like flatMap).=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_67_14748196.1359367315941
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu niedziela, 27 stycznia 2013 22:27:34 UTC+1 u=BFytkownik Dani=
el James napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 27 Janua=
ry 2013 20:55, Ville Voutilainen &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"euS-fquGG5QJ">ville.vo...@gmail.com</a>&gt; wr=
ote:
<br>&gt; Yes? x and y point to different things also if y is of the propose=
d
<br>&gt; value_ptr type.
<br>
<br>Don't you think it's odd that value_ptr doesn't behave like a pointer?
<br>That's because it isn't a pointer, it's a fixed size container (like
<br>array). Calling it 'value_ptr' is like referring to 'std::vector' as
<br>'value_ptr_with_length' - it's the implementation not the interface.
<br>
<br>&gt; They point to different things if y is an auto_ptr.
<br>
<br>I'd forgotten about auto_ptr, but since it is deprecated, it's largely
<br>irrelevant. I think everyone agrees that auto_ptr is not an example of
<br>good design. IMO it actually supports my principle. The problem with
<br>auto_ptr is that it doesn't follow the expected semantics.
<br>
<br>&gt; So there are
<br>&gt; already exceptions
<br>&gt; to this alleged rule, and chances are there's more exceptions comi=
ng.
<br>
<br>IMO there shouldn't be. Thanks to templates, C++ has an odd mix of
<br>structural and nominal typing. So when you have a type structure the
<br>implies a certain behaviour, it means something. I don't think saving
<br>a few characters is a good reason to break that. Anyone who does think
<br>that it is should at least acknowledge that there is a trade off here.
<br></blockquote><div><br>This is how i see it. We all first learned how a =
raw pointer works, and we keep in mind all its semantics. Then, we get shar=
ed_ptr, and it is different than a raw pointer, but it is still significant=
ly similar, that we can still call it a pointer. Then, we have unique_ptr, =
which is even more different. For instance, your example:<br><br>&nbsp;&nbs=
p;&nbsp; auto x =3D y;
<br>&nbsp; &nbsp; *x =3D 2;
<br><br>fails to compile if y is a unique_ptr. But it can still be thought =
of as a pointer, because parts of the reasoning for raw pointers still appl=
ies to unique_ptr. Now, optional is even less similar to a pointer, but it =
still has some similarities. And there is enough similarities to have some =
algorithms work both on pointers and optional. During these discussions I w=
as already able to identify at least four algorithms:<br><br><div class=3D"=
prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break=
-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// Not entirely C++ syntax=
, but you get the idea</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> less_pointees</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">N=
ullableProxy</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">NullableProxy</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">y</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">?</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">false<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">:(!</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">?</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">true</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">x </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> equal_pointees</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">NullableProxy</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">NullableProxy</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">bool</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">?</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">false</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">bool</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">false</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">?</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">true</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">x </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> get_value_or</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">NullableProxy</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> np</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> U </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> val</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">np</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">?</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">np </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> val</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// + forward/move</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> to_pointer</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
NullableProxy</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> np</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">bool</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">np</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> addressof</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">np</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">n=
ullptr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> less_value</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">NullableProxy</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">const</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> U </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(!</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">true</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Thus, =
because Identifying the common parts is useful, it is beneficial to identif=
y what aspects of pointers are relevant for "abstracting" type requirements=
 NullableProxy, and which aren't. And conversely, there are some aspects of=
 pointer semantics that are irrelevant (and can be dropped) when abstractin=
g the concept. We need operator* to express algorithms common to NullablePr=
ioxy concepts, but we are only interested in one aspect of it: giving us th=
e reference to the hidden value (regardless of where it is located and how =
it is copied -- NullableProxies do not have to be copyable or moveable). Th=
e other parts of the semantics of pointers are dropped when abstracting. <b=
r><br>operator* offers a couple of things. I do not think there is anything=
 that requires of us are using all of its semantics. <br><br>Typically you =
would expect of operator* (for multiplication) to be commutative. Do you co=
nsider providing operator* for matrix multiplication a design error then?<b=
r><br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Some people have referred to optional as a "nullable proxy". But it
<br>isn't a proxy, it's a container (in the sense that it contains things,
<br>not in the sense of the C++ definition - although it should be, for
<br>things like flatMap).
<br></blockquote>

<p></p>

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

------=_Part_67_14748196.1359367315941--

.

On Mon, Jan 28, 2013 at 10:07 AM, Daniel James <dnljms@gmail.com> wrote:
> On 27 January 2013 21:39, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> On Sun, Jan 27, 2013 at 9:27 PM, Daniel James <dnljms@gmail.com> wrote:
>>> But it could easily be changed to meet them. 'Optional' is a container
>>> (in the wider sense) with a maximum of 1 element. It is not in any
>>> sense a pointer. In fact, std::optional probably should meet the basic
>>> container requirements, as it would allow it to be used with generic
>>> functions.
>>
>> It's a bit like static_vector with max_size 1, true. Though I'm not
>> sure what supporting a container interface really buys you.
>
> It depends on how well the range algorithms works out. They might
> provide a more elegant way to manipulate optionals than if statements,
> similar to how a range algorithm can be more elegant than a for loop.
> This has worked out well in other languages, for example in Scala:

Wouldn't this be better handled by a wrapper that allows optionals,
(smart) pointers and references to be handled as ranges?
Separation of concerns says this shouldn't be handled by optional itself.



--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Fri, Jan 25, 2013 at 6:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> Is there a difference between empty and null?
>
>
> Yes: `optional<T*>` exists. Such an object has 3 possible states: the
> optional could be empty. The optional could contain a valid pointer. Or the
> optional could contain nullptr.
>
> That's why we should not consider them the same. To me, "null" means "a
> pointer which has no value and cannot be derefenced". If you say that an
> `optional<T*>` is "null", my assumption is that you're talking about what is
> stored within the optional and not the state of the optional itself.
>

Same problem with "empty" and optional<vector<int>>.  Which is empty,
the optional or the inner container?

Maybe a better term is "nonvalue" or notavalue or something.  Or
always say "disengaged".  But should "nullopt" be called something
else?

Tony

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 28 January 2013 10:01, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
>
> This is how i see it. We all first learned how a raw pointer works, and w=
e
> keep in mind all its semantics. Then, we get shared_ptr, and it is differ=
ent
> than a raw pointer, but it is still significantly similar, that we can st=
ill
> call it a pointer. Then, we have unique_ptr, which is even more different=
..
> For instance, your example:
>
>
>     auto x =3D y;
>     *x =3D 2;
>
> fails to compile if y is a unique_ptr.

Failing to compile is fine. If a class doesn't meet the expected
behaviour, then that's the best thing to do.

> And there is enough similarities to have some
> algorithms work both on pointers and optional. During these discussions I
> was already able to identify at least four algorithms:

> auto less_pointees(NullableProxy const& x, NullableProxy const& y)
> auto equal_pointees(NullableProxy const& x, NullableProxy const& y)

These operations are supported by ranges. And are of limited value for
pointers. (Also, of course, proxies don't have pointees, pointers do).

> auto get_value_or(NullableProxy && np, U && val)
> auto to_pointer(NullableProxy && np)

Calling these "algorithms" is certainly stretching the term, providing
a utility to do this for both optionals and pointers is pretty
trivial. There's no need for them to be generic in the manner that
'transform' is. Also, 'to_pointer' is perhaps too easy to confuse with
'get_pointer'. I'm really not convinced.

> auto less_value(NullableProxy const& x, U && y)

Isn't this just 'less_pointees' with a cast?

> Thus, because Identifying the common parts is useful, it is beneficial to
> identify what aspects of pointers are relevant for "abstracting" type
> requirements NullableProxy, and which aren't. And conversely, there are s=
ome
> aspects of pointer semantics that are irrelevant (and can be dropped) whe=
n
> abstracting the concept.

Just identifying common parts is not sufficiently useful. It has to be
done for a good reason. Otherwise this is premature generalization,
which can lead to unnecessary complexity.

> We need operator* to express algorithms common to
> NullablePrioxy concepts, but we are only interested in one aspect of it:
> giving us the reference to the hidden value (regardless of where it is
> located and how it is copied -- NullableProxies do not have to be copyabl=
e
> or moveable). The other parts of the semantics of pointers are dropped wh=
en
> abstracting.

You don't *need* operator* for anything, you just want it. The problem
is you can't just drop copying, it's just too easy to use it and
expect it to do the predictable thing without realising that you've
done that.

> Typically you would expect of operator* (for multiplication) to be
> commutative. Do you consider providing operator* for matrix multiplicatio=
n a
> design error then?

Not at all, matrix multiplication has a long and well established
history. That's very important and should be respected. Optional as a
pointer does not. It's just a cheap way to avoid typing 5 characters.

I'm also have no problem with using 'operator/' with paths, as you're
not going to mix it up with numerical division. And for a similar
reason, I don't have a problem with the use of 'operator|' for
'piping' ranges. Matrices are perhaps a bit more likely to be mixed up
with numbers, but if they are, then I think it would usually caught be
by the type system. And it's unlikely to lead to the subtle bugs that
can happen when mixing up reference and value types.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On 28 January 2013 10:08, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 10:07 AM, Daniel James <dnljms@gmail.com> wrote:
>>
>> It depends on how well the range algorithms works out. They might
>> provide a more elegant way to manipulate optionals than if statements,
>> similar to how a range algorithm can be more elegant than a for loop.
>> This has worked out well in other languages, for example in Scala:
>
> Wouldn't this be better handled by a wrapper that allows optionals,
> (smart) pointers and references to be handled as ranges?
> Separation of concerns says this shouldn't be handled by optional itself.

Fair enough. I find that such separation of concerns can end up with
unwieldy interfaces, but that's a matter of opinion.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Mon, Jan 28, 2013 at 8:54 PM, Daniel James <dnljms@gmail.com> wrote:
> On 28 January 2013 10:08, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> On Mon, Jan 28, 2013 at 10:07 AM, Daniel James <dnljms@gmail.com> wrote:
>>>
>>> It depends on how well the range algorithms works out. They might
>>> provide a more elegant way to manipulate optionals than if statements,
>>> similar to how a range algorithm can be more elegant than a for loop.
>>> This has worked out well in other languages, for example in Scala:
>>
>> Wouldn't this be better handled by a wrapper that allows optionals,
>> (smart) pointers and references to be handled as ranges?
>> Separation of concerns says this shouldn't be handled by optional itself.
>
> Fair enough. I find that such separation of concerns can end up with
> unwieldy interfaces, but that's a matter of opinion.

We can't add a range interface to raw pointers anyway, right?
--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 28 January 2013 20:10, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 8:54 PM, Daniel James <dnljms@gmail.com> wrote:
>> On 28 January 2013 10:08, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> On Mon, Jan 28, 2013 at 10:07 AM, Daniel James <dnljms@gmail.com> wrote:
>>>>
>>>> It depends on how well the range algorithms works out. They might
>>>> provide a more elegant way to manipulate optionals than if statements,
>>>> similar to how a range algorithm can be more elegant than a for loop.
>>>> This has worked out well in other languages, for example in Scala:
>>>
>>> Wouldn't this be better handled by a wrapper that allows optionals,
>>> (smart) pointers and references to be handled as ranges?
>>> Separation of concerns says this shouldn't be handled by optional itself.
>>
>> Fair enough. I find that such separation of concerns can end up with
>> unwieldy interfaces, but that's a matter of opinion.
>
> We can't add a range interface to raw pointers anyway, right?

I don't want to add a range interface to raw pointers.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_1570_33137816.1359454682676
Content-Type: text/plain; charset=ISO-8859-1

There is 2 ways to represent wether we have a value or not:
- a container with 0 or 1 element
- a pointer, either null or valid.

The both have valid yet incompatible use cases, for instance:
- the container-like representation for 0..1 could be promoted to 0..n
- the pointer-like representation could be promoted to unique_ptr if the
size of the object grows to the point where having unused memory space
would be just a waste.

If it doesn't make sense to have both representations in the same type (and
I believe it doesn"t), I wouldn't  mind having two types with distinct,
unambiguous definitions.
I find the current definition of optional somewhat difficult to understand
as "optional" suggests 0 or 1, while it is defined as "a nullable type T
that can store in its storage space either a value of type T or a special
value nullopt". And, btw, if I understand the technical argument about "why
not nullptr", I do not feel confortable about having a pointer like
interface not capable to compare to nullptr.

Regards,
Vincent


On Monday, January 28, 2013 9:27:06 PM UTC+1, Daniel James wrote:
>
> On 28 January 2013 20:10, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> > On Mon, Jan 28, 2013 at 8:54 PM, Daniel James <dnl...@gmail.com<javascript:>>
> wrote:
> >> On 28 January 2013 10:08, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> >>> On Mon, Jan 28, 2013 at 10:07 AM, Daniel James <dnl...@gmail.com<javascript:>>
> wrote:
> >>>>
> >>>> It depends on how well the range algorithms works out. They might
> >>>> provide a more elegant way to manipulate optionals than if
> statements,
> >>>> similar to how a range algorithm can be more elegant than a for loop.
> >>>> This has worked out well in other languages, for example in Scala:
> >>>
> >>> Wouldn't this be better handled by a wrapper that allows optionals,
> >>> (smart) pointers and references to be handled as ranges?
> >>> Separation of concerns says this shouldn't be handled by optional
> itself.
> >>
> >> Fair enough. I find that such separation of concerns can end up with
> >> unwieldy interfaces, but that's a matter of opinion.
> >
> > We can't add a range interface to raw pointers anyway, right?
>
> I don't want to add a range interface to raw pointers.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<div>There is 2 ways to represent wether we have a value or not:</div><div>=
- a container with 0 or 1 element</div><div>- a pointer, either null or val=
id.</div><br>The both have valid yet incompatible use cases, for instance:<=
div>- the container-like representation for 0..1 could be promoted to 0..n&=
nbsp;</div><div>- the pointer-like representation could be promoted to uniq=
ue_ptr if the size of the object grows to the point where having unused mem=
ory space would be just a waste.<br></div><div><br></div><div>If it doesn't=
 make sense to have both representations in the same type (and I believe it=
 doesn"t), I wouldn't &nbsp;mind having two types with distinct, unambiguou=
s definitions.</div><div>I find the current definition of optional somewhat=
 difficult to understand as "optional" suggests 0 or 1, while it is defined=
 as "a nullable type T that can store in its storage space either a value o=
f type T or a special value nullopt". And, btw, if I understand the technic=
al argument about "why not nullptr", I do not feel confortable about having=
 a pointer like interface not capable to compare to nullptr.</div><div><br>=
</div><div>Regards,</div><div>Vincent</div><div><br><br>On Monday, January =
28, 2013 9:27:06 PM UTC+1, Daniel James wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On 28 January 2013 20:10, Olaf van der Spek &lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"W7K3ykDCr4IJ">olafv=
....@gmail.com</a>&gt; wrote:
<br>&gt; On Mon, Jan 28, 2013 at 8:54 PM, Daniel James &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"W7K3ykDCr4IJ">dnl...@gma=
il.com</a>&gt; wrote:
<br>&gt;&gt; On 28 January 2013 10:08, Olaf van der Spek &lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"W7K3ykDCr4IJ">olafv...=
@gmail.com</a>&gt; wrote:
<br>&gt;&gt;&gt; On Mon, Jan 28, 2013 at 10:07 AM, Daniel James &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"W7K3ykDCr4IJ">d=
nl...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt; It depends on how well the range algorithms works out.=
 They might
<br>&gt;&gt;&gt;&gt; provide a more elegant way to manipulate optionals tha=
n if statements,
<br>&gt;&gt;&gt;&gt; similar to how a range algorithm can be more elegant t=
han a for loop.
<br>&gt;&gt;&gt;&gt; This has worked out well in other languages, for examp=
le in Scala:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Wouldn't this be better handled by a wrapper that allows o=
ptionals,
<br>&gt;&gt;&gt; (smart) pointers and references to be handled as ranges?
<br>&gt;&gt;&gt; Separation of concerns says this shouldn't be handled by o=
ptional itself.
<br>&gt;&gt;
<br>&gt;&gt; Fair enough. I find that such separation of concerns can end u=
p with
<br>&gt;&gt; unwieldy interfaces, but that's a matter of opinion.
<br>&gt;
<br>&gt; We can't add a range interface to raw pointers anyway, right?
<br>
<br>I don't want to add a range interface to raw pointers.
<br></blockquote></div>

<p></p>

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

------=_Part_1570_33137816.1359454682676--

.

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



W dniu wtorek, 29 stycznia 2013 11:18:02 UTC+1 u=BFytkownik Vincent Jacquet=
=20
napisa=B3:
>
> There is 2 ways to represent wether we have a value or not:
> - a container with 0 or 1 element
> - a pointer, either null or valid.
>
> The both have valid yet incompatible use cases, for instance:
> - the container-like representation for 0..1 could be promoted to 0..n=20
> - the pointer-like representation could be promoted to unique_ptr if the=
=20
> size of the object grows to the point where having unused memory space=20
> would be just a waste.
>
> If it doesn't make sense to have both representations in the same type=20
> (and I believe it doesn"t), I wouldn't  mind having two types with=20
> distinct, unambiguous definitions.
> I find the current definition of optional somewhat difficult to understan=
d=20
> as "optional" suggests 0 or 1, while it is defined as "a nullable type T=
=20
> that can store in its storage space either a value of type T or a special=
=20
> value nullopt". And, btw, if I understand the technical argument about "w=
hy=20
> not nullptr", I do not feel confortable about having a pointer like=20
> interface not capable to compare to nullptr.
>
=20
I agree with some of the observations, especially with the nullptr one.=20
However having two types for almost the same thing has a fundamental=20
problem.

Note that the primary purpose of optional<T> is to (1) answer the question=
=20
"do you have the value or not?" and if answer is "I have", (2) to give us=
=20
this value. Other aspects are secondary (although not unimportant). This is=
=20
why I say "two types for almost the same thing".

If we did this, some people would return one type from their functions,=20
some other people would be returning the other, and their code would be=20
incompatible (explicit conversion would not fix it, and it might add a=20
performance hit). For similar reasons, the deleter type of shared_ptr is=20
erased. The goal of the standard is to have one common interface for=20
everybody (rather than everyone coming with their own interface for almost=
=20
the same thing.)

--=20

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



------=_Part_291_10214938.1359459054222
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 11:18:02 UTC+1 u=BFytkownik Vincent=
 Jacquet napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>There =
is 2 ways to represent wether we have a value or not:</div><div>- a contain=
er with 0 or 1 element</div><div>- a pointer, either null or valid.</div><b=
r>The both have valid yet incompatible use cases, for instance:<div>- the c=
ontainer-like representation for 0..1 could be promoted to 0..n&nbsp;</div>=
<div>- the pointer-like representation could be promoted to unique_ptr if t=
he size of the object grows to the point where having unused memory space w=
ould be just a waste.<br></div><div><br></div><div>If it doesn't make sense=
 to have both representations in the same type (and I believe it doesn"t), =
I wouldn't &nbsp;mind having two types with distinct, unambiguous definitio=
ns.</div><div>I find the current definition of optional somewhat difficult =
to understand as "optional" suggests 0 or 1, while it is defined as "a null=
able type T that can store in its storage space either a value of type T or=
 a special value nullopt". And, btw, if I understand the technical argument=
 about "why not nullptr", I do not feel confortable about having a pointer =
like interface not capable to compare to nullptr.</div></blockquote><div>&n=
bsp;<br>I agree with some of the observations, especially with the nullptr =
one. However having two types for almost the same thing has a fundamental p=
roblem.<br><br>Note that the primary purpose of optional&lt;T&gt; is to (1)=
 answer the question "do you have the value or not?" and if answer is "I ha=
ve", (2) to give us this value. Other aspects are secondary (although not u=
nimportant). This is why I say "two types for almost the same thing".<br><b=
r>If we did this, some people would return one type from their functions, s=
ome other people would be returning the other, and their code would be inco=
mpatible (explicit conversion would not fix it, and it might add a performa=
nce hit). For similar reasons, the deleter type of shared_ptr is erased. Th=
e goal of the standard is to have one common interface for everybody (rathe=
r than everyone coming with their own interface for almost the same thing.)=
<br></div>

<p></p>

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

------=_Part_291_10214938.1359459054222--

.

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

I agree, I simply wanted to investigate this possibility for the sake of=20
completness.=20

I find the definition of optional<T> you gave above much clearer and=20
simpler than the one introducting your proposal. Also, interrestingly, it=
=20
doesn't mention a nullable type anymore.

Thanks,
Vincent

On Tuesday, January 29, 2013 12:30:54 PM UTC+1, Andrzej Krzemie=F1ski wrote=
:
>
>
>
> W dniu wtorek, 29 stycznia 2013 11:18:02 UTC+1 u=BFytkownik Vincent Jacqu=
et=20
> napisa=B3:
>>
>> There is 2 ways to represent wether we have a value or not:
>> - a container with 0 or 1 element
>> - a pointer, either null or valid.
>>
>> The both have valid yet incompatible use cases, for instance:
>> - the container-like representation for 0..1 could be promoted to 0..n=
=20
>> - the pointer-like representation could be promoted to unique_ptr if the=
=20
>> size of the object grows to the point where having unused memory space=
=20
>> would be just a waste.
>>
>> If it doesn't make sense to have both representations in the same type=
=20
>> (and I believe it doesn"t), I wouldn't  mind having two types with=20
>> distinct, unambiguous definitions.
>> I find the current definition of optional somewhat difficult to=20
>> understand as "optional" suggests 0 or 1, while it is defined as "a=20
>> nullable type T that can store in its storage space either a value of ty=
pe=20
>> T or a special value nullopt". And, btw, if I understand the technical=
=20
>> argument about "why not nullptr", I do not feel confortable about having=
 a=20
>> pointer like interface not capable to compare to nullptr.
>>
> =20
> I agree with some of the observations, especially with the nullptr one.=
=20
> However having two types for almost the same thing has a fundamental=20
> problem.
>
> Note that the primary purpose of optional<T> is to (1) answer the questio=
n=20
> "do you have the value or not?" and if answer is "I have", (2) to give us=
=20
> this value. Other aspects are secondary (although not unimportant). This =
is=20
> why I say "two types for almost the same thing".
>
> If we did this, some people would return one type from their functions,=
=20
> some other people would be returning the other, and their code would be=
=20
> incompatible (explicit conversion would not fix it, and it might add a=20
> performance hit). For similar reasons, the deleter type of shared_ptr is=
=20
> erased. The goal of the standard is to have one common interface for=20
> everybody (rather than everyone coming with their own interface for almos=
t=20
> the same thing.)
>

--=20

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



------=_Part_2508_20660289.1359477040002
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

I agree, I simply wanted to investigate this possibility for the sake of co=
mpletness.&nbsp;<div><br></div><div>I find the definition of optional&lt;T&=
gt; you gave above much clearer and simpler than the one introducting your =
proposal. Also, interrestingly, it doesn't mention a nullable type anymore.=
</div><div><br></div><div>Thanks,</div><div>Vincent</div><div><br>On Tuesda=
y, January 29, 2013 12:30:54 PM UTC+1, Andrzej Krzemie=F1ski wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><br><br>W dniu wtorek, 29 stycznia 201=
3 11:18:02 UTC+1 u=BFytkownik Vincent Jacquet napisa=B3:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div>There is 2 ways to represent wether we have a v=
alue or not:</div><div>- a container with 0 or 1 element</div><div>- a poin=
ter, either null or valid.</div><br>The both have valid yet incompatible us=
e cases, for instance:<div>- the container-like representation for 0..1 cou=
ld be promoted to 0..n&nbsp;</div><div>- the pointer-like representation co=
uld be promoted to unique_ptr if the size of the object grows to the point =
where having unused memory space would be just a waste.<br></div><div><br><=
/div><div>If it doesn't make sense to have both representations in the same=
 type (and I believe it doesn"t), I wouldn't &nbsp;mind having two types wi=
th distinct, unambiguous definitions.</div><div>I find the current definiti=
on of optional somewhat difficult to understand as "optional" suggests 0 or=
 1, while it is defined as "a nullable type T that can store in its storage=
 space either a value of type T or a special value nullopt". And, btw, if I=
 understand the technical argument about "why not nullptr", I do not feel c=
onfortable about having a pointer like interface not capable to compare to =
nullptr.</div></blockquote><div>&nbsp;<br>I agree with some of the observat=
ions, especially with the nullptr one. However having two types for almost =
the same thing has a fundamental problem.<br><br>Note that the primary purp=
ose of optional&lt;T&gt; is to (1) answer the question "do you have the val=
ue or not?" and if answer is "I have", (2) to give us this value. Other asp=
ects are secondary (although not unimportant). This is why I say "two types=
 for almost the same thing".<br><br>If we did this, some people would retur=
n one type from their functions, some other people would be returning the o=
ther, and their code would be incompatible (explicit conversion would not f=
ix it, and it might add a performance hit). For similar reasons, the delete=
r type of shared_ptr is erased. The goal of the standard is to have one com=
mon interface for everybody (rather than everyone coming with their own int=
erface for almost the same thing.)<br></div></blockquote></div>

<p></p>

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

------=_Part_2508_20660289.1359477040002--

.

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



W dniu wtorek, 29 stycznia 2013 17:30:39 UTC+1 u=BFytkownik Vincent Jacquet=
=20
napisa=B3:
>
> I agree, I simply wanted to investigate this possibility for the sake of=
=20
> completness.=20
>
> I find the definition of optional<T> you gave above much clearer and=20
> simpler than the one introducting your proposal. Also, interrestingly, it=
=20
> doesn't mention a nullable type anymore.
>

:) We will update the documentation, so that it is more clear. This=20
discussion also helps us determine, what is "obvious" to the majority and=
=20
what needs to be explained.=20

Regards,
&rzej

--=20

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



------=_Part_234_32181126.1359477495793
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 17:30:39 UTC+1 u=BFytkownik Vincent=
 Jacquet napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I agree, I =
simply wanted to investigate this possibility for the sake of completness.&=
nbsp;<div><br></div><div>I find the definition of optional&lt;T&gt; you gav=
e above much clearer and simpler than the one introducting your proposal. A=
lso, interrestingly, it doesn't mention a nullable type anymore.</div></blo=
ckquote><div><br>:) We will update the documentation, so that it is more cl=
ear. This discussion also helps us determine, what is "obvious" to the majo=
rity and what needs to be explained. <br><br>Regards,<br>&amp;rzej<br></div=
>

<p></p>

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

------=_Part_234_32181126.1359477495793--

.