I was thinking about the differences between optional<T> and
containers, ie vector<T>.

In particular that vector<T> allocates storage for its elements
whereas optional<T> has a T embedded.
And in particular, how that affects API:

- vector<T>:
- nothrow move, swap (moves/swaps pointer)
- these do NOT call T's move or swap
- move 'empties' the source vector
- etc

optional:
- must call T's move, swap, etc
- does not empty source on move

this is directly due to optional having T embedded.  So being embedded
isn't just an implementation detail - its API.  (It is also an
important characteristic for performance.)  Is it (will it be) a
*requirement*?  (obviously optional doesn't take an allocator, so it
shouldn't be allocating)


I think describing optional (as in the latest rev of the proposal) as
_like_ having a T * member, causes more confusion than it is worth.
I also think trying to see optional as a 'container-of-one' is
error-prone (in the sense of causing design errors with potential
decisions on how optional should behave), since it isn't a true
analogy.


Note that *every* operation on optional<T> forwards directly to T.
The only case that doesn't *directly* forward, is assignment, as it
may actually do copy-construction if the optional wasn't already
engaged (otherwise it forwards to T's assignment).

Oh, *except* the relational operators.  <=, >, >= all forward to < and ==.
I find that just wrong.  I know it goes against containers and
pair/tuple, but, as above, I think it is wrong to think of optional as
a container.
Optional is a "T or not".

I think *not* forwarding the relational operators directly goes
against optional itself, and it is more important to be
self-consistent than consistent with other parts of std::,
particularly parts that aren't really good analogs.

Also, I think not having optional<T&> forward exactly to T& is wrong
for the same reason. (Meaning first assignment sets the reference,
subsequent ones assign through the reference, etc.)

I really would like to see optional be self-consistent, so that
instead of having a number of special rules and gotchas, the only
rules are:

- assignment: constructs T with source value if not already engaged,
else assigns T with source value
- otherwise, if engaged, does whatever T does in that situation
- mostly undefined if not engaged

Thoughts?

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 15 March 2013 07:47, Tony V E <tvaneerd@gmail.com> wrote:
> - vector<T>:
> - nothrow move, swap (moves/swaps pointer)
> - these do NOT call T's move or swap
> - move 'empties' the source vector
> - etc
> optional:
> - must call T's move, swap, etc
> - does not empty source on move
> this is directly due to optional having T embedded.  So being embedded
> isn't just an implementation detail - its API.  (It is also an

It's interesting that you use vector as a comparison, because vector's
implementation
is directly visible in its API, especially the requirements that
vector is contiguous.
Therefore I don't think it's unprecedented that an intended implementation, when
it has important physical characteristics, is reflected in the API.

> I really would like to see optional be self-consistent, so that
> instead of having a number of special rules and gotchas, the only
> rules are:
> - assignment: constructs T with source value if not already engaged,
> else assigns T with source value
> - otherwise, if engaged, does whatever T does in that situation
> - mostly undefined if not engaged

"Mostly undefined if not engaged"? Which cases are undefined? Also, is
it a gotcha
that assigning from a disengaged disengages? Because that's very
useful in practice,
even if it doesn't seem philosophically pure.

--

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



W dniu pi=B1tek, 15 marca 2013 06:47:12 UTC+1 u=BFytkownik Tony V E napisa=
=B3:
>
> I was thinking about the differences between optional<T> and=20
> containers, ie vector<T>.=20
>
> In particular that vector<T> allocates storage for its elements=20
> whereas optional<T> has a T embedded.=20
> And in particular, how that affects API:=20
>
> - vector<T>:=20
> - nothrow move, swap (moves/swaps pointer)=20
> - these do NOT call T's move or swap=20
> - move 'empties' the source vector=20
> - etc=20
>
> optional:=20
> - must call T's move, swap, etc=20
> - does not empty source on move=20
>
> this is directly due to optional having T embedded.  So being embedded=20
> isn't just an implementation detail - its API.  (It is also an=20
> important characteristic for performance.)  Is it (will it be) a=20
> *requirement*?  (obviously optional doesn't take an allocator, so it=20
> shouldn't be allocating)=20
>
>
> I think describing optional (as in the latest rev of the proposal) as=20
> _like_ having a T * member, causes more confusion than it is worth.=20
> I also think trying to see optional as a 'container-of-one' is=20
> error-prone (in the sense of causing design errors with potential=20
> decisions on how optional should behave), since it isn't a true=20
> analogy.=20
>
>
> Note that *every* operation on optional<T> forwards directly to T.=20
> The only case that doesn't *directly* forward, is assignment, as it=20
> may actually do copy-construction if the optional wasn't already=20
> engaged (otherwise it forwards to T's assignment).=20
>
> Oh, *except* the relational operators.  <=3D, >, >=3D all forward to < an=
d =3D=3D.=20
> I find that just wrong.  I know it goes against containers and=20
> pair/tuple, but, as above, I think it is wrong to think of optional as=20
> a container.=20
> Optional is a "T or not".=20
>
> I think *not* forwarding the relational operators directly goes=20
> against optional itself, and it is more important to be=20
> self-consistent than consistent with other parts of std::,=20
> particularly parts that aren't really good analogs.=20
>
> Also, I think not having optional<T&> forward exactly to T& is wrong=20
> for the same reason. (Meaning first assignment sets the reference,=20
> subsequent ones assign through the reference, etc.)=20
>
> I really would like to see optional be self-consistent, so that=20
> instead of having a number of special rules and gotchas, the only=20
> rules are:=20
>
> - assignment: constructs T with source value if not already engaged,=20
> else assigns T with source value=20
> - otherwise, if engaged, does whatever T does in that situation=20
> - mostly undefined if not engaged=20
>
> Thoughts?=20
>

I may not address all of the points you bring, but let me try to reply.=20

First, apart from "technical" goals, we also have a "political" goal for=20
Optional: we want it to gather a consensus in the Committee and be added to=
=20
C++; soon. This affects the design to significant extent. We are willing to=
=20
sacrifice some of the purity of the interface in order to make Optional=20
generally useful to many users with various views.

Yes; the contained value being embedded inside Optional's storage is part=
=20
of the API. It is even mentioned in the proposed wording: "Engaged=20
instances of optional<T> where T is of object type shall contain a value of=
=20
type T within its own storage."
You can rely on it, for instance in case you want to implement the copying=
=20
of array<optional<int>, 100> using memcpy.

I agree that using "exposition only" pointer may be confusing. On the other=
=20
hand, I am not sure how to express the requirements without it. If you have=
=20
any suggestion, it would be welcome. The wording is correct and=20
unambiguous, I think: it is just that it may confuse the reader.

Agreed that the model of 0-or-1-sized container will not do. This is why we=
=20
do not choose it. We prefer to see it as a value storing all T's + one=20
additional state (hence the mixed rel-ops) with the possibility to cast the=
=20
value back to T.

Regarding the (homogenous) relops, it is possible to implement them as just=
=20
forwarding to T. But before departing from the current practice in the=20
Library I would rather hear the direction from LWG. Can you think of any=20
practical use case where this difference (between the current proposal and=
=20
your expectation) really matters? Given the model " all T's + one=20
additional state", this difference does not appear that relevant. And also,=
=20
you get all relops for free if you only define =3D=3D and <.

Optional reference assignment is very fragile, and it is not possible to=20
get it right. Every implementation that we could think of is inconsistent=
=20
with some other aspects of the interface. Optional reference is just=20
tricky. Nonetheless the guidance from LWG was that if optional references=
=20
are there, they should have a rebinding assignment (removing optional refs=
=20
altogether is also a consistent option). At least copy ctor, assignment and=
=20
swap are consistent with themselves. And to learn its mechanics should also=
=20
be easy: if you mutate it, it rebinds; if you just read it, it behaves like=
=20
a reference.

How many *practical* gotchas of Optional can you list? My understanding=20
(apologies if it is wrong) is that you are concerned with "purity" aspects=
=20
rather gothchas that regular C++ programmers might run into.

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

<br><br>W dniu pi=B1tek, 15 marca 2013 06:47:12 UTC+1 u=BFytkownik Tony V E=
 napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I was thinking abou=
t the differences between optional&lt;T&gt; and
<br>containers, ie vector&lt;T&gt;.
<br>
<br>In particular that vector&lt;T&gt; allocates storage for its elements
<br>whereas optional&lt;T&gt; has a T embedded.
<br>And in particular, how that affects API:
<br>
<br>- vector&lt;T&gt;:
<br>- nothrow move, swap (moves/swaps pointer)
<br>- these do NOT call T's move or swap
<br>- move 'empties' the source vector
<br>- etc
<br>
<br>optional:
<br>- must call T's move, swap, etc
<br>- does not empty source on move
<br>
<br>this is directly due to optional having T embedded. &nbsp;So being embe=
dded
<br>isn't just an implementation detail - its API. &nbsp;(It is also an
<br>important characteristic for performance.) &nbsp;Is it (will it be) a
<br>*requirement*? &nbsp;(obviously optional doesn't take an allocator, so =
it
<br>shouldn't be allocating)
<br>
<br>
<br>I think describing optional (as in the latest rev of the proposal) as
<br>_like_ having a T * member, causes more confusion than it is worth.
<br>I also think trying to see optional as a 'container-of-one' is
<br>error-prone (in the sense of causing design errors with potential
<br>decisions on how optional should behave), since it isn't a true
<br>analogy.
<br>
<br>
<br>Note that *every* operation on optional&lt;T&gt; forwards directly to T=
..
<br>The only case that doesn't *directly* forward, is assignment, as it
<br>may actually do copy-construction if the optional wasn't already
<br>engaged (otherwise it forwards to T's assignment).
<br>
<br>Oh, *except* the relational operators. &nbsp;&lt;=3D, &gt;, &gt;=3D all=
 forward to &lt; and =3D=3D.
<br>I find that just wrong. &nbsp;I know it goes against containers and
<br>pair/tuple, but, as above, I think it is wrong to think of optional as
<br>a container.
<br>Optional is a "T or not".
<br>
<br>I think *not* forwarding the relational operators directly goes
<br>against optional itself, and it is more important to be
<br>self-consistent than consistent with other parts of std::,
<br>particularly parts that aren't really good analogs.
<br>
<br>Also, I think not having optional&lt;T&amp;&gt; forward exactly to T&am=
p; is wrong
<br>for the same reason. (Meaning first assignment sets the reference,
<br>subsequent ones assign through the reference, etc.)
<br>
<br>I really would like to see optional be self-consistent, so that
<br>instead of having a number of special rules and gotchas, the only
<br>rules are:
<br>
<br>- assignment: constructs T with source value if not already engaged,
<br>else assigns T with source value
<br>- otherwise, if engaged, does whatever T does in that situation
<br>- mostly undefined if not engaged
<br>
<br>Thoughts?
<br></blockquote><div><br>I may not address all of the points you bring, bu=
t let me try to reply. <br><br>First, apart from "technical" goals, we also=
 have a "political" goal for Optional: we want it to gather a consensus in =
the Committee and be added to C++; soon. This affects the design to signifi=
cant extent. We are willing to sacrifice some of the purity of the interfac=
e in order to make Optional generally useful to many users with various vie=
ws.<br><br>Yes; the contained value being embedded inside Optional's storag=
e is part of the API. It is even mentioned in the proposed wording: "Engage=
d instances of <code>optional&lt;T&gt;</code> where <code>T</code> is of ob=
ject type shall contain a value of type <code>T</code> within its own stora=
ge."<br>You can rely on it, for instance in case you want to implement the =
copying of <span style=3D"font-family: courier new,monospace;">array&lt;opt=
ional&lt;int&gt;, 100&gt;</span> using <span style=3D"font-family: courier =
new,monospace;">memcpy</span>.<br><br>I agree that using "exposition only" =
pointer may be confusing. On the other hand, I am not sure how to express t=
he requirements without it. If you have any suggestion, it would be welcome=
.. The wording is correct and unambiguous, I think: it is just that it may c=
onfuse the reader.<br><br>Agreed that the model of 0-or-1-sized container w=
ill not do. This is why we do not choose it. We prefer to see it as a value=
 storing all T's + one additional state (hence the mixed rel-ops) with the =
possibility to cast the value back to T.<br><br>Regarding the (homogenous) =
relops, it is possible to implement them as just forwarding to T. But befor=
e departing from the current practice in the Library I would rather hear th=
e direction from LWG. Can you think of any practical use case where this di=
fference (between the current proposal and your expectation) really matters=
? Given the model " all T's + one additional state", this difference does n=
ot appear that relevant. And also, you get all relops for free if you only =
define =3D=3D and &lt;.<br><br>Optional reference assignment is very fragil=
e, and it is not possible to get it right. Every implementation that we cou=
ld think of is inconsistent with some other aspects of the interface. Optio=
nal reference is just tricky. Nonetheless the guidance from LWG was that if=
 optional references are there, they should have a rebinding assignment (re=
moving optional refs altogether is also a consistent option). At least copy=
 ctor, assignment and swap are consistent with themselves. And to learn its=
 mechanics should also be easy: if you mutate it, it rebinds; if you just r=
ead it, it behaves like a reference.<br><br>How many <u>practical</u> gotch=
as of Optional can you list? My understanding (apologies if it is wrong) is=
 that you are concerned with "purity" aspects rather gothchas that regular =
C++ programmers might run into.<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_63_16113214.1363334090623--

.

On Fri, Mar 15, 2013 at 2:06 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 15 March 2013 07:47, Tony V E <tvaneerd@gmail.com> wrote:
>> - vector<T>:
>> - nothrow move, swap (moves/swaps pointer)
>> - these do NOT call T's move or swap
>> - move 'empties' the source vector
>> - etc
>> optional:
>> - must call T's move, swap, etc
>> - does not empty source on move
>> this is directly due to optional having T embedded.  So being embedded
>> isn't just an implementation detail - its API.  (It is also an
>
> It's interesting that you use vector as a comparison, because vector's
> implementation
> is directly visible in its API, especially the requirements that
> vector is contiguous.
> Therefore I don't think it's unprecedented that an intended implementation, when
> it has important physical characteristics, is reflected in the API.
>

agreed.


>> I really would like to see optional be self-consistent, so that
>> instead of having a number of special rules and gotchas, the only
>> rules are:
>> - assignment: constructs T with source value if not already engaged,
>> else assigns T with source value
>> - otherwise, if engaged, does whatever T does in that situation
>> - mostly undefined if not engaged
>
> "Mostly undefined if not engaged"? Which cases are undefined? Also, is
> it a gotcha
> that assigning from a disengaged disengages? Because that's very
> useful in practice,
> even if it doesn't seem philosophically pure.
>

Maybe just forget the "mostly undefined" part - that was a last second
addition (at 2am) when I realized to be complete I needed to mention
rules about disengaged.  My point was more about the engaged cases.

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, Mar 15, 2013 at 3:54 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
 wrote:
>
>
> W dniu pi=B1tek, 15 marca 2013 06:47:12 UTC+1 u=BFytkownik Tony V E napis=
a=B3:
>>
>
> I may not address all of the points you bring, but let me try to reply.
>
> First, apart from "technical" goals, we also have a "political" goal for
> Optional: we want it to gather a consensus in the Committee and be added =
to
> C++; soon. This affects the design to significant extent. We are willing =
to
> sacrifice some of the purity of the interface in order to make Optional
> generally useful to many users with various views.
>

Unfortunate, but somewhat understandable.
If you want to get *really* political, being the only member from my
country showing interest in the details of optional, my opinion might
well decide one NB's vote on it. :-)
But really, I agree that it is worth having optional in the standard
even if I don't agree with every detail in the edge cases.

On the other hand, I think all the members agree - I'm pretty sure
they will accept optional regardless of what you do on the edge cases,
so feel free to remain pure.


> Yes; the contained value being embedded inside Optional's storage is part=
 of
> the API. It is even mentioned in the proposed wording: "Engaged instances=
 of
> optional<T> where T is of object type shall contain a value of type T wit=
hin
> its own storage."
> You can rely on it, for instance in case you want to implement the copyin=
g
> of array<optional<int>, 100> using memcpy.
>
> I agree that using "exposition only" pointer may be confusing. On the oth=
er
> hand, I am not sure how to express the requirements without it. If you ha=
ve
> any suggestion, it would be welcome. The wording is correct and unambiguo=
us,
> I think: it is just that it may confuse the reader.
>
> Agreed that the model of 0-or-1-sized container will not do. This is why =
we
> do not choose it. We prefer to see it as a value storing all T's + one
> additional state (hence the mixed rel-ops) with the possibility to cast t=
he
> value back to T.
>

So maybe you shouldn't use "works like other std containers" as reasoning t=
hen.

> Regarding the (homogenous) relops, it is possible to implement them as ju=
st
> forwarding to T. But before departing from the current practice in the
> Library I would rather hear the direction from LWG. Can you think of any
> practical use case where this difference (between the current proposal an=
d
> your expectation) really matters? Given the model " all T's + one additio=
nal
> state", this difference does not appear that relevant.

Obviously, only for cases where you don't do traditional relops.
Maybe DSELs, boost Proto-like stuff.  Not average programmer stuff.

But I think either way you define relops (forwarding or not) will be
the same for the average programmer.  One is not better than the other
for average code.


> And also, you get all
> relops for free if you only define =3D=3D and <.
>

I don't think that should be optional's job.  That is probably
something we should solve elsewhere in the language (like using
=3Ddefault for operators).


> Optional reference assignment is very fragile, and it is not possible to =
get
> it right. Every implementation that we could think of is inconsistent wit=
h
> some other aspects of the interface. Optional reference is just tricky.

I'm not sure I agree with that (I have some vague ideas), but I'll
need to get back to it in a later email.

> Nonetheless the guidance from LWG was that if optional references are the=
re,
> they should have a rebinding assignment (removing optional refs altogethe=
r
> is also a consistent option).

I was at the last LWG when optional was presented.  I may have been
one of the ones giving that guidance :-)
I worry that LWG can only give so much time to each proposal such that
initial guidance isn't always best. - Although I do think gut-reaction
tends to be a good sign of how the average programmer (who rarely has
time to think deeply about a library) will see an API.  And of course
some of LWG have used boost::optional or similar and are coming from
experience.  And of course just gut-reaction from LWG could easily be
better than what I might conclude after days of study :-)


> At least copy ctor, assignment and swap are
> consistent with themselves. And to learn its mechanics should also be eas=
y:
> if you mutate it, it rebinds; if you just read it, it behaves like a
> reference.
>

> How many practical gotchas of Optional can you list? My understanding
> (apologies if it is wrong) is that you are concerned with "purity" aspect=
s
> rather gothchas that regular C++ programmers might run into.
>

_practical_ gotchas? Maybe none.  They are more the "advanced
gotchas".  So on one hand, no particular optional<T&> behaviour or
relops behaviour will affect the average programmer - because the
average programmer won't use optional<T&> at all nor have classes with
non-consistent relops.

But for the, let's say "intermediate optional programmer" who is
probably "advanced programmer, occasional optional user", it seems
like more rules/exceptions.

So the decisions on the edge cases don't effect the average usage
either way, but they do affect the advanced user.

(... and it seems I have a "on one hand" here, and a "On the other
hand" at the top of the email, so my naive +/- bracket counting
algorithm says this is correct.:-)

> Regards,
> &rzej
>

Thanks for all your work to bring optional into the standard,
Tony

--=20

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



.

On 15 March 2013 22:03, Tony V E <tvaneerd@gmail.com> wrote:
>> Nonetheless the guidance from LWG was that if optional references are there,
>> they should have a rebinding assignment (removing optional refs altogether
>> is also a consistent option).
> I was at the last LWG when optional was presented.  I may have been
> one of the ones giving that guidance :-)
> I worry that LWG can only give so much time to each proposal such that
> initial guidance isn't always best. - Although I do think gut-reaction
> tends to be a good sign of how the average programmer (who rarely has
> time to think deeply about a library) will see an API.  And of course
> some of LWG have used boost::optional or similar and are coming from
> experience.  And of course just gut-reaction from LWG could easily be
> better than what I might conclude after days of study :-)

Well, having been there too, I remember Eric Niebler stating that he thinks
optional<T&> should do what reference_wrapper<T> does. That seems like
a sane piece of advice, because should we omit optional<T&>, its work-around
is.. ..optional<reference_wrapper<T>>. ;) Even if we keep optional<T&>, I don't
think we want to introduce such a difference between optional<T&> and
optional<reference_wrapper<T>>. reference_wrapper<T> performs
re-seating on assignment.

--

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



.

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

On 15 March 2013 15:03, Tony V E <tvaneerd@gmail.com> wrote:

>
> > And also, you get all
> > relops for free if you only define == and <.
> >
>
> I don't think that should be optional's job.  That is probably
> something we should solve elsewhere in the language (like using
> =default for operators).
>

-1.  Given that we have a reasonable solution, putting off solving the
problem now in the hopes of some as yet unproposed future language feature
is a really bad idea.  It would be inconsistent with the rest of the
standard library.  I can see either (a) for engaged values, forward to the
underlying relop if it exists (consistent with things like std::atomic) or
(b) rewrite the rest of the relops in terms of == and < (consistent with
containers).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



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

On 15 March 2013 15:03, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tv=
aneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote=
:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><div class=3D"im">
&gt; And also, you get all<br>
&gt; relops for free if you only define =3D=3D and &lt;.<br>
&gt;<br>
<br>
</div>I don&#39;t think that should be optional&#39;s job. =A0That is proba=
bly<br>
something we should solve elsewhere in the language (like using<br>
=3Ddefault for operators).<br></blockquote><div><br>-1.=A0 Given that we ha=
ve a reasonable solution, putting off solving the problem now in the hopes =
of some as yet unproposed future language feature is a really bad idea.=A0 =
It would be inconsistent with the rest of the standard library.=A0 I can se=
e either (a) for engaged values, forward to the underlying relop if it exis=
ts (consistent with things like std::atomic) or (b) rewrite the rest of the=
 relops in terms of =3D=3D and &lt; (consistent with containers).<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=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 />

--14dae9ccde3ee9e34404d7fc73d3--

.

On Fri, Mar 15, 2013 at 4:14 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 15 March 2013 22:03, Tony V E <tvaneerd@gmail.com> wrote:
>>> Nonetheless the guidance from LWG was that if optional references are there,
>>> they should have a rebinding assignment (removing optional refs altogether
>>> is also a consistent option).
>> I was at the last LWG when optional was presented.  I may have been
>> one of the ones giving that guidance :-)
>> I worry that LWG can only give so much time to each proposal such that
>> initial guidance isn't always best. - Although I do think gut-reaction
>> tends to be a good sign of how the average programmer (who rarely has
>> time to think deeply about a library) will see an API.  And of course
>> some of LWG have used boost::optional or similar and are coming from
>> experience.  And of course just gut-reaction from LWG could easily be
>> better than what I might conclude after days of study :-)
>
> Well, having been there too, I remember Eric Niebler stating that he thinks
> optional<T&> should do what reference_wrapper<T> does. That seems like
> a sane piece of advice, because should we omit optional<T&>, its work-around
> is.. ..optional<reference_wrapper<T>>. ;) Even if we keep optional<T&>, I don't
> think we want to introduce such a difference between optional<T&> and
> optional<reference_wrapper<T>>. reference_wrapper<T> performs
> re-seating on assignment.
>

Alternatively, is re-seating assignment one of the essential points
for existence of reference_wrapper<> over just using references
directly?  (And if not an essential point of its existence, at least
an essential difference)

Shouldn't we expect optional<reference_wrapper<T>> to behave
differently than optional<T&> in the exact same ways that
reference_wrapper<T> acts differently than T &.
?

Or in other words,
    "reference_wrapper<T> does not work like T & , so I expect
optional<T&> to work like optional<reference_wrapper<T>>"
doesn't actually make sense to me. (Sorry Eric)



What about (and my email-compiler is still broken, so this is not exact...)

template<typename T>
class ref_like
{
   T * t;
public:
    ref_like(T & target) : t(&target) {}   // binds
    ref_like & operator=(T value) { *t = value; }  // assigns through

    // ... assign/constructors as needed for && and const and whatever else

    T & operatorT&() { return *t; }
};

Does this work *exactly* like a reference?

And how does optional<ref_like<T>> behave?  Exactly as I propose
optional<T&> should?

I'm probably missing lots of problems - this is why I (in the other
reply) I needed more time to think about it.

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, Mar 15, 2013 at 4:25 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 15 March 2013 15:03, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>
>> > And also, you get all
>> > relops for free if you only define == and <.
>> >
>>
>> I don't think that should be optional's job.  That is probably
>> something we should solve elsewhere in the language (like using
>> =default for operators).
>
>
> -1.  Given that we have a reasonable solution, putting off solving the
> problem now in the hopes of some as yet unproposed future language feature
> is a really bad idea.  It would be inconsistent with the rest of the
> standard library.  I can see either (a) for engaged values, forward to the
> underlying relop if it exists (consistent with things like std::atomic) or
> (b) rewrite the rest of the relops in terms of == and < (consistent with
> containers).
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>

I have a slight confusion.  Which part is the -1?
I'm suggesting (a) instead of (b).  Sorry if I wasn't clear.  (I'm not
suggesting no relops, for example)

And I think std::atomic<> is a great example - I think it is closer to
optional than containers or tuples. ie it is also trying to *be* T as
much as possible.

The other option, I suppose, is to generate the other relops *if* T
hasn't defined them already. (Or was that would you were suggesting?)
ie forward if available, generate otherwise - on a per T basis.  (more
work for implementors...)


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, Mar 15, 2013 at 5:01 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> What about (and my email-compiler is still broken, so this is not exact...)
>
> template<typename T>
> class ref_like
> {
>    T * t;
> public:
>     ref_like(T & target) : t(&target) {}   // binds
>     ref_like & operator=(T value) { *t = value; }  // assigns through
>

grrrr.   Is this where the problems lie...

       ref_like(ref_like const & other) {...}
       ref_like & operator=(ref_like other) { ... }


>     // ... assign/constructors as needed for && and const and whatever else
>
>     T & operatorT&() { return *t; }
> };
>
> Does this work *exactly* like a reference?
>
> And how does optional<ref_like<T>> behave?  Exactly as I propose
> optional<T&> should?
>
> I'm probably missing lots of problems - this is why I (in the other
> reply) I needed more time to think about it.
>
> 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.



.

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

On 15 March 2013 16:07, Tony V E <tvaneerd@gmail.com> wrote:

>
> I have a slight confusion.  Which part is the -1?
>

I think we either (a) forward them all (if they exist for T; otherwise,
don't compile), or (b) generate them all (in terms of == and <).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



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

On 15 March 2013 16:07, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tv=
aneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote=
:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div><br>
</div></div>I have a slight confusion. =A0Which part is the -1?<br></blockq=
uote><div><br>I think we either (a) forward them all (if they exist for T; =
otherwise, don&#39;t compile), or (b) generate them all (in terms of =3D=3D=
 and &lt;).<br clear=3D"all">


</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=
=3D"_blank">(847) 691-1404</a>

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

--14dae93995a99ac4d504d7fd45f9--

.

------=_Part_235_8524221.1363406329514
Content-Type: text/plain; charset=ISO-8859-1



On Friday, March 15, 2013 1:14:25 PM UTC-7, Ville Voutilainen wrote:
>
> On 15 March 2013 22:03, Tony V E <tvan...@gmail.com <javascript:>> wrote:
> >> Nonetheless the guidance from LWG was that if optional references are
> there,
> >> they should have a rebinding assignment (removing optional refs
> altogether
> >> is also a consistent option).
> > I was at the last LWG when optional was presented.  I may have been
> > one of the ones giving that guidance :-)
> > I worry that LWG can only give so much time to each proposal such that
> > initial guidance isn't always best. - Although I do think gut-reaction
> > tends to be a good sign of how the average programmer (who rarely has
> > time to think deeply about a library) will see an API.  And of course
> > some of LWG have used boost::optional or similar and are coming from
> > experience.  And of course just gut-reaction from LWG could easily be
> > better than what I might conclude after days of study :-)
>
> Well, having been there too, I remember Eric Niebler stating that he
> thinks
> optional<T&> should do what reference_wrapper<T> does. That seems like
> a sane piece of advice, because should we omit optional<T&>, its
> work-around
> is.. ..optional<reference_wrapper<T>>. ;) Even if we keep optional<T&>, I
> don't
> think we want to introduce such a difference between optional<T&> and
> optional<reference_wrapper<T>>. reference_wrapper<T> performs
> re-seating on assignment.
>

Why not just sanction it directly? Just say:

template<typename T>
using optional_ref = optional<reference_wrapper<T>>;

We can even add:

template<typename T> optional_ref<T> ref_opt(T &);

To make creating them easier.

--

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

<br><br>On Friday, March 15, 2013 1:14:25 PM UTC-7, Ville Voutilainen wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On 15 March 2013 22:03, Tony =
V E &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
cnz5vZM1KvsJ">tvan...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; Nonetheless the guidance from LWG was that if optional referen=
ces are there,
<br>&gt;&gt; they should have a rebinding assignment (removing optional ref=
s altogether
<br>&gt;&gt; is also a consistent option).
<br>&gt; I was at the last LWG when optional was presented. &nbsp;I may hav=
e been
<br>&gt; one of the ones giving that guidance :-)
<br>&gt; I worry that LWG can only give so much time to each proposal such =
that
<br>&gt; initial guidance isn't always best. - Although I do think gut-reac=
tion
<br>&gt; tends to be a good sign of how the average programmer (who rarely =
has
<br>&gt; time to think deeply about a library) will see an API. &nbsp;And o=
f course
<br>&gt; some of LWG have used boost::optional or similar and are coming fr=
om
<br>&gt; experience. &nbsp;And of course just gut-reaction from LWG could e=
asily be
<br>&gt; better than what I might conclude after days of study :-)
<br>
<br>Well, having been there too, I remember Eric Niebler stating that he th=
inks
<br>optional&lt;T&amp;&gt; should do what reference_wrapper&lt;T&gt; does. =
That seems like
<br>a sane piece of advice, because should we omit optional&lt;T&amp;&gt;, =
its work-around
<br>is.. ..optional&lt;reference_wrapper&lt;<wbr>T&gt;&gt;. ;) Even if we k=
eep optional&lt;T&amp;&gt;, I don't
<br>think we want to introduce such a difference between optional&lt;T&amp;=
&gt; and
<br>optional&lt;reference_wrapper&lt;T&gt;&gt;<wbr>. reference_wrapper&lt;T=
&gt; performs
<br>re-seating on assignment.
<br></blockquote><div><br>Why not just sanction it directly? Just say:<br><=
br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
 word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">using</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> optional_ref </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> optional</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">reference_wrapper</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;&gt;;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span></div></code></div><br>We can even add:<br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> optional_ref</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">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> ref_opt</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">T </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br>To make creating them easier.<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_235_8524221.1363406329514--

.

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

Hi Tony,

First I'd like to apologize, but I keep being hunted by this ridiculously
overdue project that is driving crazy. I haven't been able to follow on any
discussion for std::optional until today.


On Fri, Mar 15, 2013 at 2:47 AM, Tony V E <tvaneerd@gmail.com> wrote:

> I was thinking about the differences between optional<T> and
> containers, ie vector<T>.
>
> In particular that vector<T> allocates storage for its elements
> whereas optional<T> has a T embedded.
> And in particular, how that affects API:
>
> - vector<T>:
> - nothrow move, swap (moves/swaps pointer)
> - these do NOT call T's move or swap
> - move 'empties' the source vector
> - etc
>
> optional:
> - must call T's move, swap, etc
> - does not empty source on move
>
> this is directly due to optional having T embedded.  So being embedded
> isn't just an implementation detail - its API.


Absolutely.


>  (It is also an
> important characteristic for performance.)  Is it (will it be) a
> *requirement*?


Yes


>  (obviously optional doesn't take an allocator, so it
> shouldn't be allocating)
>
>
> I think describing optional (as in the latest rev of the proposal) as
> _like_ having a T * member, causes more confusion than it is worth.
> I also think trying to see optional as a 'container-of-one' is
> error-prone (in the sense of causing design errors with potential
> decisions on how optional should behave), since it isn't a true
> analogy.
>
>
> Note that *every* operation on optional<T> forwards directly to T.
> The only case that doesn't *directly* forward, is assignment, as it
> may actually do copy-construction if the optional wasn't already
> engaged (otherwise it forwards to T's assignment).
>
> Oh, *except* the relational operators.  <=, >, >= all forward to < and ==.
> I find that just wrong.  I know it goes against containers and
> pair/tuple, but, as above, I think it is wrong to think of optional as
> a container.
> Optional is a "T or not".
>
> On the one hand, I completely agree with you.
But OTOH, I think your point exceeds std::optional and could be (should
be?) made for containers and pair/tuple.
So, we had to decide between the best choice by itself and consistency with
the rest of the lib and chose the later.

Also, that's how it is defined in boost::optional. While it is not a
requirement, consistency with Boost.Optional is significant since people
would eventually replace one with the other. Last year I upgraded a large
project to C++11 and it took me a lot of time and dedication to port all
uses of boost::shared_ptr, weak_pre, bind, tuple, etc.. only because of the
small differences between the boost and std versions. I'd like to minimize
that as much as possible with std::optional.



> I think *not* forwarding the relational operators directly goes
> against optional itself, and it is more important to be
> self-consistent than consistent with other parts of std::,
> particularly parts that aren't really good analogs.
>
> I'm not sure I agree on what is more important. The semantics of rest of
the library implies a set of expectations that everyone automatically have,
so it might be surprising to break that even if it is to "fix a mistake"


Also, I think not having optional<T&> forward exactly to T& is wrong
> for the same reason. (Meaning first assignment sets the reference,
> subsequent ones assign through the reference, etc.)
>
> I really would like to see optional be self-consistent,


Actually, the choice of semantics for optional references are precisely
given for consistency. This is only evident when you consider the
transition to and from the disengaged state. Consider:

int a = 1 ;
int b = 2 ;
int c = 3 ;

optional<int&> oref = a ;

// oref is engaged, so it would make sense to assign the referenced object
oref = b ;
assert( a == b ) ;

oref = nullopt ; // now oref is disengafed

oref = c ;
assert( a == c )  // ERROR: a was not reassigned because the optional lost
its track

As you can see, with those semantics, assignment would do one or the other
depending on whether the optional reference is engage or not, whereas with
the proposed semantics it's always consistent.

Best

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

--

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



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

<div dir=3D"ltr"><div>Hi Tony,<br><br></div>First I&#39;d like to apologize=
, but I keep being hunted by this ridiculously overdue project that is driv=
ing crazy. I haven&#39;t been able to follow on any discussion for std::opt=
ional until today.<br>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Mar 1=
5, 2013 at 2:47 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvanee=
rd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">

I was thinking about the differences between optional&lt;T&gt; and<br>
containers, ie vector&lt;T&gt;.<br>
<br>
In particular that vector&lt;T&gt; allocates storage for its elements<br>
whereas optional&lt;T&gt; has a T embedded.<br>
And in particular, how that affects API:<br>
<br>
- vector&lt;T&gt;:<br>
- nothrow move, swap (moves/swaps pointer)<br>
- these do NOT call T&#39;s move or swap<br>
- move &#39;empties&#39; the source vector<br>
- etc<br>
<br>
optional:<br>
- must call T&#39;s move, swap, etc<br>
- does not empty source on move<br>
<br>
this is directly due to optional having T embedded. =A0So being embedded<br=
>
isn&#39;t just an implementation detail - its API. </blockquote><div><br></=
div><div>Absolutely.<br></div><div></div><div>=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">

=A0(It is also an<br>
important characteristic for performance.) =A0Is it (will it be) a<br>
*requirement*? </blockquote><div><br></div><div>Yes<br>=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">=A0(obviously optional doesn&#39=
;t take an allocator, so it<br>


shouldn&#39;t be allocating)<br>
<br>
<br>
I think describing optional (as in the latest rev of the proposal) as<br>
_like_ having a T * member, causes more confusion than it is worth.<br>
I also think trying to see optional as a &#39;container-of-one&#39; is<br>
error-prone (in the sense of causing design errors with potential<br>
decisions on how optional should behave), since it isn&#39;t a true<br>
analogy.<br>
<br>
<br>
Note that *every* operation on optional&lt;T&gt; forwards directly to T.<br=
>
The only case that doesn&#39;t *directly* forward, is assignment, as it<br>
may actually do copy-construction if the optional wasn&#39;t already<br>
engaged (otherwise it forwards to T&#39;s assignment).<br>
<br>
Oh, *except* the relational operators. =A0&lt;=3D, &gt;, &gt;=3D all forwar=
d to &lt; and =3D=3D.<br>
I find that just wrong. =A0I know it goes against containers and<br>
pair/tuple, but, as above, I think it is wrong to think of optional as<br>
a container.<br>
Optional is a &quot;T or not&quot;.<br>
<br></blockquote><div>On the one hand, I completely agree with you.<br></di=
v><div>But OTOH, I think your point exceeds std::optional and could be (sho=
uld be?) made for containers and pair/tuple.<br></div><div>So, we had to de=
cide between the best choice by itself and consistency with the rest of the=
 lib and chose the later.<br>

<br></div><div>Also, that&#39;s how it is defined in boost::optional. While=
 it is not a requirement, consistency with Boost.Optional is significant si=
nce people would eventually replace one with the other. Last year I upgrade=
d a large project to C++11 and it took me a lot of time and dedication to p=
ort all uses of boost::shared_ptr, weak_pre, bind, tuple, etc.. only becaus=
e of the small differences between the boost and std versions. I&#39;d like=
 to minimize that as much as possible with std::optional.<br>

</div><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think *not* forwarding the relational operators directly goes<br>
against optional itself, and it is more important to be<br>
self-consistent than consistent with other parts of std::,<br>
particularly parts that aren&#39;t really good analogs.<br>
<br></blockquote><div>I&#39;m not sure I agree on what is more important. T=
he semantics of rest of the library implies a set of expectations that ever=
yone automatically have, so it might be surprising to break that even if it=
 is to &quot;fix a mistake&quot;<br>

<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, I think not having optional&lt;T&amp;&gt; forward exactly to T&amp; i=
s wrong<br>
for the same reason. (Meaning first assignment sets the reference,<br>
subsequent ones assign through the reference, etc.)<br>
<br>
I really would like to see optional be self-consistent, </blockquote><div><=
br></div><div>Actually, the choice of semantics for optional references are=
 precisely given for consistency. This is only evident when you consider th=
e transition to and from the disengaged state. Consider:<br>

<br></div><div>int a =3D 1 ;<br></div><div><div>int b =3D 2 ;<br></div>int =
c =3D 3 ;<br><br>optional&lt;int&amp;&gt; oref =3D a ;<br><br></div>// oref=
 is engaged, so it would make sense to assign the referenced object<br><div=
>oref =3D b ; <br>

</div><div>assert( a =3D=3D b ) ;<br><br></div>oref =3D nullopt ; // now or=
ef is disengafed<br><div><br></div><div>oref =3D c ; <br></div><div>assert(=
 a =3D=3D c )=A0 // ERROR: a was not reassigned because the optional lost i=
ts track<br>

</div><div><br></div><div>As you can see, with those semantics, assignment =
would do one or the other depending on whether the optional reference is en=
gage or not, whereas with the proposed semantics it&#39;s always consistent=
..<br>

<br>Best<br></div><div></div></div><br>-- <br>Fernando Cacciola<br>SciSoft =
Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http:/=
/www.scisoft-consulting.com</a>
</div></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 />

--f46d0407143396d51e04d8457a2e--

.

On Fri, Mar 15, 2013 at 4:25 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>  I can see either (a) for engaged values, forward to the
> underlying relop if it exists (consistent with things like std::atomic) or
> (b) rewrite the rest of the relops in terms of == and < (consistent with
> containers).
>

Actually, as much as I'd like to use std::atomic as an example, I'm
not sure relops are defined at all for atomics.  (Possibly because the
relop would not be atomic.)
atomic<T> has a conversion to T, so I guess atomic1 < atomic2 is
really 2 conversions then the relop on the T.

So in a way atomic<T> forwards relops to T, but not via defining relops.

On the other hand, if definitely doesn't define all the other relops
in terms of < and ==.

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 Tue, Mar 19, 2013 at 7:33 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
>>
>> Note that *every* operation on optional<T> forwards directly to T.
>> The only case that doesn't *directly* forward, is assignment, as it
>> may actually do copy-construction if the optional wasn't already
>> engaged (otherwise it forwards to T's assignment).
>>
>> Oh, *except* the relational operators.  <=, >, >= all forward to < and ==.
>> I find that just wrong.  I know it goes against containers and
>> pair/tuple, but, as above, I think it is wrong to think of optional as
>> a container.
>> Optional is a "T or not".
>>
> On the one hand, I completely agree with you.
> But OTOH, I think your point exceeds std::optional and could be (should be?)
> made for containers and pair/tuple.

I somewhat agree the other containers are also broken, but
importantly, containers/tuple don't try to be their underlying type at
all. Optional does.

> So, we had to decide between the best choice by itself and consistency with
> the rest of the lib and chose the later.
>
yeah I know.

> Also, that's how it is defined in boost::optional. While it is not a
> requirement, consistency with Boost.Optional is significant since people
> would eventually replace one with the other. Last year I upgraded a large
> project to C++11 and it took me a lot of time and dedication to port all
> uses of boost::shared_ptr, weak_pre, bind, tuple, etc.. only because of the
> small differences between the boost and std versions. I'd like to minimize
> that as much as possible with std::optional.
>

I don't give that much weight.  I doubt handling relops either way
will affect any boost users.  And I think the point of boost is to try
things - we need to be able to change them when they go into std.

>
>>
>> I think *not* forwarding the relational operators directly goes
>> against optional itself, and it is more important to be
>> self-consistent than consistent with other parts of std::,
>> particularly parts that aren't really good analogs.
>>
> I'm not sure I agree on what is more important. The semantics of rest of the
> library implies a set of expectations that everyone automatically have, so
> it might be surprising to break that even if it is to "fix a mistake"
>

Like I said, the rest of the library doesn't try to mimic an
underlying type as much as optional does.  I think only std::atomic
has a similar role (and doesn't re-define the relops).

>
>> Also, I think not having optional<T&> forward exactly to T& is wrong
>> for the same reason. (Meaning first assignment sets the reference,
>> subsequent ones assign through the reference, etc.)
>>
>> I really would like to see optional be self-consistent,
>
>
> Actually, the choice of semantics for optional references are precisely
> given for consistency. This is only evident when you consider the transition
> to and from the disengaged state. Consider:
>
> int a = 1 ;
> int b = 2 ;
> int c = 3 ;
>
> optional<int&> oref = a ;

optional<int&> oref = a;  // inner  int & constructed with (binds to) a
optional<Foo> ofoo = a; // inner Foo constructed with a

>
> // oref is engaged, so it would make sense to assign the referenced object
> oref = b ;
> assert( a == b ) ;
>

oref = b ;  // inner int & *assigned* b, a set to b
ofoo = b;  // inner Foo assigned b

> oref = nullopt ; // now oref is disengafed, inner int & is "destroyed" no longer valid
ofoo = nullopt; // same, inner Foo is destroyed, no longer valid

>
> oref = c ;
> assert( a == c )  // ERROR: a was not reassigned because the optional lost
> its track
>

oref  = c; // inner int & (re)constructed with (binds to) c
ofoo = c; // inner Foo (re)constructed with c

> As you can see, with those semantics, assignment would do one or the other
> depending on whether the optional reference is engage or not,

just like every other T in optional<T>.  Optional<T> does one or the
other depending on whether the optional is engaged or not.  That is
optional, is it not?

You are being deceived because most T's are regular - assignment and
construction do essentially the same thing, so you don't typically see
the "inconsistency".


> whereas with
> the proposed semantics it's always consistent.

As you can see, that is inconsistent with optional.

You've made an non-consistent type (int&) consistent.

int & is not a regular-type.  For any NonRegular T, optional<T> should
not suddenly be Regular.  Will you fix all NonRegulars? (somehow... ie
never construct more than once, don't call destructor when setting to
nullopt?...)  You are basically resurrecting dead int &'s.


I know many people find the behaviour somewhat surprising, but I feel
this is just because they don't actually understand the behaviour of
optional.  Maybe you should ban optional<T> for all non-regular T.

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

Obviously we just disagree, but I thought I'd give it one more try.
:-)  And actually feel it is possible for forward progress, not just
stalemate disagreement.
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 19/03/13 19:11, Tony V E wrote:
> I don't give that much weight. I doubt handling relops either way will
> affect any boost users. And I think the point of boost is to try
> things - we need to be able to change them when they go into std.

Personally, I think consistency with std::tuple / the containers is
important. But also, one data point:

Just looking at this one point. Very irritatingly google code search has
disappeared just recently, but last time I checked there was about twice
as many 'operator==' as 'operator!=', and about twice as many
'operator<' as 'operator>='.

That means there is lots of code out there where people are lazy at
implementing all operators. If those types would then be put in a
std::optional, and compared with != / >= / etc, it is hard to know. But
in general people often don't implement all operators.

Chris

--

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



.

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

On Tue, Mar 19, 2013 at 4:11 PM, Tony V E <tvaneerd@gmail.com> wrote:

> On Tue, Mar 19, 2013 at 7:33 AM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> >>
> >> Note that *every* operation on optional<T> forwards directly to T.
> >> The only case that doesn't *directly* forward, is assignment, as it
> >> may actually do copy-construction if the optional wasn't already
> >> engaged (otherwise it forwards to T's assignment).
> >>
> >> Oh, *except* the relational operators.  <=, >, >= all forward to < and
> ==.
> >> I find that just wrong.  I know it goes against containers and
> >> pair/tuple, but, as above, I think it is wrong to think of optional as
> >> a container.
> >> Optional is a "T or not".
> >>
> > On the one hand, I completely agree with you.
> > But OTOH, I think your point exceeds std::optional and could be (should
> be?)
> > made for containers and pair/tuple.
>
> I somewhat agree the other containers are also broken, but
> importantly, containers/tuple don't try to be their underlying type at
> all. Optional does.
>
> Agreed.


> > So, we had to decide between the best choice by itself and consistency
> with
> > the rest of the lib and chose the later.
> >
> yeah I know.
>
> > Also, that's how it is defined in boost::optional. While it is not a
> > requirement, consistency with Boost.Optional is significant since people
> > would eventually replace one with the other. Last year I upgraded a large
> > project to C++11 and it took me a lot of time and dedication to port all
> > uses of boost::shared_ptr, weak_pre, bind, tuple, etc.. only because of
> the
> > small differences between the boost and std versions. I'd like to
> minimize
> > that as much as possible with std::optional.
> >
>
> I don't give that much weight.  I doubt handling relops either way
> will affect any boost users.  And I think the point of boost is to try
> things


Indeed.


> - we need to be able to change them when they go into std.
>
>
Absolutely. Though while doing that we might play against adoption of the
standardized version.
Having said that, I think I agree with you that in the particular case of
relops, I don't expect it to have a significant impact on existing
Boost.Optional users.

>
> >>
> >> I think *not* forwarding the relational operators directly goes
> >> against optional itself, and it is more important to be
> >> self-consistent than consistent with other parts of std::,
> >> particularly parts that aren't really good analogs.
> >>
> > I'm not sure I agree on what is more important. The semantics of rest of
> the
> > library implies a set of expectations that everyone automatically have,
> so
> > it might be surprising to break that even if it is to "fix a mistake"
> >
>
> Like I said, the rest of the library doesn't try to mimic an
> underlying type as much as optional does.  I think only std::atomic
> has a similar role (and doesn't re-define the relops).
>
> Point taken.


> >
> >> Also, I think not having optional<T&> forward exactly to T& is wrong
> >> for the same reason. (Meaning first assignment sets the reference,
> >> subsequent ones assign through the reference, etc.)
> >>
> >> I really would like to see optional be self-consistent,
> >
> >
> > Actually, the choice of semantics for optional references are precisely
> > given for consistency. This is only evident when you consider the
> transition
> > to and from the disengaged state. Consider:
> >
> > int a = 1 ;
> > int b = 2 ;
> > int c = 3 ;
> >
> > optional<int&> oref = a ;
>
> optional<int&> oref = a;  // inner  int & constructed with (binds to) a
> optional<Foo> ofoo = a; // inner Foo constructed with a
>
> >
> > // oref is engaged, so it would make sense to assign the referenced
> object
> > oref = b ;
> > assert( a == b ) ;
> >
>
> oref = b ;  // inner int & *assigned* b, a set to b
> ofoo = b;  // inner Foo assigned b
>
> > oref = nullopt ; // now oref is disengafed, inner int & is "destroyed"
> no longer valid
> ofoo = nullopt; // same, inner Foo is destroyed, no longer valid
>
> >
> > oref = c ;
> > assert( a == c )  // ERROR: a was not reassigned because the optional
> lost
> > its track
> >
>
> oref  = c; // inner int & (re)constructed with (binds to) c
> ofoo = c; // inner Foo (re)constructed with c
>
> > As you can see, with those semantics, assignment would do one or the
> other
> > depending on whether the optional reference is engage or not,
>
> just like every other T in optional<T>.  Optional<T> does one or the
> other depending on whether the optional is engaged or not.  That is
> optional, is it not?
>
> Right


> You are being deceived because most T's are regular - assignment and
> construction do essentially the same thing, so you don't typically see
> the "inconsistency".
>
>  OK, I agree here.


> > whereas with
> > the proposed semantics it's always consistent.
>
> As you can see, that is inconsistent with optional.
>
> You've made an non-consistent type (int&) consistent.
>
>
That's indeed a nice way to put it. In fact, I wrote in my response that
this was chosen "for consistency" , not self-consistency.

int & is not a regular-type.  For any NonRegular T, optional<T> should
> not suddenly be Regular.  Will you fix all NonRegulars? (somehow... ie
> never construct more than once, don't call destructor when setting to
> nullopt?...)  You are basically resurrecting dead int &'s.
>
> I guess indeed you could say that.


>
> I know many people find the behaviour somewhat surprising, but I feel
> this is just because they don't actually understand the behaviour of
> optional.  Maybe you should ban optional<T> for all non-regular T.
>
> I think we even considered that at some point.
But like I said, I don't believe in restricting C++ in order to avoid
confusions, subtleties, etc...


> >
> > Best
> >
> > --
> > Fernando Cacciola
> > SciSoft Consulting, Founder
> > http://www.scisoft-consulting.com
> >
>
> Obviously we just disagree, but I thought I'd give it one more try.
> :-)  And actually feel it is possible for forward progress, not just
> stalemate disagreement.
>

And FWIW is not that we completely disagree. I totally see your arguments
(which have been made before several times), but I also see arguments for
the other choice. At the end of the day we have to choose one or the other,
so we did just that in the proposal. Technically speaking, it's as if the
balance where just 50.1% toward the proposed semantics.

Best


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

--

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



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 19, 2013 at 4:11 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Mar 19, 2013 at 7:=
33 AM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Note that *every* operation on optional&lt;T&gt; forwards directly=
 to T.<br>
&gt;&gt; The only case that doesn&#39;t *directly* forward, is assignment, =
as it<br>
&gt;&gt; may actually do copy-construction if the optional wasn&#39;t alrea=
dy<br>
&gt;&gt; engaged (otherwise it forwards to T&#39;s assignment).<br>
&gt;&gt;<br>
&gt;&gt; Oh, *except* the relational operators. =A0&lt;=3D, &gt;, &gt;=3D a=
ll forward to &lt; and =3D=3D.<br>
&gt;&gt; I find that just wrong. =A0I know it goes against containers and<b=
r>
&gt;&gt; pair/tuple, but, as above, I think it is wrong to think of optiona=
l as<br>
&gt;&gt; a container.<br>
&gt;&gt; Optional is a &quot;T or not&quot;.<br>
&gt;&gt;<br>
&gt; On the one hand, I completely agree with you.<br>
&gt; But OTOH, I think your point exceeds std::optional and could be (shoul=
d be?)<br>
&gt; made for containers and pair/tuple.<br>
<br>
</div>I somewhat agree the other containers are also broken, but<br>
importantly, containers/tuple don&#39;t try to be their underlying type at<=
br>
all. Optional does.<br>
<div class=3D"im"><br></div></blockquote><div>Agreed.<br>=A0<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div class=3D"im">
&gt; So, we had to decide between the best choice by itself and consistency=
 with<br>
&gt; the rest of the lib and chose the later.<br>
&gt;<br>
</div>yeah I know.<br>
<div class=3D"im"><br>
&gt; Also, that&#39;s how it is defined in boost::optional. While it is not=
 a<br>
&gt; requirement, consistency with Boost.Optional is significant since peop=
le<br>
&gt; would eventually replace one with the other. Last year I upgraded a la=
rge<br>
&gt; project to C++11 and it took me a lot of time and dedication to port a=
ll<br>
&gt; uses of boost::shared_ptr, weak_pre, bind, tuple, etc.. only because o=
f the<br>
&gt; small differences between the boost and std versions. I&#39;d like to =
minimize<br>
&gt; that as much as possible with std::optional.<br>
&gt;<br>
<br>
</div>I don&#39;t give that much weight. =A0I doubt handling relops either =
way<br>
will affect any boost users. =A0And I think the point of boost is to try<br=
>
things </blockquote><div><br></div><div>Indeed.<br></div><div>=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">- we need to be able to change them when they go=
 into std.<br>


<div class=3D"im"><br></div></blockquote><div><br></div><div>Absolutely. Th=
ough while doing that we might play against adoption of the standardized ve=
rsion.<br></div><div>Having said that, I think I agree with you that in the=
 particular case of relops, I don&#39;t expect it to have a significant imp=
act on existing Boost.Optional users.<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 class=3D"im">
&gt;<br>
&gt;&gt;<br>
&gt;&gt; I think *not* forwarding the relational operators directly goes<br=
>
&gt;&gt; against optional itself, and it is more important to be<br>
&gt;&gt; self-consistent than consistent with other parts of std::,<br>
&gt;&gt; particularly parts that aren&#39;t really good analogs.<br>
&gt;&gt;<br>
&gt; I&#39;m not sure I agree on what is more important. The semantics of r=
est of the<br>
&gt; library implies a set of expectations that everyone automatically have=
, so<br>
&gt; it might be surprising to break that even if it is to &quot;fix a mist=
ake&quot;<br>
&gt;<br>
<br>
</div>Like I said, the rest of the library doesn&#39;t try to mimic an<br>
underlying type as much as optional does. =A0I think only std::atomic<br>
has a similar role (and doesn&#39;t re-define the relops).<br>
<div class=3D"im"><br></div></blockquote><div>Point taken.<br>=A0<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">
&gt;<br>
&gt;&gt; Also, I think not having optional&lt;T&amp;&gt; forward exactly to=
 T&amp; is wrong<br>
&gt;&gt; for the same reason. (Meaning first assignment sets the reference,=
<br>
&gt;&gt; subsequent ones assign through the reference, etc.)<br>
&gt;&gt;<br>
&gt;&gt; I really would like to see optional be self-consistent,<br>
&gt;<br>
&gt;<br>
&gt; Actually, the choice of semantics for optional references are precisel=
y<br>
&gt; given for consistency. This is only evident when you consider the tran=
sition<br>
&gt; to and from the disengaged state. Consider:<br>
&gt;<br>
&gt; int a =3D 1 ;<br>
&gt; int b =3D 2 ;<br>
&gt; int c =3D 3 ;<br>
&gt;<br>
&gt; optional&lt;int&amp;&gt; oref =3D a ;<br>
<br>
</div>optional&lt;int&amp;&gt; oref =3D a; =A0// inner =A0int &amp; constru=
cted with (binds to) a<br>
optional&lt;Foo&gt; ofoo =3D a; // inner Foo constructed with a<br>
<div class=3D"im"><br>
&gt;<br>
&gt; // oref is engaged, so it would make sense to assign the referenced ob=
ject<br>
&gt; oref =3D b ;<br>
&gt; assert( a =3D=3D b ) ;<br>
&gt;<br>
<br>
</div>oref =3D b ; =A0// inner int &amp; *assigned* b, a set to b<br>
ofoo =3D b; =A0// inner Foo assigned b<br>
<br>
&gt; oref =3D nullopt ; // now oref is disengafed, inner int &amp; is &quot=
;destroyed&quot; no longer valid<br>
ofoo =3D nullopt; // same, inner Foo is destroyed, no longer valid<br>
<div class=3D"im"><br>
&gt;<br>
&gt; oref =3D c ;<br>
&gt; assert( a =3D=3D c ) =A0// ERROR: a was not reassigned because the opt=
ional lost<br>
&gt; its track<br>
&gt;<br>
<br>
</div>oref =A0=3D c; // inner int &amp; (re)constructed with (binds to) c<b=
r>
ofoo =3D c; // inner Foo (re)constructed with c<br>
<div class=3D"im"><br>
&gt; As you can see, with those semantics, assignment would do one or the o=
ther<br>
&gt; depending on whether the optional reference is engage or not,<br>
<br>
</div>just like every other T in optional&lt;T&gt;. =A0Optional&lt;T&gt; do=
es one or the<br>
other depending on whether the optional is engaged or not. =A0That is<br>
optional, is it not?<br>
<br></blockquote><div>Right<br>=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You are being deceived because most T&#39;s are regular - assignment and<br=
>
construction do essentially the same thing, so you don&#39;t typically see<=
br>
the &quot;inconsistency&quot;.<br>
<div class=3D"im"><br></div></blockquote><div>=A0OK, I agree here.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
<br>
&gt; whereas with<br>
&gt; the proposed semantics it&#39;s always consistent.<br>
<br>
</div>As you can see, that is inconsistent with optional.<br>
<br>
You&#39;ve made an non-consistent type (int&amp;) consistent.<br>
<br></blockquote><div><br></div><div>That&#39;s indeed a nice way to put it=
.. In fact, I wrote in my response that this was chosen &quot;for consistenc=
y&quot; , not self-consistency.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>


int &amp; is not a regular-type. =A0For any NonRegular T, optional&lt;T&gt;=
 should<br>
not suddenly be Regular. =A0Will you fix all NonRegulars? (somehow... ie<br=
>
never construct more than once, don&#39;t call destructor when setting to<b=
r>
nullopt?...) =A0You are basically resurrecting dead int &amp;&#39;s.<br>
<br></blockquote><div>I guess indeed you could say that.<br>=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<br>
I know many people find the behaviour somewhat surprising, but I feel<br>
this is just because they don&#39;t actually understand the behaviour of<br=
>
optional. =A0Maybe you should ban optional&lt;T&gt; for all non-regular T.<=
br>
<div class=3D"im"><br></div></blockquote><div>I think we even considered th=
at at some point.<br></div><div>But like I said, I don&#39;t believe in res=
tricting C++ in order to avoid confusions, subtleties, etc... <br>=A0<br></=
div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">
&gt;<br>
&gt; Best<br>
&gt;<br>
&gt; --<br>
&gt; Fernando Cacciola<br>
&gt; SciSoft Consulting, Founder<br>
&gt; <a href=3D"http://www.scisoft-consulting.com" target=3D"_blank">http:/=
/www.scisoft-consulting.com</a><br>
&gt;<br>
<br>
</div>Obviously we just disagree, but I thought I&#39;d give it one more tr=
y.<br>
:-) =A0And actually feel it is possible for forward progress, not just<br>
stalemate disagreement.<br></blockquote><div><br></div><div>And FWIW is not=
 that we completely disagree. I totally see your arguments (which have been=
 made before several times), but I also see arguments for the other choice.=
 At the end of the day we have to choose one or the other, so we did just t=
hat in the proposal. Technically speaking, it&#39;s as if the balance where=
 just 50.1% toward the proposed semantics.<br>

</div><br></div><div class=3D"gmail_quote">Best<br></div><br clear=3D"all">=
<br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"h=
ttp://www.scisoft-consulting.com">http://www.scisoft-consulting.com</a>
</div></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 />

--e0cb4efa6e6cfe243904d84d679c--

.

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

On Fri, Mar 15, 2013 at 9:24 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 15 March 2013 16:07, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>> I have a slight confusion.  Which part is the -1?
>>
>
> I think we either (a) forward them all (if they exist for T; otherwise,
> don't compile), or (b) generate them all (in terms of == and <).
>

I might being naive. But I see optional as T's values + empty value, as
others have voiced here. So, the relops seem quite obvious to me with empty
value being the the smallest and the others coming after it in operator<.

So, (empty < engaged) = true /\ (engaged < empty) = false /\ (engaged1 <
engaged2) = (*engaged1 < *engaged2).

What am I missing?


>  --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
>
Regards,
--
Felipe Magno de Almeida

--

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



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 15, 2013 at 9:24 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 15 March 2013 16:07, To=
ny V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=
=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br>

</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">


<div><div><br>
</div></div>I have a slight confusion. =A0Which part is the -1?<br></blockq=
uote></div><div><br>I think we either (a) forward them all (if they exist f=
or T; otherwise, don&#39;t compile), or (b) generate them all (in terms of =
=3D=3D and &lt;).<br clear=3D"all">

</div></div></blockquote><div><br></div><div>I might being naive. But I see=
 optional as T&#39;s values + empty value, as others have voiced here. So, =
the relops seem quite obvious to me with empty value being the the smallest=
 and the others coming after it in operator&lt;.<br>

<br></div><div>So, (empty &lt; engaged) =3D true /\ (engaged &lt; empty) =
=3D false /\ (engaged1 &lt; engaged2) =3D (*engaged1 &lt; *engaged2).<br><b=
r></div><div>What am I missing?<br></div><div>=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">

<div class=3D"gmail_quote"><div>


</div></div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18=
476911404" target=3D"_blank">(847) 691-1404</a>

<p></p></div>

-- <br><br></blockquote><div><br></div><div>Regards, <br></div></div>--<br>=
Felipe Magno de Almeida
</div></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 />

--e89a8f643b6ed50f1b04dbd5abb4--

.

--001a11c24b7cc0a2a604dbd5e735
Content-Type: text/plain; charset=ISO-8859-1

On 3 May 2013 22:50, Felipe Magno de Almeida <felipe.m.almeida@gmail.com>wrote:

> On Fri, Mar 15, 2013 at 9:24 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
>
>> On 15 March 2013 16:07, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>>
>>> I have a slight confusion.  Which part is the -1?
>>>
>>
>> I think we either (a) forward them all (if they exist for T; otherwise,
>> don't compile), or (b) generate them all (in terms of == and <).
>>
>
> I might being naive. But I see optional as T's values + empty value, as
> others have voiced here. So, the relops seem quite obvious to me with empty
> value being the the smallest and the others coming after it in operator<.
>
> So, (empty < engaged) = true /\ (engaged < empty) = false /\ (engaged1 <
> engaged2) = (*engaged1 < *engaged2).
>
> What am I missing?
>
>
>
I don't think you're missing anything, that's how optional's op< is
specified to work currently. With the slight difference
that it's using std::less rather than the underlying op<.

--

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



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 3 May 2013 22:50, Felipe Magno de Almeida <span dir=3D"ltr">&lt;=
<a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank">felipe.m.al=
meida@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Fri, Mar 15, 2013 at 9:24 P=
M, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.c=
om" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 15 March 2013 16:07, Tony V E <span =
dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tva=
neerd@gmail.com</a>&gt;</span> wrote:<br>


</div><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div><br>
</div></div>I have a slight confusion. =A0Which part is the -1?<br></blockq=
uote></div><div><br>I think we either (a) forward them all (if they exist f=
or T; otherwise, don&#39;t compile), or (b) generate them all (in terms of =
=3D=3D and &lt;).<br clear=3D"all">


</div></div></blockquote><div><br></div></div><div>I might being naive. But=
 I see optional as T&#39;s values + empty value, as others have voiced here=
.. So, the relops seem quite obvious to me with empty value being the the sm=
allest and the others coming after it in operator&lt;.<br>


<br></div><div>So, (empty &lt; engaged) =3D true /\ (engaged &lt; empty) =
=3D false /\ (engaged1 &lt; engaged2) =3D (*engaged1 &lt; *engaged2).<br><b=
r></div><div>What am I missing?<br></div><div class=3D"im"><div><br><br></d=
iv></div>
</div></div></div></blockquote><div><br></div><div>I don&#39;t think you&#3=
9;re missing anything, that&#39;s how optional&#39;s op&lt; is specified to=
 work currently. With the slight difference<br>that it&#39;s using std::les=
s rather than the underlying op&lt;. <br>
</div></div><br></div></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 />

--001a11c24b7cc0a2a604dbd5e735--

.

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

On Fri, May 3, 2013 at 5:07 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 3 May 2013 22:50, Felipe Magno de Almeida <felipe.m.almeida@gmail.com>wrote:
>
>> On Fri, Mar 15, 2013 at 9:24 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
>>
>>> On 15 March 2013 16:07, Tony V E <tvaneerd@gmail.com> wrote:
>>>
>>>>
>>>> I have a slight confusion.  Which part is the -1?
>>>>
>>>
>>> I think we either (a) forward them all (if they exist for T; otherwise,
>>> don't compile), or (b) generate them all (in terms of == and <).
>>>
>>
>> I might being naive. But I see optional as T's values + empty value, as
>> others have voiced here. So, the relops seem quite obvious to me with empty
>> value being the the smallest and the others coming after it in operator<.
>>
>> So, (empty < engaged) = true /\ (engaged < empty) = false /\ (engaged1 <
>> engaged2) = (*engaged1 < *engaged2).
>>
>> What am I missing?
>>
>>
>>
> I don't think you're missing anything, that's how optional's op< is
> specified to work currently. With the slight difference
> that it's using std::less rather than the underlying op<.
>

While reading other threads related to relops I see what I'm missing. If
the other relops are implemented using the relops of T or by using
operator< and operator==. To which, if I were to vote (which I'm not), I
would delay these relops (>, <=, >=) until concepts are added to C++ and
then add these operators as forwarding to T.

--
Felipe Magno de Almeida

--

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



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 3, 2013 at 5:07 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On 3 May 2013 22:50, Felipe Ma=
gno de Almeida <span dir=3D"ltr">&lt;<a href=3D"mailto:felipe.m.almeida@gma=
il.com" target=3D"_blank">felipe.m.almeida@gmail.com</a>&gt;</span> wrote:<=
br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>On Fri, Mar 15, 2013 at 9:24 PM, Nevin Libe=
r <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br>




<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 15 March 2013 16:07, Tony V E <span =
dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tva=
neerd@gmail.com</a>&gt;</span> wrote:<br>




</div><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div><br>
</div></div>I have a slight confusion. =A0Which part is the -1?<br></blockq=
uote></div><div><br>I think we either (a) forward them all (if they exist f=
or T; otherwise, don&#39;t compile), or (b) generate them all (in terms of =
=3D=3D and &lt;).<br clear=3D"all">




</div></div></blockquote><div><br></div></div><div>I might being naive. But=
 I see optional as T&#39;s values + empty value, as others have voiced here=
.. So, the relops seem quite obvious to me with empty value being the the sm=
allest and the others coming after it in operator&lt;.<br>




<br></div><div>So, (empty &lt; engaged) =3D true /\ (engaged &lt; empty) =
=3D false /\ (engaged1 &lt; engaged2) =3D (*engaged1 &lt; *engaged2).<br><b=
r></div><div>What am I missing?<br></div><div><div><br><br></div></div>
</div></div></div></blockquote><div><br></div></div><div>I don&#39;t think =
you&#39;re missing anything, that&#39;s how optional&#39;s op&lt; is specif=
ied to work currently. With the slight difference<br>that it&#39;s using st=
d::less rather than the underlying op&lt;. <br>


</div></div></div></div></blockquote><div><br></div><div>While reading othe=
r threads related to relops I see what I&#39;m missing. If the other relops=
 are implemented using the relops of T or by using operator&lt; and operato=
r=3D=3D. To which, if I were to vote (which I&#39;m not), I would delay the=
se relops (&gt;, &lt;=3D, &gt;=3D) until concepts are added to C++ and then=
 add these operators as forwarding to T.<br>

</div></div><br>-- <br>Felipe Magno de Almeida
</div></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 />

--e89a8f5038e2af024e04dbd609dc--

.

--089e013d174a9a24a704dbd64410
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 3, 2013 at 4:16 PM, Felipe Magno de Almeida <
felipe.m.almeida@gmail.com> wrote:

> On Fri, May 3, 2013 at 5:07 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> On 3 May 2013 22:50, Felipe Magno de Almeida <felipe.m.almeida@gmail.com>wrote:
>>
>>> On Fri, Mar 15, 2013 at 9:24 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
>>>
>>>> On 15 March 2013 16:07, Tony V E <tvaneerd@gmail.com> wrote:
>>>>
>>>>>
>>>>> I have a slight confusion.  Which part is the -1?
>>>>>
>>>>
>>>> I think we either (a) forward them all (if they exist for T; otherwise,
>>>> don't compile), or (b) generate them all (in terms of == and <).
>>>>
>>>
>>> I might being naive. But I see optional as T's values + empty value, as
>>> others have voiced here. So, the relops seem quite obvious to me with empty
>>> value being the the smallest and the others coming after it in operator<.
>>>
>>> So, (empty < engaged) = true /\ (engaged < empty) = false /\ (engaged1 <
>>> engaged2) = (*engaged1 < *engaged2).
>>>
>>> What am I missing?
>>>
>>>
>>>
>> I don't think you're missing anything, that's how optional's op< is
>> specified to work currently. With the slight difference
>> that it's using std::less rather than the underlying op<.
>>
>
> While reading other threads related to relops I see what I'm missing. If
> the other relops are implemented using the relops of T or by using
> operator< and operator==. To which, if I were to vote (which I'm not), I
> would delay these relops (>, <=, >=) until concepts are added to C++ and
> then add these operators as forwarding to T.
>
> --
> Felipe Magno de Almeida
>
>
>
Why wait for concepts?  Why not forward now?

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.



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 4:16 PM, Felipe Magno de Almeida <span dir=
=3D"ltr">&lt;<a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank=
">felipe.m.almeida@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Fri, May 3, 2013 at 5:07 PM=
, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilain=
en@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> =
wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>On 3 May 2013 22:50, Felipe Magno de Almeid=
a <span dir=3D"ltr">&lt;<a href=3D"mailto:felipe.m.almeida@gmail.com" targe=
t=3D"_blank">felipe.m.almeida@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>On Fri, Mar 15, 2013 at 9:24 PM, Nevin Libe=
r <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br>





<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 15 March 2013 16:07, Tony V E <span =
dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tva=
neerd@gmail.com</a>&gt;</span> wrote:<br>





</div><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div><br>
</div></div>I have a slight confusion. =A0Which part is the -1?<br></blockq=
uote></div><div><br>I think we either (a) forward them all (if they exist f=
or T; otherwise, don&#39;t compile), or (b) generate them all (in terms of =
=3D=3D and &lt;).<br clear=3D"all">





</div></div></blockquote><div><br></div></div><div>I might being naive. But=
 I see optional as T&#39;s values + empty value, as others have voiced here=
.. So, the relops seem quite obvious to me with empty value being the the sm=
allest and the others coming after it in operator&lt;.<br>





<br></div><div>So, (empty &lt; engaged) =3D true /\ (engaged &lt; empty) =
=3D false /\ (engaged1 &lt; engaged2) =3D (*engaged1 &lt; *engaged2).<br><b=
r></div><div>What am I missing?<br></div><div><div><br><br></div></div>
</div></div></div></blockquote><div><br></div></div><div>I don&#39;t think =
you&#39;re missing anything, that&#39;s how optional&#39;s op&lt; is specif=
ied to work currently. With the slight difference<br>that it&#39;s using st=
d::less rather than the underlying op&lt;. <br>



</div></div></div></div></blockquote><div><br></div></div><div>While readin=
g other threads related to relops I see what I&#39;m missing. If the other =
relops are implemented using the relops of T or by using operator&lt; and o=
perator=3D=3D. To which, if I were to vote (which I&#39;m not), I would del=
ay these relops (&gt;, &lt;=3D, &gt;=3D) until concepts are added to C++ an=
d then add these operators as forwarding to T.<br>


</div></div><div class=3D"im"><br>-- <br>Felipe Magno de Almeida
</div></div></div>

<p></p>

<br></blockquote><div><br></div><div>Why wait for concepts?=A0 Why not forw=
ard now?<br><br>Tony<br>=A0<br></div></div><br></div></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 />

--089e013d174a9a24a704dbd64410--

.

--089e013a214a22f6d204dbd6684c
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 3, 2013 at 5:33 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
>
> On Fri, May 3, 2013 at 4:16 PM, Felipe Magno de Almeida <
> felipe.m.almeida@gmail.com> wrote:
>
>>
>>
[snip]


>  While reading other threads related to relops I see what I'm missing. If
>> the other relops are implemented using the relops of T or by using
>> operator< and operator==. To which, if I were to vote (which I'm not), I
>> would delay these relops (>, <=, >=) until concepts are added to C++ and
>> then add these operators as forwarding to T.
>>
>> --
>> Felipe Magno de Almeida
>>
>>
>>
> Why wait for concepts?  Why not forward now?
>

Actually, if these operators aren't defined now, with concepts it is way
more likely that they do not forward to T, but use < and == as basis. Since
that would be implied by concepts. I honestly find both ways good enough.
But it does seem just a little strange that optional<T> and T do not define
the same relation on operator> with the simple addition of the empty state.


> Tony
>

--
Felipe Magno de Almeida

--

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



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, May 3, 2013 at 5:33 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</spa=
n> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, May 3=
, 2013 at 4:16 PM, Felipe Magno de Almeida <span dir=3D"ltr">&lt;<a href=3D=
"mailto:felipe.m.almeida@gmail.com" target=3D"_blank">felipe.m.almeida@gmai=
l.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div><div><br></div></div></div></div></div></bl=
ockquote>

</div></div></div></div></div></blockquote><div>=A0</div><div>[snip]<br></d=
iv><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra">

<div class=3D"gmail_quote"><div><div class=3D"h5"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div><div>

</div>While reading other threads related to relops I see what I&#39;m miss=
ing. If the other relops are implemented using the relops of T or by using =
operator&lt; and operator=3D=3D. To which, if I were to vote (which I&#39;m=
 not), I would delay these relops (&gt;, &lt;=3D, &gt;=3D) until concepts a=
re added to C++ and then add these operators as forwarding to T.<br>




</div></div><div><br>-- <br>Felipe Magno de Almeida
</div></div></div>

<p></p>

<br></blockquote><div><br></div></div></div><div>Why wait for concepts?=A0 =
Why not forward now?<span class=3D"HOEnZb"><font color=3D"#888888"><br></fo=
nt></span></div></div></div></div></blockquote><div><br></div><div>Actually=
, if these operators aren&#39;t defined now, with concepts it is way more l=
ikely that they do not forward to T, but use &lt; and =3D=3D as basis. Sinc=
e that would be implied by concepts. I honestly find both ways good enough.=
 But it does seem just a little strange that optional&lt;T&gt; and T do not=
 define the same relation on operator&gt; with the simple addition of the e=
mpty state.<br>

</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div><span class=3D"HOEnZb">=
<font color=3D"#888888">Tony </font></span><br clear=3D"all">

</div></div></div></div></blockquote></div><br>-- <br>Felipe Magno de Almei=
da
</div></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 />

--089e013a214a22f6d204dbd6684c--

.

--047d7b3a897ad644eb04dbd6b9f3
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 3, 2013 at 4:43 PM, Felipe Magno de Almeida <
felipe.m.almeida@gmail.com> wrote:

>
> On Fri, May 3, 2013 at 5:33 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>>
>> On Fri, May 3, 2013 at 4:16 PM, Felipe Magno de Almeida <
>> felipe.m.almeida@gmail.com> wrote:
>>
>>>
>>>
> [snip]
>
>
>>  While reading other threads related to relops I see what I'm missing.
>>> If the other relops are implemented using the relops of T or by using
>>> operator< and operator==. To which, if I were to vote (which I'm not), I
>>> would delay these relops (>, <=, >=) until concepts are added to C++ and
>>> then add these operators as forwarding to T.
>>>
>>> --
>>> Felipe Magno de Almeida
>>>
>>>
>>>
>> Why wait for concepts?  Why not forward now?
>>
>
> Actually, if these operators aren't defined now, with concepts it is way
> more likely that they do not forward to T, but use < and == as basis. Since
> that would be implied by concepts. I honestly find both ways good enough.
> But it does seem just a little strange that optional<T> and T do not define
> the same relation on operator> with the simple addition of the empty state.
>
>
>> Tony
>>
>
> --
> Felipe Magno de Almeida
>
> --
>
>
OK, that gets into the big debate about concepts and whether containers
will require a true proper ordering or not.  I don't really want to get
into that debate here.  (If the end result is that more T's are made with
proper ordering, then it won't matter how optional defines things -
forwarding still works fine.)

Basically, if T doesn't model the proper concept, why should optional<T>?
(Will people start wrapping their classes in optional or tuple just to fix
their concept problems!?  I'd rather they fix T itself.)

Also, I think it is interesting to note that the debate (IIUC) indicates
that there *is* code out there that uses "improper" ordering, some of it
maybe even on purpose.

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.



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 4:43 PM, Felipe Magno de Almeida <span dir=
=3D"ltr">&lt;<a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank=
">felipe.m.almeida@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote"><div class=3D"im">On Fri,=
 May 3, 2013 at 5:33 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:t=
vaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrot=
e:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Fri,=
 May 3, 2013 at 4:16 PM, Felipe Magno de Almeida <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank">felipe.m.almeid=
a@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div><div><br></div></div></d=
iv></div>
</div></blockquote>

</div></div></div></div></div></blockquote><div>=A0</div></div><div>[snip]<=
br></div><div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">

<div class=3D"gmail_quote"><div><div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote">
<div><div>

</div>While reading other threads related to relops I see what I&#39;m miss=
ing. If the other relops are implemented using the relops of T or by using =
operator&lt; and operator=3D=3D. To which, if I were to vote (which I&#39;m=
 not), I would delay these relops (&gt;, &lt;=3D, &gt;=3D) until concepts a=
re added to C++ and then add these operators as forwarding to T.<br>





</div></div><div><br>-- <br>Felipe Magno de Almeida
</div></div></div>

<p></p>

<br></blockquote><div><br></div></div></div><div>Why wait for concepts?=A0 =
Why not forward now?<span><font color=3D"#888888"><br></font></span></div><=
/div></div></div></blockquote><div><br></div></div><div>Actually, if these =
operators aren&#39;t defined now, with concepts it is way more likely that =
they do not forward to T, but use &lt; and =3D=3D as basis. Since that woul=
d be implied by concepts. I honestly find both ways good enough. But it doe=
s seem just a little strange that optional&lt;T&gt; and T do not define the=
 same relation on operator&gt; with the simple addition of the empty state.=
<br>


</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><spa=
n><font color=3D"#888888">Tony </font></span><br clear=3D"all">


</div></div></div></div></blockquote></div><div class=3D"im"><br>-- <br>Fel=
ipe Magno de Almeida
</div></div></div>

<p></p>

--<br><br></blockquote><div>=A0</div><div>OK, that gets into the big debate=
 about concepts and whether containers will require a true proper ordering =
or not.=A0 I don&#39;t really want to get into that debate here.=A0 (If the=
 end result is that more T&#39;s are made with proper ordering, then it won=
&#39;t matter how optional defines things - forwarding still works fine.)<b=
r>
<br>Basically, if T doesn&#39;t model the proper concept, why should option=
al&lt;T&gt;?=A0 (Will people start wrapping their classes in optional or tu=
ple just to fix their concept problems!?=A0 I&#39;d rather they fix T itsel=
f.)<br>
<br>Also, I think it is interesting to note that the debate (IIUC) indicate=
s that there *is* code out there that uses &quot;improper&quot; ordering, s=
ome of it maybe even on purpose.<br><br></div><div>Tony<br></div></div>
</div></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 />

--047d7b3a897ad644eb04dbd6b9f3--

.

--089e0112cbeecaf6d104dbd6dd13
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 3, 2013 at 6:06 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
>
> On Fri, May 3, 2013 at 4:43 PM, Felipe Magno de Almeida <
> felipe.m.almeida@gmail.com> wrote:
>
>>
>> On Fri, May 3, 2013 at 5:33 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Fri, May 3, 2013 at 4:16 PM, Felipe Magno de Almeida <
>>> felipe.m.almeida@gmail.com> wrote:
>>>
>>>>
>>>>
>> [snip]
>>
>>
>>>   While reading other threads related to relops I see what I'm missing.
>>>> If the other relops are implemented using the relops of T or by using
>>>> operator< and operator==. To which, if I were to vote (which I'm not), I
>>>> would delay these relops (>, <=, >=) until concepts are added to C++ and
>>>> then add these operators as forwarding to T.
>>>>
>>>> --
>>>> Felipe Magno de Almeida
>>>>
>>>>
>>>>
>>> Why wait for concepts?  Why not forward now?
>>>
>>
>> Actually, if these operators aren't defined now, with concepts it is way
>> more likely that they do not forward to T, but use < and == as basis. Since
>> that would be implied by concepts. I honestly find both ways good enough.
>> But it does seem just a little strange that optional<T> and T do not define
>> the same relation on operator> with the simple addition of the empty state.
>>
>>
>>> Tony
>>>
>>
>> --
>> Felipe Magno de Almeida
>>
>> --
>>
>>
> OK, that gets into the big debate about concepts and whether containers
> will require a true proper ordering or not.  I don't really want to get
> into that debate here.  (If the end result is that more T's are made with
> proper ordering, then it won't matter how optional defines things -
> forwarding still works fine.)
>
> Basically, if T doesn't model the proper concept, why should optional<T>?
> (Will people start wrapping their classes in optional or tuple just to fix
> their concept problems!?  I'd rather they fix T itself.)
>
> Also, I think it is interesting to note that the debate (IIUC) indicates
> that there *is* code out there that uses "improper" ordering, some of it
> maybe even on purpose.
>
>
Btw, can you or anyone else show such a code? While I do think we should at
least discuss what to do with those, it is a bit difficult to weight a
totally theoretical problem, so hard data would be of help.

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

--

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



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 3, 2013 at 6:06 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On Fri, May 3, 201=
3 at 4:43 PM, Felipe Magno de Almeida <span dir=3D"ltr">&lt;<a href=3D"mail=
to:felipe.m.almeida@gmail.com" target=3D"_blank">felipe.m.almeida@gmail.com=
</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote"><div>On Fri, May 3, 2013 =
at 5:33 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail=
..com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br>




<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Fri,=
 May 3, 2013 at 4:16 PM, Felipe Magno de Almeida <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank">felipe.m.almeid=
a@gmail.com</a>&gt;</span> wrote:<br>





<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div><div><br></div></div></d=
iv></div>


</div></blockquote>

</div></div></div></div></div></blockquote><div>=A0</div></div><div>[snip]<=
br></div><div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">


<div dir=3D"ltr"><div class=3D"gmail_extra">

<div class=3D"gmail_quote"><div><div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote">


<div><div>

</div>While reading other threads related to relops I see what I&#39;m miss=
ing. If the other relops are implemented using the relops of T or by using =
operator&lt; and operator=3D=3D. To which, if I were to vote (which I&#39;m=
 not), I would delay these relops (&gt;, &lt;=3D, &gt;=3D) until concepts a=
re added to C++ and then add these operators as forwarding to T.<br>







</div></div><div><br>-- <br>Felipe Magno de Almeida
</div></div></div>

<p></p>

<br></blockquote><div><br></div></div></div><div>Why wait for concepts?=A0 =
Why not forward now?<span><font color=3D"#888888"><br></font></span></div><=
/div></div></div></blockquote><div><br></div></div><div>Actually, if these =
operators aren&#39;t defined now, with concepts it is way more likely that =
they do not forward to T, but use &lt; and =3D=3D as basis. Since that woul=
d be implied by concepts. I honestly find both ways good enough. But it doe=
s seem just a little strange that optional&lt;T&gt; and T do not define the=
 same relation on operator&gt; with the simple addition of the empty state.=
<br>




</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><spa=
n><font color=3D"#888888">Tony </font></span><br clear=3D"all">




</div></div></div></div></blockquote></div><div><br>-- <br>Felipe Magno de =
Almeida
</div></div></div>

<p></p>

--<br><br></blockquote><div>=A0</div></div><div>OK, that gets into the big =
debate about concepts and whether containers will require a true proper ord=
ering or not.=A0 I don&#39;t really want to get into that debate here.=A0 (=
If the end result is that more T&#39;s are made with proper ordering, then =
it won&#39;t matter how optional defines things - forwarding still works fi=
ne.)<br>


<br>Basically, if T doesn&#39;t model the proper concept, why should option=
al&lt;T&gt;?=A0 (Will people start wrapping their classes in optional or tu=
ple just to fix their concept problems!?=A0 I&#39;d rather they fix T itsel=
f.)<br>


<br>Also, I think it is interesting to note that the debate (IIUC) indicate=
s that there *is* code out there that uses &quot;improper&quot; ordering, s=
ome of it maybe even on purpose.<span class=3D"HOEnZb"><font color=3D"#8888=
88"><br>

<br></font></span></div></div></div></div></blockquote><div><br></div><div>=
Btw, can you or anyone else show such a code? While I do think we should at=
 least discuss what to do with those, it is a bit difficult to weight a tot=
ally theoretical problem, so hard data would be of help.<br>

</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></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 />

--089e0112cbeecaf6d104dbd6dd13--

.

--089e013a214a3701eb04dbd72fc6
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 3, 2013 at 6:06 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
>
> On Fri, May 3, 2013 at 4:43 PM, Felipe Magno de Almeida <
> felipe.m.almeida@gmail.com> wrote:
>
Actually, if these operators aren't defined now, with concepts it is way
>> more likely that they do not forward to T, but use < and == as basis. Since
>> that would be implied by concepts. I honestly find both ways good enough.
>> But it does seem just a little strange that optional<T> and T do not define
>> the same relation on operator> with the simple addition of the empty state.
>>
>>
>>> Tony
>>>
>>
>> --
>> Felipe Magno de Almeida
>>
>> --
>>
>>
> OK, that gets into the big debate about concepts and whether containers
> will require a true proper ordering or not.  I don't really want to get
> into that debate here.  (If the end result is that more T's are made with
> proper ordering, then it won't matter how optional defines things -
> forwarding still works fine.)
>
> Basically, if T doesn't model the proper concept, why should optional<T>?
> (Will people start wrapping their classes in optional or tuple just to fix
> their concept problems!?  I'd rather they fix T itself.)
>

I believe I agree. If T doesn't define its relops correctly and/or
consistent with each other, then optional<T> shouldn't try to be correct
and consistent (by using <). And too there might be performance
considerations, where calling operator>(T,T) to define
operator<(optional<T>, ...) might actually be more efficient than
implementing it using operator<. I don't think consistency with containers
are worth, specially since a sequence of T's is a quite a different beast
than a (T or empty). And I believe it might be useful that the ordering
stays the same for engaged optional<T>s as for Ts for all relops.


> Also, I think it is interesting to note that the debate (IIUC) indicates
> that there *is* code out there that uses "improper" ordering, some of it
> maybe even on purpose.
>
> Tony
>

--
Felipe Magno de Almeida

--

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



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 3, 2013 at 6:06 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div><div>On Fri, May 3, 2013 at 4:4=
3 PM, Felipe Magno de Almeida <span dir=3D"ltr">&lt;<a href=3D"mailto:felip=
e.m.almeida@gmail.com" target=3D"_blank">felipe.m.almeida@gmail.com</a>&gt;=
</span> wrote: <br>

</div></div></div></div></div></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">

<div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><div><div></div></div><div>Actually, if these operators =
aren&#39;t defined now, with concepts it is way more likely that they do no=
t forward to T, but use &lt; and =3D=3D as basis. Since that would be impli=
ed by concepts. I honestly find both ways good enough. But it does seem jus=
t a little strange that optional&lt;T&gt; and T do not define the same rela=
tion on operator&gt; with the simple addition of the empty state.<br>




</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><spa=
n><font color=3D"#888888">Tony </font></span><br clear=3D"all">




</div></div></div></div></blockquote></div><div><br>-- <br>Felipe Magno de =
Almeida
</div></div></div>

<p></p></div></div>

--<br><br></blockquote><div>=A0</div><div>OK, that gets into the big debate=
 about concepts and whether containers will require a true proper ordering =
or not.=A0 I don&#39;t really want to get into that debate here.=A0 (If the=
 end result is that more T&#39;s are made with proper ordering, then it won=
&#39;t matter how optional defines things - forwarding still works fine.)<b=
r>


<br>Basically, if T doesn&#39;t model the proper concept, why should option=
al&lt;T&gt;?=A0 (Will people start wrapping their classes in optional or tu=
ple just to fix their concept problems!?=A0 I&#39;d rather they fix T itsel=
f.)<br>

</div></div></div></div></blockquote><div><br></div><div>I believe I agree.=
 If T doesn&#39;t define its relops correctly and/or consistent with each o=
ther, then optional&lt;T&gt; shouldn&#39;t try to be correct and consistent=
 (by using &lt;). And too there might be performance considerations, where =
calling operator&gt;(T,T) to define operator&lt;(optional&lt;T&gt;, ...) mi=
ght actually be more efficient than implementing it using operator&lt;. I d=
on&#39;t think consistency with containers are worth, specially since a seq=
uence of T&#39;s is a quite a different beast than a (T or empty). And I be=
lieve it might be useful that the ordering stays the same for engaged optio=
nal&lt;T&gt;s as for Ts for all relops.<br>

</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div>Also, I think it is int=
eresting to note that the debate (IIUC) indicates that there *is* code out =
there that uses &quot;improper&quot; ordering, some of it maybe even on pur=
pose.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

<br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><div=
>Tony<br></div></font></span></div>
</div></div></blockquote></div><br>--<br>Felipe Magno de Almeida
</div></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 />

--089e013a214a3701eb04dbd72fc6--

.

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

On 4 May 2013 00:06, Tony V E <tvaneerd@gmail.com> wrote:

>
> Basically, if T doesn't model the proper concept, why should optional<T>?
> (Will people start wrapping their classes in optional or tuple just to fix
> their concept problems!?  I'd rather they fix T itself.)
>

Interesting point. Maybe people will. And if we decide to one day provide
an identity wrapper that is convertible to and
from T implicitly and provides the additional relational operators so that
I merely need to write op< for my T, I will accept such
a wrapper in a heartbeat. That would be a very nice and useful addition,
and it would be consistent with optional
and tuple. That, to me, seems like a very attractive evolution path.


Also, I think it is interesting to note that the debate (IIUC) indicates
> that there *is* code out there that uses "improper" ordering, some of it
> maybe even on purpose.
>
>
Again, it would be really nice to see examples of such code. And it's again
another matter whether library
wrappers should even support such code.

--

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



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 May 2013 00:06, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div>Basically, if T doesn&#39;t model the p=
roper concept, why should optional&lt;T&gt;?=A0 (Will people start wrapping=
 their classes in optional or tuple just to fix their concept problems!?=A0=
 I&#39;d rather they fix T itself.)<br>
</div></div></div></div></blockquote><div><br></div><div>Interesting point.=
 Maybe people will. And if we decide to one day provide an identity wrapper=
 that is convertible to and <br>from T implicitly and provides the addition=
al relational operators so that I merely need to write op&lt; for my T, I w=
ill accept such<br>
a wrapper in a heartbeat. That would be a very nice and useful addition, an=
d it would be consistent with optional<br>and tuple. That, to me, seems lik=
e a very attractive evolution path.<br><br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>
Also, I think it is interesting to note that the debate (IIUC) indicates th=
at there *is* code out there that uses &quot;improper&quot; ordering, some =
of it maybe even on purpose.<span class=3D"HOEnZb"><font color=3D"#888888">=
<br>
<br></font></span></div></div></div></div></blockquote><div><br></div><div>=
Again, it would be really nice to see examples of such code. And it&#39;s a=
gain another matter whether library<br>wrappers should even support such co=
de.<br>
</div></div><br></div></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 />

--e89a8ff2511c056a4204dbd91e8e--

.

--047d7b3a897ad42ea304dbdaaaff
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 3, 2013 at 7:57 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 4 May 2013 00:06, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>> Basically, if T doesn't model the proper concept, why should
>> optional<T>?  (Will people start wrapping their classes in optional or
>> tuple just to fix their concept problems!?  I'd rather they fix T itself.)
>>
>
> Interesting point. Maybe people will. And if we decide to one day provide
> an identity wrapper that is convertible to and
> from T implicitly and provides the additional relational operators so that
> I merely need to write op< for my T, I will accept such
> a wrapper in a heartbeat. That would be a very nice and useful addition,
> and it would be consistent with optional
> and tuple. That, to me, seems like a very attractive evolution path.
>
>
I think I'd rather have something like

class Foo {
....
operator>() = default;
};

(or really operator> and all the rest  = default.  Not sure what syntax
that would be)


Of course I wrapper would also be useful for classes that you can't change.




>  Also, I think it is interesting to note that the debate (IIUC) indicates
>> that there *is* code out there that uses "improper" ordering, some of it
>> maybe even on purpose.
>>
>>
> Again, it would be really nice to see examples of such code. And it's
> again another matter whether library
> wrappers should even support such code.
>
>
I didn't follow the old concept saga, but my understanding was that
concept-izing the std library required compromises otherwise lots of code
broke.  I have no idea what that code was, but it is always mentioned with
respect to WellOrdered vs LessThanComparable, etc. (or whatever the proper
names are)

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.



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 7:57 PM, Ville Voutilainen <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville=
..voutilainen@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div>On 4 May 2013 00:06, Tony V E <=
span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank=
">tvaneerd@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div>Basically, if T doesn&#39;t model the p=
roper concept, why should optional&lt;T&gt;?=A0 (Will people start wrapping=
 their classes in optional or tuple just to fix their concept problems!?=A0=
 I&#39;d rather they fix T itself.)<br>


</div></div></div></div></blockquote><div><br></div></div><div>Interesting =
point. Maybe people will. And if we decide to one day provide an identity w=
rapper that is convertible to and <br>from T implicitly and provides the ad=
ditional relational operators so that I merely need to write op&lt; for my =
T, I will accept such<br>


a wrapper in a heartbeat. That would be a very nice and useful addition, an=
d it would be consistent with optional<br>and tuple. That, to me, seems lik=
e a very attractive evolution path.<br><br></div></div></div></div></blockq=
uote>

<div><br></div><div>I think I&#39;d rather have something like</div><div><b=
r></div><div>class Foo {</div><div>...</div><div>operator&gt;() =3D default=
;</div><div>};</div><div><br></div><div>(or really operator&gt; and all the=
 rest =A0=3D default. =A0Not sure what syntax that would be)</div>
<div><br></div><div><br></div><div>Of course I wrapper would also be useful=
 for classes that you can&#39;t change.</div><div><br></div><div><br></div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>
Also, I think it is interesting to note that the debate (IIUC) indicates th=
at there *is* code out there that uses &quot;improper&quot; ordering, some =
of it maybe even on purpose.<span><font color=3D"#888888"><br>
<br></font></span></div></div></div></div></blockquote><div><br></div></div=
><div>Again, it would be really nice to see examples of such code. And it&#=
39;s again another matter whether library<br>wrappers should even support s=
uch code.<br>


</div></div><br></div></div><div><div>

<p></p>

</div></div></blockquote></div><br></div><div class=3D"gmail_extra">I didn&=
#39;t follow the old concept saga, but my understanding was that concept-iz=
ing the std library required compromises otherwise lots of code broke. =A0I=
 have no idea what that code was, but it is always mentioned with respect t=
o WellOrdered vs LessThanComparable, etc. (or whatever the proper names are=
)</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Tony</div><=
div class=3D"gmail_extra"><br></div></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 />

--047d7b3a897ad42ea304dbdaaaff--

.