--20cf30050e8a37ea8b04d4923fef
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 30 January 2013 10:39, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:

>
> Now I start to understand something (which was probably obvious to
> others): with optional we are proposing two opposite features: (1) an
> "improved NaN" and (2) "just another value of T".


There aren't just two things that optional models; there are many.  A few
off the top of my head:

nullable<T>
regular<T> // if T is regular
one_more_state<T>
variant<blank, T>
sequence_container<T> // assert(size() <=3D1
boost::optional<T>
similar feature in other languages
optional proposal in Portland
how does it fit in with the rest of the standard library

And they are all valid and set expectations, because at the end of the day,
users will only be looking at the interface and semantics provided by the
standard, with the actual proposal only being a curiosity.

For instance, if we were to use sequence_container<T>, then both an "empty"
optional is the same as an empty vector in the sense that it sorts less
than a container with one element and <, >, =3D=3D, !=3D, <=3D and >=3D are=
 all well
defined on it (if they are well defined on T).  Heck, that's about how
almost every (if not all) other value types in the standard library work.
 Do people really consider this generally a problem for the other types in
the standard library (I certainly don't)?  If not, why is optional so
special here?

For the record, I am strongly for a disengaged optional to be less than an
engaged optional, and =3D=3D, !=3D, <, >, <=3D, >=3D to all be well defined=
 (when
they are well defined for T) for direct comparison.  I'm also for defining
all comparisons between optional<T> and T.


The job of the committee is to evaluate (not design) a proposal on
soundness, usefulness and, as Bjarne has been drilling into us in EWG, how
it fits in with the rest of the language.  Also, consensus !=3D unanimous.

Make strong choices  When you make weak choices, you are both trying to
defer design to the committee, as well as hinting that the feature may not
be ready for prime time, which is ridiculous for a library that has been
happily in use for almost a decade.  If the committee thinks you got it
wrong, believe me, they'll let you know.  Both the standard library and
boost::optional have tons of user experience; leverage it; don't try to
design around it.


I want this library.  Yet as a committee member, I will be looking at
soundness, the interface as compared with the rest of the standard library,
and whether or not I want to change my code bases to use std::optional or
just stick with boost::optional because it has a better interface.  I was
strongly in favor of the proposal in Portland.  After this ongoing
discussion, I cannot say that about this version, and that really saddens
me, because if the three points above aren't met, I'll have to vote
strongly against.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

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



--20cf30050e8a37ea8b04d4923fef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 30 January 2013 10:39, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">

<br>Now I start to understand something (which was probably obvious to othe=
rs): with optional we are proposing two opposite features: (1) an &quot;imp=
roved NaN&quot; and (2) &quot;just another value of T&quot;.</blockquote>

<div><br></div><div>There aren&#39;t just two things that optional models; =
there are many. =C2=A0A few off the top of my head:</div><div><br></div><di=
v>nullable&lt;T&gt;<br>regular&lt;T&gt; // if T is regular<br>one_more_stat=
e&lt;T&gt;<br>

variant&lt;blank, T&gt;<br>sequence_container&lt;T&gt; // assert(size() &lt=
;=3D1</div><div>boost::optional&lt;T&gt;</div><div>similar feature in other=
 languages</div><div>optional proposal in Portland</div><div>how does it fi=
t in with the rest of the standard library</div>

<div><br></div><div>And they are all valid and set expectations, because at=
 the end of the day, users will only be looking at the interface and semant=
ics provided by the standard, with the actual proposal only being a curiosi=
ty.</div>

<div><br></div><div>For instance, if we were to use sequence_container&lt;T=
&gt;, then both an &quot;empty&quot; optional is the same as an empty vecto=
r in the sense that it sorts less than a container with one element and &lt=
;, &gt;, =3D=3D, !=3D, &lt;=3D and &gt;=3D are all well defined on it (if t=
hey are well defined on T). =C2=A0Heck, that&#39;s about how almost every (=
if not all) other value types in the standard library work. =C2=A0Do people=
 really consider this generally a problem for the other types in the standa=
rd library (I certainly don&#39;t)? =C2=A0If not, why is optional so specia=
l here?</div>

<div><br></div><div>For the record, I am strongly for a disengaged optional=
 to be less than an engaged optional, and =3D=3D, !=3D, &lt;, &gt;, &lt;=3D=
, &gt;=3D to all be well defined (when they are well defined for T) for dir=
ect comparison. =C2=A0I&#39;m also for defining all comparisons between opt=
ional&lt;T&gt; and T.</div>

<div><br></div><div><br></div><div>The job of the committee is to evaluate =
(not design) a proposal on soundness, usefulness and, as Bjarne has been dr=
illing into us in EWG, how it fits in with the rest of the language. =C2=A0=
Also, consensus !=3D unanimous.</div>

<div><br></div><div>Make strong choices =C2=A0When you make weak choices, y=
ou are both trying to defer design to the committee, as well as hinting tha=
t the feature may not be ready for prime time, which is ridiculous for a li=
brary that has been happily in use for almost a decade. =C2=A0If the commit=
tee thinks you got it wrong, believe me, they&#39;ll let you know. =C2=A0Bo=
th the standard library and boost::optional have tons of user experience; l=
everage it; don&#39;t try to design around it.</div>

<div><br></div><div><br></div><div>I want this library. =C2=A0Yet as a comm=
ittee member, I will be looking at soundness, the interface as compared wit=
h the rest of the standard library, and whether or not I want to change my =
code bases to use std::optional or just stick with boost::optional because =
it has a better interface. =C2=A0I was strongly in favor of the proposal in=
 Portland. =C2=A0After this ongoing discussion, I cannot say that about thi=
s version, and that really saddens me, because if the three points above ar=
en&#39;t met, I&#39;ll have to vote strongly against.</div>

</div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=C2=A0 (847) 691-1404

<p></p>

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

--20cf30050e8a37ea8b04d4923fef--

.

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



W dniu czwartek, 31 stycznia 2013 10:27:36 UTC+1 u=BFytkownik Nevin ":-)"=
=20
Liber napisa=B3:
>
> On 30 January 2013 10:39, Andrzej Krzemie=F1ski <akrz...@gmail.com<javasc=
ript:>
> > wrote:
>
>>
>> Now I start to understand something (which was probably obvious to=20
>> others): with optional we are proposing two opposite features: (1) an=20
>> "improved NaN" and (2) "just another value of T".
>
>
> There aren't just two things that optional models; there are many.  A few=
=20
> off the top of my head:
>
> nullable<T>
> regular<T> // if T is regular
> one_more_state<T>
> variant<blank, T>
> sequence_container<T> // assert(size() <=3D1
> boost::optional<T>
> similar feature in other languages
> optional proposal in Portland
> how does it fit in with the rest of the standard library
>
> And they are all valid and set expectations, because at the end of the=20
> day, users will only be looking at the interface and semantics provided b=
y=20
> the standard, with the actual proposal only being a curiosity.
>
> For instance, if we were to use sequence_container<T>, then both an=20
> "empty" optional is the same as an empty vector in the sense that it sort=
s=20
> less than a container with one element and <, >, =3D=3D, !=3D, <=3D and >=
=3D are all=20
> well defined on it (if they are well defined on T).  Heck, that's about h=
ow=20
> almost every (if not all) other value types in the standard library work.=
=20
>  Do people really consider this generally a problem for the other types i=
n=20
> the standard library (I certainly don't)?  If not, why is optional so=20
> special here?
>
> For the record, I am strongly for a disengaged optional to be less than a=
n=20
> engaged optional, and =3D=3D, !=3D, <, >, <=3D, >=3D to all be well defin=
ed (when=20
> they are well defined for T) for direct comparison.  I'm also for definin=
g=20
> all comparisons between optional<T> and T.
>
>
> The job of the committee is to evaluate (not design) a proposal on=20
> soundness, usefulness and, as Bjarne has been drilling into us in EWG, ho=
w=20
> it fits in with the rest of the language.  Also, consensus !=3D unanimous=
..
>
> Make strong choices  When you make weak choices, you are both trying to=
=20
> defer design to the committee, as well as hinting that the feature may no=
t=20
> be ready for prime time, which is ridiculous for a library that has been=
=20
> happily in use for almost a decade.  If the committee thinks you got it=
=20
> wrong, believe me, they'll let you know.  Both the standard library and=
=20
> boost::optional have tons of user experience; leverage it; don't try to=
=20
> design around it.
>
>
> I want this library.  Yet as a committee member, I will be looking at=20
> soundness, the interface as compared with the rest of the standard librar=
y,=20
> and whether or not I want to change my code bases to use std::optional or=
=20
> just stick with boost::optional because it has a better interface.  I was=
=20
> strongly in favor of the proposal in Portland.  After this ongoing=20
> discussion, I cannot say that about this version, and that really saddens=
=20
> me, because if the three points above aren't met, I'll have to vote=20
> strongly against.
>

I must admit I don't understand. Why did you change your mind? Is it the=20
amount of the discussions, or the contents of the two proposals?=20

Is it about the mixed relops? But it is the previous revision that was=20
poisoning them. In this revision we are considering putting them back: that=
=20
appears to be in accord with your expectations?

Is it about dropping the optional references? (we are now considering to=20
put them as an "auxiliary proposal", but within the same paper). Is this=20
what you call a "weak choice"? Would you rather that we make a call whether=
=20
to propose them or not?

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

<br><br>W dniu czwartek, 31 stycznia 2013 10:27:36 UTC+1 u=BFytkownik Nevin=
 ":-)" Liber napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 30 J=
anuary 2013 10:39, Andrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"kv4nLhYzJkAJ">akrz..=
..@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

<br>Now I start to understand something (which was probably obvious to othe=
rs): with optional we are proposing two opposite features: (1) an "improved=
 NaN" and (2) "just another value of T".</blockquote>

<div><br></div><div>There aren't just two things that optional models; ther=
e are many. &nbsp;A few off the top of my head:</div><div><br></div><div>nu=
llable&lt;T&gt;<br>regular&lt;T&gt; // if T is regular<br>one_more_state&lt=
;T&gt;<br>

variant&lt;blank, T&gt;<br>sequence_container&lt;T&gt; // assert(size() &lt=
;=3D1</div><div>boost::optional&lt;T&gt;</div><div>similar feature in other=
 languages</div><div>optional proposal in Portland</div><div>how does it fi=
t in with the rest of the standard library</div>

<div><br></div><div>And they are all valid and set expectations, because at=
 the end of the day, users will only be looking at the interface and semant=
ics provided by the standard, with the actual proposal only being a curiosi=
ty.</div>

<div><br></div><div>For instance, if we were to use sequence_container&lt;T=
&gt;, then both an "empty" optional is the same as an empty vector in the s=
ense that it sorts less than a container with one element and &lt;, &gt;, =
=3D=3D, !=3D, &lt;=3D and &gt;=3D are all well defined on it (if they are w=
ell defined on T). &nbsp;Heck, that's about how almost every (if not all) o=
ther value types in the standard library work. &nbsp;Do people really consi=
der this generally a problem for the other types in the standard library (I=
 certainly don't)? &nbsp;If not, why is optional so special here?</div>

<div><br></div><div>For the record, I am strongly for a disengaged optional=
 to be less than an engaged optional, and =3D=3D, !=3D, &lt;, &gt;, &lt;=3D=
, &gt;=3D to all be well defined (when they are well defined for T) for dir=
ect comparison. &nbsp;I'm also for defining all comparisons between optiona=
l&lt;T&gt; and T.</div>

<div><br></div><div><br></div><div>The job of the committee is to evaluate =
(not design) a proposal on soundness, usefulness and, as Bjarne has been dr=
illing into us in EWG, how it fits in with the rest of the language. &nbsp;=
Also, consensus !=3D unanimous.</div>

<div><br></div><div>Make strong choices &nbsp;When you make weak choices, y=
ou are both trying to defer design to the committee, as well as hinting tha=
t the feature may not be ready for prime time, which is ridiculous for a li=
brary that has been happily in use for almost a decade. &nbsp;If the commit=
tee thinks you got it wrong, believe me, they'll let you know. &nbsp;Both t=
he standard library and boost::optional have tons of user experience; lever=
age it; don't try to design around it.</div>

<div><br></div><div><br></div><div>I want this library. &nbsp;Yet as a comm=
ittee member, I will be looking at soundness, the interface as compared wit=
h the rest of the standard library, and whether or not I want to change my =
code bases to use std::optional or just stick with boost::optional because =
it has a better interface. &nbsp;I was strongly in favor of the proposal in=
 Portland. &nbsp;After this ongoing discussion, I cannot say that about thi=
s version, and that really saddens me, because if the three points above ar=
en't met, I'll have to vote strongly against.</div></div></blockquote><div>=
<br></div><div>I must admit I don't understand. Why did you change your min=
d? Is it the amount of the discussions, or the contents of the two proposal=
s?&nbsp;</div><div><br></div><div>Is it about the mixed relops? But it is t=
he previous revision that was poisoning them. In this revision we are consi=
dering putting them back: that appears to be in accord with your expectatio=
ns?</div><div><br></div><div>Is it about dropping the optional references? =
(we are now considering to put them as an "auxiliary proposal", but within =
the same paper). Is this what you call a "weak choice"? Would you rather th=
at we make a call whether to propose them or not?</div><div><br></div><div>=
Regards,</div><div>&amp;rzej</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_797_17092015.1359643953324--

.

------=_Part_837_27475076.1359645371795
Content-Type: text/plain; charset=ISO-8859-1

Op donderdag 31 januari 2013 10:27:36 UTC+1 schreef Nevin ":-)" Liber het
volgende:

> For the record, I am strongly for a disengaged optional to be less than an
> engaged optional, and ==, !=, <, >, <=, >= to all be well defined (when
> they are well defined for T) for direct comparison.  I'm also for defining
> all comparisons between optional<T> and T.
>

Then maybe you should address the concerns others have.

optional<int> is quite like int* if we consider the const interface. Both
are empty/null or have a value. Yet you can't compare int* with int
directly. You also either compare the pointers or the pointees, not both at
the same time.

--

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

Op donderdag 31 januari 2013 10:27:36 UTC+1 schreef Nevin ":-)" Liber het v=
olgende:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmai=
l_quote"><div>For the record, I am strongly for a disengaged optional to be=
 less than an engaged optional, and =3D=3D, !=3D, &lt;, &gt;, &lt;=3D, &gt;=
=3D to all be well defined (when they are well defined for T) for direct co=
mparison. &nbsp;I'm also for defining all comparisons between optional&lt;T=
&gt; and T.</div></div></blockquote><div><br></div><div>Then maybe you shou=
ld address the concerns others have.</div><div><br></div><div>optional&lt;i=
nt&gt; is quite like int* if we consider the const interface. Both are empt=
y/null or have a value. Yet you can't compare int* with int directly. You a=
lso either compare the pointers or the pointees, not both at the same time.=
</div><div><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_837_27475076.1359645371795--

.

On Thu, Jan 31, 2013 at 6:27 AM, Nevin Liber <nevin@eviloverlord.com> wrote=
:
> On 30 January 2013 10:39, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> w=
rote:
>>
>>
>> Now I start to understand something (which was probably obvious to
>> others): with optional we are proposing two opposite features: (1) an
>> "improved NaN" and (2) "just another value of T".
>
>
> There aren't just two things that optional models; there are many.  A few
> off the top of my head:
>
> nullable<T>
> regular<T> // if T is regular
> one_more_state<T>
> variant<blank, T>
> sequence_container<T> // assert(size() <=3D1
> boost::optional<T>
> similar feature in other languages
> optional proposal in Portland
> how does it fit in with the rest of the standard library
>

Or, like I like to say, std::optional<>

There is a value in drawing an analogy to something else when
describing, explaining, analyzing, etc..  but what is a mistake IMO is
to allow those analogies to force a design.

> And they are all valid and set expectations, because at the end of the da=
y,
> users will only be looking at the interface and semantics provided by the
> standard, with the actual proposal only being a curiosity.
>
Exactly

> For instance, if we were to use sequence_container<T>, then both an "empt=
y"
> optional is the same as an empty vector in the sense that it sorts less t=
han
> a container with one element and <, >, =3D=3D, !=3D, <=3D and >=3D are al=
l well
> defined on it (if they are well defined on T).  Heck, that's about how
> almost every (if not all) other value types in the standard library work.
> Do people really consider this generally a problem for the other types in
> the standard library (I certainly don't)?  If not, why is optional so
> special here?
>
> For the record, I am strongly for a disengaged optional to be less than a=
n
> engaged optional, and =3D=3D, !=3D, <, >, <=3D, >=3D to all be well defin=
ed (when they
> are well defined for T) for direct comparison.  I'm also for defining all
> comparisons between optional<T> and T.
>
+1

>
> The job of the committee is to evaluate (not design) a proposal on
> soundness, usefulness and, as Bjarne has been drilling into us in EWG, ho=
w
> it fits in with the rest of the language.  Also, consensus !=3D unanimous=
..
>
> Make strong choices  When you make weak choices, you are both trying to
> defer design to the committee, as well as hinting that the feature may no=
t
> be ready for prime time, which is ridiculous for a library that has been
> happily in use for almost a decade.  If the committee thinks you got it
> wrong, believe me, they'll let you know.  Both the standard library and
> boost::optional have tons of user experience; leverage it; don't try to
> design around it.
>
OK

We'll make sure in the proposal that is clear that there is *one*
single thing that we propose (well, at least there is one single thing
*I* propose, and I'll see to converge with Andrzej on that)

But we'll also make it clear that we believe is important that the
proposal is accepted, so we are willing to compromise on a couple of
points IFF that is required because the committee does not like what
we propose.

We have identified  what those points are based on the feedback, so
the alternative choices are there only to have a simple way to
re-design it during the meeting.

>
> I want this library.  Yet as a committee member, I will be looking at
> soundness, the interface as compared with the rest of the standard librar=
y,
> and whether or not I want to change my code bases to use std::optional or
> just stick with boost::optional because it has a better interface.  I was
> strongly in favor of the proposal in Portland.  After this ongoing
> discussion, I cannot say that about this version, and that really saddens
> me, because if the three points above aren't met, I'll have to vote stron=
gly
> against.

We'll put the mixed relops back in and only express that we would
agree to have them poisson IFF that's the decision of the committee,
even though we (well, *I*) strongly believe it would be a mistake to
do so.


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



.