Topic: optional Rev.4 (N3672): What was the
Author: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Wed, 01 May 2013 21:24:28 +0900
Raw View
On 2013/05/01 19:53 +0900, DeadMG wrote:
> Basically, because no matter what you do with them, they produce
> unintuitive surprising results, and the Committee could not agree on which
> set of utter insanity it preferred, so it chose to simply drop them.
I'm not sure what was counted as "unintuitive surprising results" if
std::optional<T> provided operator!= which is defined as !operator== .
I can guess only this one; a problem when T has a non-standard
relationship between == and !=. (The link is for < and >, though.)
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/GqTeK3cseD8/NFUKmdVwhE0J
Right?
--
k_satoda
--
---
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.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 17:17:58 +0300
Raw View
--089e013a1978f2220e04dba8c864
Content-Type: text/plain; charset=ISO-8859-1
On May 1, 2013 3:24 PM, "Kazutoshi Satoda" <k_satoda@f2.dion.ne.jp> wrote:
>
> On 2013/05/01 19:53 +0900, DeadMG wrote:
> > Basically, because no matter what you do with them, they produce
> > unintuitive surprising results, and the Committee could not agree on
which
> > set of utter insanity it preferred, so it chose to simply drop them.
>
> I'm not sure what was counted as "unintuitive surprising results" if
> std::optional<T> provided operator!= which is defined as !operator== .
>
> I can guess only this one; a problem when T has a non-standard
> relationship between == and !=. (The link is for < and >, though.)
>
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/GqTeK3cseD8/NFUKmdVwhE0J
>
> Right?
I guess so. The relational operators like less/greater etc. are one thing.
But not having != has NO excuse. We should not support brain-damaged types
for which !(x==y) isn't the same as x!=y.
--
---
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.
--089e013a1978f2220e04dba8c864
Content-Type: text/html; charset=ISO-8859-1
<p><br>
On May 1, 2013 3:24 PM, "Kazutoshi Satoda" <<a href="mailto:k_satoda@f2.dion.ne.jp">k_satoda@f2.dion.ne.jp</a>> wrote:<br>
><br>
> On 2013/05/01 19:53 +0900, DeadMG wrote:<br>
> > Basically, because no matter what you do with them, they produce<br>
> > unintuitive surprising results, and the Committee could not agree on which<br>
> > set of utter insanity it preferred, so it chose to simply drop them.<br>
><br>
> I'm not sure what was counted as "unintuitive surprising results" if<br>
> std::optional<T> provided operator!= which is defined as !operator== .<br>
><br>
> I can guess only this one; a problem when T has a non-standard<br>
> relationship between == and !=. (The link is for < and >, though.)<br>
> <a href="https://groups.google.com/a/isocpp.org/d/msg/std-discussion/GqTeK3cseD8/NFUKmdVwhE0J">https://groups.google.com/a/isocpp.org/d/msg/std-discussion/GqTeK3cseD8/NFUKmdVwhE0J</a><br>
><br>
> Right?</p>
<p>I guess so. The relational operators like less/greater etc. are one thing. But not having != has NO excuse. We should not support brain-damaged types for which !(x==y) isn't the same as x!=y.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--089e013a1978f2220e04dba8c864--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 1 May 2013 08:42:06 -0700 (PDT)
Raw View
------=_Part_984_882250.1367422926798
Content-Type: text/plain; charset=ISO-8859-1
Whether or not != was different to > is irrelevant. What matters is that
the Committee simply did not have the time to think about it. It was either
"Cut everything except < and ==" or "Drop optional for C++14 due to time
pressures". The session discussing optional already overran substantially.
--
---
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_984_882250.1367422926798
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Whether or not !=3D was different to > is irrelevant. What matters is th=
at the Committee simply did not have the time to think about it. It was eit=
her "Cut everything except < and =3D=3D" or "Drop optional for C++14 due=
to time pressures". The session discussing optional already overran substa=
ntially.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
------=_Part_984_882250.1367422926798--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 21:21:07 +0300
Raw View
--14dae93b5e3682f48e04dbac2ed9
Content-Type: text/plain; charset=ISO-8859-1
On 1 May 2013 18:42, DeadMG <wolfeinstein@gmail.com> wrote:
> Whether or not != was different to > is irrelevant. What matters is that
> the Committee simply did not have the time to think about it.
I think it's very much relevant. The less-than comparison (and its ilk) is
much more controversial
than the equality/inequality comparison. What we have in the C++14 CD
working draft is
known to be broken wrt. ==/!=, and the situation will not survive ballot
unmodified.
It was either "Cut everything except < and ==" or "Drop optional for C++14
> due to time pressures". The session discussing optional already overran
> substantially.
>
> The overrun was partly caused by drive-by-redesign. The committee should
perhaps try and avoid
the tendency to redesign things on the fly.
--
---
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.
--14dae93b5e3682f48e04dbac2ed9
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 1 May 2013 18:42, DeadMG <span dir=3D"ltr"><<a href=3D"mailto=
:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Whether or not !=3D was different to > is=
irrelevant. What matters is that the Committee simply did not have the tim=
e to think about it. </blockquote>
<div><br></div><div>I think it's very much relevant. The less-than comp=
arison (and its ilk) is much more controversial<br></div><div>than the equa=
lity/inequality comparison. What we have in the C++14 CD working draft is<b=
r>
</div><div>known to be broken wrt. =3D=3D/!=3D, and the situation will not =
survive ballot unmodified.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It w=
as either "Cut everything except < and =3D=3D" or "Drop o=
ptional for C++14 due to time pressures". The session discussing optio=
nal already overran substantially.
<div class=3D"HOEnZb"><div class=3D"h5"><p></p>
</div></div></blockquote><div>The overrun was partly caused by drive-by-red=
esign. The committee should perhaps try and avoid<br></div><div>the tendenc=
y to redesign things on the fly.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--14dae93b5e3682f48e04dbac2ed9--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 1 May 2013 11:28:40 -0700 (PDT)
Raw View
------=_Part_5222_4897554.1367432920596
Content-Type: text/plain; charset=ISO-8859-1
I wasn't present for the other sessions covering optional so I can't
comment on any drive-by-redesigning.
What we have in the C++14 CD working draft is known to be broken wrt.
> ==/!=, and the situation will not survive ballot unmodified.
Feel free to enlighten me, since I was at the final LEWG meeting and no
issues wrt. ==/!= were raised.
Ultimately, the reason for the overrun is also irrelevant. The Committee
simply could not spare any more time and that's that.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_5222_4897554.1367432920596
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I wasn't present for the other sessions covering optional so I can't commen=
t on any drive-by-redesigning.<div><br></div><div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border=
-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1e=
x;">What we have in the C++14 CD working draft is known to be broken wrt. =
=3D=3D/!=3D, and the situation will not survive ballot unmodified.</blockqu=
ote><div><br></div><div>Feel free to enlighten me, since I was at the final=
LEWG meeting and no issues wrt. =3D=3D/!=3D were raised.</div><div><br></d=
iv><div>Ultimately, the reason for the overrun is also irrelevant. The Comm=
ittee simply could not spare any more time and that's that. </div></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
------=_Part_5222_4897554.1367432920596--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 21:45:16 +0300
Raw View
--047d7b33d31cd2a9ef04dbac8445
Content-Type: text/plain; charset=ISO-8859-1
On 1 May 2013 21:28, DeadMG <wolfeinstein@gmail.com> wrote:
> What we have in the C++14 CD working draft is known to be broken wrt.
> ==/!=, and the situation will not survive ballot unmodified.
>
> Feel free to enlighten me, since I was at the final LEWG meeting and no
> issues wrt. ==/!= were raised.
>
That's because sometimes people need to make concessions to get a
fundamental vocabulary
type into a working draft, and fix its issues later.
Not being able to say opt1 != opt2 is utterly brain-damaged, and I'm
shocked if there are people
on this planet who have trouble comprehending that.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7b33d31cd2a9ef04dbac8445
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 1 May 2013 21:28, DeadMG <span dir=3D"ltr"><<a href=3D"mailto=
:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">What we have in the C++14 CD working draft i=
s known to be broken wrt. =3D=3D/!=3D, and the situation will not survive b=
allot unmodified.<div>
<div class=3D"im"><div><br></div></div><div>Feel free to enlighten me, sinc=
e I was at the final LEWG meeting and no issues wrt. =3D=3D/!=3D were raise=
d.</div></div></blockquote><div><br><br></div><div>That's because somet=
imes people need to make concessions to get a fundamental vocabulary<br>
type into a working draft, and fix its issues later.<br><br></div><div>Not =
being able to say opt1 !=3D opt2 is utterly brain-damaged, and I'm shoc=
ked if there are people<br>on this planet who have trouble comprehending th=
at.<br>
</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b33d31cd2a9ef04dbac8445--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 1 May 2013 11:51:59 -0700 (PDT)
Raw View
------=_Part_8552_24711551.1367434319697
Content-Type: text/plain; charset=ISO-8859-1
It has nothing to do with the desirability or not of !=. It was purely
about scheduling. That's it.
And secondly, frankly, you can complain all you like, but it's done. The
question is answered. It was removed for scheduling reasons. So unless you
want to go and travel back in time and change the proceedings so that there
was more time to discuss optional, there's no point harping on about how
brain-damaged it is. The situation is not brain-damaged at all. The
scheduling didn't permit spending more time on it. It's just that simple.
I'm shocked if there are people on this planet who can't comprehend that
you have to stop when you run out of time, regardless of how much better
things might be if you had more time.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_8552_24711551.1367434319697
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
It has nothing to do with the desirability or not of !=3D. It was purely ab=
out scheduling. That's it.<div><br></div><div>And secondly, frankly, you ca=
n complain all you like, but it's done. The question is answered. It was re=
moved for scheduling reasons. So unless you want to go and travel back in t=
ime and change the proceedings so that there was more time to discuss optio=
nal, there's no point harping on about how brain-damaged it is. The situati=
on is not brain-damaged at all. The scheduling didn't permit spending more =
time on it. It's just that simple. I'm shocked if there are people on this =
planet who can't comprehend that you have to stop when you run out of time,=
regardless of how much better things might be if you had more time.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
------=_Part_8552_24711551.1367434319697--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 22:12:35 +0300
Raw View
--089e012948028febdf04dbace6db
Content-Type: text/plain; charset=ISO-8859-1
On 1 May 2013 21:51, DeadMG <wolfeinstein@gmail.com> wrote:
> It has nothing to do with the desirability or not of !=. It was purely
> about scheduling. That's it.
The original proposal had a perfectly sane definition of operator!=. The
committee decided
to fiddle with it. The scheduling problems were caused by that fiddling,
that's it.
>
> And secondly, frankly, you can complain all you like, but it's done. The
> question is answered. It was removed for scheduling
>
Oh, rest assured it's not done. As I said multiple times, the current
status quo won't pass the ballot
uncommented.
--
---
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.
--089e012948028febdf04dbace6db
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 1 May 2013 21:51, DeadMG <span dir=3D"ltr"><<a href=3D"mailto=
:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It has nothing to do with the desirability o=
r not of !=3D. It was purely about scheduling. That's it.</blockquote><=
div>
<br></div><div>The original proposal had a perfectly sane definition of ope=
rator!=3D. The committee decided<br>to fiddle with it. The scheduling probl=
ems were caused by that fiddling, that's it.<br>=A0<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div><br></div><div>And secondly, frankly, you can complain all you like, b=
ut it's done. The question is answered. It was removed for scheduling <=
/div></blockquote><div><br></div><div>Oh, rest assured it's not done. A=
s I said multiple times, the current status quo won't pass the ballot<b=
r>
uncommented.<br><br><br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e012948028febdf04dbace6db--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Wed, 1 May 2013 14:23:29 -0500
Raw View
--089e01176f71eb85e404dbad0f50
Content-Type: text/plain; charset=ISO-8859-1
+1.
I would say that more than one national body will request this situation to
be solved.
On Wed, May 1, 2013 at 2:12 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 1 May 2013 21:51, DeadMG <wolfeinstein@gmail.com> wrote:
>
>> It has nothing to do with the desirability or not of !=. It was purely
>> about scheduling. That's it.
>
>
> The original proposal had a perfectly sane definition of operator!=. The
> committee decided
> to fiddle with it. The scheduling problems were caused by that fiddling,
> that's it.
>
>
>>
>> And secondly, frankly, you can complain all you like, but it's done. The
>> question is answered. It was removed for scheduling
>>
>
> Oh, rest assured it's not done. As I said multiple times, the current
> status quo won't pass the ballot
> uncommented.
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To 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.
--089e01176f71eb85e404dbad0f50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">+1.<div><br></div><div style>I would say that more than on=
e national body will request this situation to be solved.</div><div class=
=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, May 1, 2013 at =
2:12 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.vo=
utilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>><=
/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 class=3D"im">On 1 May 2013 21:5=
1, DeadMG <span dir=3D"ltr"><<a href=3D"mailto:wolfeinstein@gmail.com" t=
arget=3D"_blank">wolfeinstein@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It has nothing to do with the desirability o=
r not of !=3D. It was purely about scheduling. That's it.</blockquote><=
div>
<br></div></div><div>The original proposal had a perfectly sane definition =
of operator!=3D. The committee decided<br>to fiddle with it. The scheduling=
problems were caused by that fiddling, that's it.<br>=A0<br></div><div=
class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div><br></div><div>And secondly, frankly, you can complain all you like, b=
ut it's done. The question is answered. It was removed for scheduling <=
/div></blockquote><div><br></div></div><div>Oh, rest assured it's not d=
one. As I said multiple times, the current status quo won't pass the ba=
llot<br>
uncommented.<br><br><br></div></div><br></div></div><div class=3D"HOEnZb"><=
div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div><br></d=
iv></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e01176f71eb85e404dbad0f50--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 1 May 2013 15:57:31 -0400
Raw View
--089e01184510431aa604dbad87c1
Content-Type: text/plain; charset=ISO-8859-1
Potentially in different ways!
On Wed, May 1, 2013 at 3:23 PM, J. Daniel Garcia
<josedaniel.garcia@uc3m.es>wrote:
> +1.
>
> I would say that more than one national body will request this situation
> to be solved.
>
>
> On Wed, May 1, 2013 at 2:12 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>>
>>
>> On 1 May 2013 21:51, DeadMG <wolfeinstein@gmail.com> wrote:
>>
>>> It has nothing to do with the desirability or not of !=. It was purely
>>> about scheduling. That's it.
>>
>>
>> The original proposal had a perfectly sane definition of operator!=. The
>> committee decided
>> to fiddle with it. The scheduling problems were caused by that fiddling,
>> that's it.
>>
>>
>>>
>>> And secondly, frankly, you can complain all you like, but it's done. The
>>> question is answered. It was removed for scheduling
>>>
>>
>> Oh, rest assured it's not done. As I said multiple times, the current
>> status quo won't pass the ballot
>> uncommented.
>>
>>
>>
>>
--
---
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.
--089e01184510431aa604dbad87c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Potentially in different ways!<br><div><div class=3D"gmail=
_extra"><br><br><div class=3D"gmail_quote">On Wed, May 1, 2013 at 3:23 PM, =
J. Daniel Garcia <span dir=3D"ltr"><<a href=3D"mailto:josedaniel.garcia@=
uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.es</a>></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">+1.<div><br></div><div>I wo=
uld say that more than one national body will request this situation to be =
solved.</div>
<div><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gma=
il_quote">On Wed, May 1, 2013 at 2:12 PM, Ville Voutilainen <span dir=3D"lt=
r"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vil=
le.voutilainen@gmail.com</a>></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 1 May 2013 21:51, DeadMG <sp=
an dir=3D"ltr"><<a href=3D"mailto:wolfeinstein@gmail.com" target=3D"_bla=
nk">wolfeinstein@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It has nothing to do with the desirability o=
r not of !=3D. It was purely about scheduling. That's it.</blockquote><=
div>
<br></div></div><div>The original proposal had a perfectly sane definition =
of operator!=3D. The committee decided<br>to fiddle with it. The scheduling=
problems were caused by that fiddling, that's it.<br>=A0<br></div><div=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div><br></div><div>And secondly, frankly, you can complain all you like, b=
ut it's done. The question is answered. It was removed for scheduling <=
/div></blockquote><div><br></div></div><div>Oh, rest assured it's not d=
one. As I said multiple times, the current status quo won't pass the ba=
llot<br>
uncommented.<br><br><br></div></div><br></div></div></blockquote></div></di=
v></div></div></div></blockquote></div><br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e01184510431aa604dbad87c1--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 1 May 2013 16:08:58 -0400
Raw View
--089e011845103305ee04dbadb066
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 1, 2013 at 10:17 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> I guess so. The relational operators like less/greater etc. are one thing.
> But not having != has NO excuse. We should not support brain-damaged types
> for which !(x==y) isn't the same as x!=y.
>
>
>
Like double.
!(NaN == 0) != (NaN != 0)
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.
--089e011845103305ee04dbadb066
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 Wed, May 1, 2013 at 10:17 AM, Ville Voutilainen <span dir=3D"ltr=
"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vill=
e.voutilainen@gmail.com</a>></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"><p><br></p>
</div><p>I guess so. The relational operators like less/greater etc. are on=
e thing. But not having !=3D has NO excuse. We should not support brain-dam=
aged types for which !(x=3D=3Dy) isn't the same as x!=3Dy.<br>
</p><div class=3D"HOEnZb"><div class=3D"h5">
<p></p><br></div></div></blockquote></div><br></div><div class=3D"gmail_ext=
ra">Like double.<br><br></div><div class=3D"gmail_extra">!(NaN =3D=3D 0) !=
=3D (NaN !=3D 0)<br><br>Tony<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e011845103305ee04dbadb066--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 23:11:51 +0300
Raw View
--047d7b33d31c7d977504dbadba7a
Content-Type: text/plain; charset=ISO-8859-1
On 1 May 2013 23:08, Tony V E <tvaneerd@gmail.com> wrote:
> I guess so. The relational operators like less/greater etc. are one thing.
> But not having != has NO excuse. We should not support brain-damaged types
> for which !(x==y) isn't the same as x!=y.
>
>> Like double.
>>
>> !(NaN == 0) != (NaN != 0)
>
>
....and this example comes up every time we discuss any operator for
optional. I don't think it's optional's
problem to cover for NaN. std::tuple certainly doesn't perform irrational
magic to cover for NaN, nor does
any container.
--
---
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.
--047d7b33d31c7d977504dbadba7a
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 1 May 2013 23:08, Tony V E <span dir=3D"ltr"><<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></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"im">I guess s=
o. The relational operators like less/greater etc. are one thing. But not h=
aving !=3D has NO excuse. We should not support brain-damaged types for whi=
ch !(x=3D=3Dy) isn't the same as x!=3Dy.<br>
<div class=3D"gmail_extra"><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 class=3D"gmail_extra">
Like double.<br><br></div></div></blockquote></div></div></div><div class=
=3D"gmail_extra">!(NaN =3D=3D 0) !=3D (NaN !=3D 0)<span class=3D"HOEnZb"><f=
ont color=3D"#888888"><br><br></font></span></div></div></blockquote><div><=
br></div><div>
....and this example comes up every time we discuss any operator for optiona=
l. I don't think it's optional's<br>problem to cover for NaN. s=
td::tuple certainly doesn't perform irrational magic to cover for NaN, =
nor does<br>
</div><div>any container. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b33d31c7d977504dbadba7a--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 1 May 2013 22:19:24 +0200
Raw View
2013/5/1 Ville Voutilainen <ville.voutilainen@gmail.com>:
>
> On 1 May 2013 23:08, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> I guess so. The relational operators like less/greater etc. are one thing.
>> But not having != has NO excuse. We should not support brain-damaged types
>> for which !(x==y) isn't the same as x!=y.
>>>
>>> Like double.
>>>
>> !(NaN == 0) != (NaN != 0)
>>
>
> ...and this example comes up every time we discuss any operator for
> optional. I don't think it's optional's
> problem to cover for NaN. std::tuple certainly doesn't perform irrational
> magic to cover for NaN, nor does
> any container.
Completely agreed. NaNs are very special values with different
behaviour in several aspects. Floating-point types are totally-ordered
in <, if these values are absent. Stepanov excludes NaN values when
considering the otherwise regular nature of floating-point types.
- Daniel
--
---
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.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 23:22:02 +0300
Raw View
--001a11c32932eca20404dbadde9f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 1 May 2013 23:19, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
> 2013/5/1 Ville Voutilainen <ville.voutilainen@gmail.com>:
> > ...and this example comes up every time we discuss any operator for
> > optional. I don't think it's optional's
> > problem to cover for NaN. std::tuple certainly doesn't perform irration=
al
> > magic to cover for NaN, nor does
> > any container.
>
> Completely agreed. NaNs are very special values with different
> behaviour in several aspects. Floating-point types are totally-ordered
> in <, if these values are absent. Stepanov excludes NaN values when
> considering the otherwise regular nature of floating-point types.
>
>
>
Also, for reference, we actually had a straw poll about NaN and nullopt, an=
d
it says
Should nullopt compare like
NaN<http://wiki.edg.com/twiki/bin/edit/Wg21bristol/NaN?topicparent=3DWg21br=
istol.LibraryEvolutionWorkingGroup;nowysiwyg=3D1>?
SF/F/A/SA 0/0/0/17
I must admit I threatened to take the LEWG to see a shrink should anyone
vote
anything but SA, but I am not intimidating enough that such a threat would
be the
sole reason for such a unanimous vote.
--=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.
--001a11c32932eca20404dbadde9f
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 1 May 2013 23:19, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=
=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gma=
il.com</a>></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">2013/5/1 Ville Voutilaine=
n <<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmai=
l.com</a>>:<br>
<div><div class=3D"h5">> ...and this example comes up every time we disc=
uss any operator for<br>
> optional. I don't think it's optional's<br>
> problem to cover for NaN. std::tuple certainly doesn't perform irr=
ational<br>
> magic to cover for NaN, nor does<br>
> any container.<br>
<br>
</div></div>Completely agreed. NaNs are very special values with different<=
br>
behaviour in several aspects. Floating-point types are totally-ordered<br>
in <, if these values are absent. Stepanov excludes NaN values when<br>
considering the otherwise regular nature of floating-point types.<br>
<span class=3D""><font color=3D"#888888"><br><br></font></span></blockquote=
><div><br></div><div>Also, for reference, we actually had a straw poll abou=
t NaN and nullopt, and<br>it says<br><br><p>
Should nullopt compare like <span class=3D""><a href=3D"http://wiki.edg.com=
/twiki/bin/edit/Wg21bristol/NaN?topicparent=3DWg21bristol.LibraryEvolutionW=
orkingGroup;nowysiwyg=3D1" rel=3D"nofollow" title=3D"NaN (this topic does n=
ot yet exist; you can create it)">NaN</a></span>?
</p><p>
SF/F/A/SA
0/0/0/17
</p>I must admit I threatened to take the LEWG to see a shrink should anyon=
e vote<br>anything but SA, but I am not intimidating enough that such a thr=
eat would be the<br>sole reason for such a unanimous vote. <br></div></div>
<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--001a11c32932eca20404dbadde9f--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 1 May 2013 13:26:01 -0700 (PDT)
Raw View
------=_Part_355_13506937.1367439961446
Content-Type: text/plain; charset=ISO-8859-1
Both of those things are irrelevant as to why the Bristol outcome was what
it was. Whether or not national bodies request it to be changed is also
irrelevant. It is the way it is because the scheduling didn't work out.
On Wednesday, May 1, 2013 8:12:35 PM UTC+1, Ville Voutilainen wrote:
>
>
>
>
> On 1 May 2013 21:51, DeadMG <wolfei...@gmail.com <javascript:>> wrote:
>
>> It has nothing to do with the desirability or not of !=. It was purely
>> about scheduling. That's it.
>
>
> The original proposal had a perfectly sane definition of operator!=. The
> committee decided
> to fiddle with it. The scheduling problems were caused by that fiddling,
> that's it.
>
>
>>
>> And secondly, frankly, you can complain all you like, but it's done. The
>> question is answered. It was removed for scheduling
>>
>
> Oh, rest assured it's not done. As I said multiple times, the current
> status quo won't pass the ballot
> uncommented.
>
>
>
>
--
---
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_355_13506937.1367439961446
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Both of those things are irrelevant as to why the Bristol outcome was =
what it was. Whether or not national bodies request it to be changed is als=
o irrelevant. It is the way it is because the scheduling didn't work out.</=
div><br>On Wednesday, May 1, 2013 8:12:35 PM UTC+1, 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;"><div dir=3D"ltr"><br><div><br=
><br><div class=3D"gmail_quote">On 1 May 2013 21:51, DeadMG <span dir=3D"lt=
r"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"D=
tfU67kVdEUJ">wolfei...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It has nothing to do with the desirability o=
r not of !=3D. It was purely about scheduling. That's it.</blockquote><div>
<br></div><div>The original proposal had a perfectly sane definition of ope=
rator!=3D. The committee decided<br>to fiddle with it. The scheduling probl=
ems were caused by that fiddling, that's it.<br> <br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div><br></div><div>And secondly, frankly, you can complain all you like, b=
ut it's done. The question is answered. It was removed for scheduling </div=
></blockquote><div><br></div><div>Oh, rest assured it's not done. As I said=
multiple times, the current status quo won't pass the ballot<br>
uncommented.<br><br><br></div></div><br></div></div>
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
------=_Part_355_13506937.1367439961446--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 23:30:24 +0300
Raw View
--089e01175d63dbb3f304dbadfcd5
Content-Type: text/plain; charset=ISO-8859-1
On 1 May 2013 23:26, DeadMG <wolfeinstein@gmail.com> wrote:
> Both of those things are irrelevant as to why the Bristol outcome was what
> it was. Whether or not national bodies request it to be changed is also
> irrelevant. It is the way it is because the scheduling didn't work out.
>
>
Very astute, but what is relevant is that the current status quo is known
to be controversial, and it's
not set in stone.
--
---
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.
--089e01175d63dbb3f304dbadfcd5
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 1 May 2013 23:26, DeadMG <span dir=3D"ltr"><<a href=3D"mailto=
:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>></=
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>Both of those things are irrelevant as =
to why the Bristol outcome was what it was. Whether or not national bodies =
request it to be changed is also irrelevant. It is the way it is because th=
e scheduling didn't work out.</div>
<br></blockquote><div><br></div><div>Very astute, but what is relevant is t=
hat the current status quo is known to be controversial, and it's<br>no=
t set in stone. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e01175d63dbb3f304dbadfcd5--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 1 May 2013 16:35:31 -0400
Raw View
--047d7b3441fe278e0204dbae0f93
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 1, 2013 at 4:11 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 1 May 2013 23:08, Tony V E <tvaneerd@gmail.com> wrote:
>
>> I guess so. The relational operators like less/greater etc. are one
>> thing. But not having != has NO excuse. We should not support brain-damaged
>> types for which !(x==y) isn't the same as x!=y.
>>
>>> Like double.
>>>
>>> !(NaN == 0) != (NaN != 0)
>>
>>
> ...and this example comes up every time we discuss any operator for
> optional. I don't think it's optional's
> problem to cover for NaN. std::tuple certainly doesn't perform irrational
> magic to cover for NaN, nor does
> any container.
>
>
>
The big difference with optional (compared to tuple or containers) is that
optional allows mixed-relops. So you will have
double != double
optional<double> != double
optional<double> != optional<double>
And I think they should give the same answer, even if I throw NaN in there.
Doing it so that double works doesn't break any sane (non-brain-damaged)
type where !(x == y) == (x != y). It _does_ "break" the pattern forged by
tuple and containers. So it is a question of which is worse. I think
optional is different enough that the comparison with tuple and containers
is weak, so I favour supporting brain-damaged types.
Anyhow, we can work it out when we write it up :-)
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.
--047d7b3441fe278e0204dbae0f93
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 Wed, May 1, 2013 at 4:11 PM, Ville Voutilainen <span dir=3D"ltr"=
><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville=
..voutilainen@gmail.com</a>></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 class=3D"im">On 1 May 2013 23:0=
8, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>></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>I guess so. The relati=
onal operators like less/greater etc. are one thing. But not having !=3D ha=
s NO excuse. We should not support brain-damaged types for which !(x=3D=3Dy=
) isn't the same as x!=3Dy.<br>
<div class=3D"gmail_extra"><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 class=3D"gmail_extra">
Like double.<br><br></div></div></blockquote></div></div></div><div class=
=3D"gmail_extra">!(NaN =3D=3D 0) !=3D (NaN !=3D 0)<span><font color=3D"#888=
888"><br><br></font></span></div></div></blockquote><div><br></div></div><d=
iv>
....and this example comes up every time we discuss any operator for optiona=
l. I don't think it's optional's<br>problem to cover for NaN. s=
td::tuple certainly doesn't perform irrational magic to cover for NaN, =
nor does<br>
</div><div>any container. <br></div></div><br></div></div><div class=3D"HOE=
nZb"><div class=3D"h5">
<br></div></div></blockquote><div><br></div><div>The big difference with op=
tional (compared to tuple or containers) is that optional allows mixed-relo=
ps. So you will have<br><br></div><div>double !=3D double<br></div><div>
optional<double> !=3D double<br></div><div>optional<double> !=
=3D optional<double><br></div><div><br></div><div>And I think they sh=
ould give the same answer, even if I throw NaN in there.<br><br></div><div>=
Doing it so that double works doesn't break any sane (non-brain-damaged=
) type where !(x =3D=3D y) =3D=3D (x !=3D y).=A0 It _does_ "break"=
; the pattern forged by tuple and containers.=A0 So it is a question of whi=
ch is worse.=A0 I think optional is different enough that the comparison wi=
th tuple and containers is weak, so I favour supporting brain-damaged types=
..<br>
<br>Anyhow, we can work it out when we write it up :-)<br><br>Tony<br><br><=
/div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b3441fe278e0204dbae0f93--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 May 2013 23:39:48 +0300
Raw View
--089e0115ef60745a4e04dbae1ede
Content-Type: text/plain; charset=ISO-8859-1
On 1 May 2013 23:35, Tony V E <tvaneerd@gmail.com> wrote:
>
>
>
> On Wed, May 1, 2013 at 4:11 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>>
>>
>> On 1 May 2013 23:08, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>> I guess so. The relational operators like less/greater etc. are one
>>> thing. But not having != has NO excuse. We should not support brain-damaged
>>> types for which !(x==y) isn't the same as x!=y.
>>>
>>>> Like double.
>>>>
>>>> !(NaN == 0) != (NaN != 0)
>>>
>>>
>> ...and this example comes up every time we discuss any operator for
>> optional. I don't think it's optional's
>> problem to cover for NaN. std::tuple certainly doesn't perform irrational
>> magic to cover for NaN, nor does
>> any container.
>>
>>
>>
> The big difference with optional (compared to tuple or containers) is that
> optional allows mixed-relops. So you will have
>
> double != double
> optional<double> != double
> optional<double> != optional<double>
>
> And I think they should give the same answer, even if I throw NaN in there.
>
> Doing it so that double works doesn't break any sane (non-brain-damaged)
> type where !(x == y) == (x != y). It _does_ "break" the pattern forged by
> tuple and containers. So it is a question of which is worse. I think
> optional is different enough that the comparison with tuple and containers
> is weak, so I favour supporting brain-damaged types.
>
> Anyhow, we can work it out when we write it up :-)
>
>
I certainly hope so. :) I would love to see a practical example of code
that would break if optional's
operator!= works differently from the built-in operator for double. I
happen to think NaN is a red
herring in all of these discussions.
--
---
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.
--089e0115ef60745a4e04dbae1ede
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 1 May 2013 23:35, Tony V E <span dir=3D"ltr"><<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></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><div class=3D"h5">On Wed, May 1=
, 2013 at 4:11 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailt=
o:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.co=
m</a>></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 1 May 2013 23:08, Tony V E <=
span dir=3D"ltr"><<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank=
">tvaneerd@gmail.com</a>></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>I guess so. The relati=
onal operators like less/greater etc. are one thing. But not having !=3D ha=
s NO excuse. We should not support brain-damaged types for which !(x=3D=3Dy=
) isn't the same as x!=3Dy.<br>
<div class=3D"gmail_extra"><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 class=3D"gmail_extra">
Like double.<br><br></div></div></blockquote></div></div></div><div class=
=3D"gmail_extra">!(NaN =3D=3D 0) !=3D (NaN !=3D 0)<span><font color=3D"#888=
888"><br><br></font></span></div></div></blockquote><div><br></div></div><d=
iv>
....and this example comes up every time we discuss any operator for optiona=
l. I don't think it's optional's<br>problem to cover for NaN. s=
td::tuple certainly doesn't perform irrational magic to cover for NaN, =
nor does<br>
</div><div>any container. <br></div></div><br></div></div><div><div>
<br></div></div></blockquote><div><br></div></div></div><div>The big differ=
ence with optional (compared to tuple or containers) is that optional allow=
s mixed-relops. So you will have<br><br></div><div>double !=3D double<br>
</div><div>
optional<double> !=3D double<br></div><div>optional<double> !=
=3D optional<double><br></div><div><br></div><div>And I think they sh=
ould give the same answer, even if I throw NaN in there.<br><br></div><div>=
Doing it so that double works doesn't break any sane (non-brain-damaged=
) type where !(x =3D=3D y) =3D=3D (x !=3D y).=A0 It _does_ "break"=
; the pattern forged by tuple and containers.=A0 So it is a question of whi=
ch is worse.=A0 I think optional is different enough that the comparison wi=
th tuple and containers is weak, so I favour supporting brain-damaged types=
..<br>
<br>Anyhow, we can work it out when we write it up :-)<span class=3D"HOEnZb=
"><font color=3D"#888888"><br><br></font></span></div></div></div></div></b=
lockquote><div><br></div><div>I certainly hope so. :) I would love to see a=
practical example of code that would break if optional's<br>
</div><div>operator!=3D works differently from the built-in operator for do=
uble. I happen to think NaN is a red<br>herring in all of these discussions=
.. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e0115ef60745a4e04dbae1ede--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Wed, 01 May 2013 16:07:47 -0500
Raw View
DeadMG <wolfeinstein@gmail.com> writes:
| Whether or not != was different to > is irrelevant. What matters is that the
| Committee simply did not have the time to think about it. It was either "Cut
| everything except < and ==" or "Drop optional for C++14 due to time pressures".
| The session discussing optional already overran substantially.
If you believe the committee didn't have time to think about it, then
logically it shouldn't remove things -- because it would have needed
time to think about the consequences of removal.
-- Gaby
--
---
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.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 1 May 2013 17:06:23 -0500
Raw View
--20cf3074afe095358104dbaf5644
Content-Type: text/plain; charset=ISO-8859-1
On 1 May 2013 13:28, DeadMG <wolfeinstein@gmail.com> wrote:
> I wasn't present for the other sessions covering optional so I can't
> comment on any drive-by-redesigning.
>
> What we have in the C++14 CD working draft is known to be broken wrt.
>> ==/!=, and the situation will not survive ballot unmodified.
>
>
> Feel free to enlighten me, since I was at the final LEWG meeting and no
> issues wrt. ==/!= were raised.
>
LEWG came to concensus early in the week on optional, including all the
relation operators, and slated it for C++14.
Late Wednesday night, some members of LWG disagreed with the the choice
LEWG made for the relation operators. Since proposals require both LEWG
and LWG to come to consensus, we hit an impasse.
A day later, during the late Thursday afternoon joint LEWG/LWG session for
discussing optional, someone (I don't remember who) realized that there was
no controversy for operator< and operator==, and so the compromise was to
pull all the other relation operators, fully expecting to resolve the issue
via NB comments after the CD is issued.
The alternative was to pull optional and start at ground zero at another
meeting, and no one wanted that.
While I was present for all the LEWG discussions on optional, I was not
present for any of the LWG-only discussions on optional; if you are
interested in their deliberations, you might want to start by looking at
the LWG wiki.
FYI: the controversy is whether you want the relation operators for
engaged optional<T> to be consistent with the relation operators for type T
or you want them to be consistent with the relation operators of other
standard library classes (i.e., based only on </==). In an ideal world,
these two cases would be indistinguishable, but that isn't the world of
C++. :-)
--
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.
--20cf3074afe095358104dbaf5644
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 1 May 2013 13:28, DeadMG <span dir=3D"ltr"><<a href=3D"mailto:wolfein=
stein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>></span> wr=
ote:<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">
I wasn't present for the other sessions covering optional so I can'=
t comment on any drive-by-redesigning.<div><br></div><div><div class=3D"im"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex">
What we have in the C++14 CD working draft is known to be broken wrt. =3D=
=3D/!=3D, and the situation will not survive ballot unmodified.</blockquote=
><div><br></div></div><div>Feel free to enlighten me, since I was at the fi=
nal LEWG meeting and no issues wrt. =3D=3D/!=3D were raised.</div>
</div></blockquote><div><br>LEWG came to concensus early in the week on opt=
ional, including all the relation operators, and slated it for C++14.<br><b=
r>Late Wednesday night, some members of LWG disagreed with the the choice L=
EWG made for the relation operators.=A0 Since proposals require both LEWG a=
nd LWG to come to consensus, we hit an impasse.<br>
<br>A day later, during the late Thursday afternoon joint LEWG/LWG session =
for discussing optional, someone (I don't remember who) realized that t=
here was no controversy for operator< and operator=3D=3D, and so the com=
promise was to pull all the other relation operators, fully expecting to re=
solve the issue via NB comments after the CD is issued.<br>
<br>The alternative was to pull optional and start at ground zero at anothe=
r meeting, and no one wanted that.<br><br>While I was present for all the L=
EWG discussions on optional, I was not=20
present for any of the LWG-only discussions on optional; if you are=20
interested in their deliberations, you might want to start by looking at
the LWG wiki.<br><br>FYI:=A0 the controversy is whether you want the relat=
ion operators for engaged optional<T> to be consistent with the relat=
ion operators for type T or you want them to be consistent with the relatio=
n operators of other standard library classes (i.e., based only on </=3D=
=3D).=A0 In an ideal world, these two cases would be indistinguishable, but=
that isn't the world of C++. :-)<br clear=3D"all">
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--20cf3074afe095358104dbaf5644--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 1 May 2013 18:55:48 -0400
Raw View
--089e011604f4d9803e04dbb0045b
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 1, 2013 at 6:06 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 1 May 2013 13:28, DeadMG <wolfeinstein@gmail.com> wrote:
>
>> I wasn't present for the other sessions covering optional so I can't
>> comment on any drive-by-redesigning.
>>
>> What we have in the C++14 CD working draft is known to be broken wrt.
>>> ==/!=, and the situation will not survive ballot unmodified.
>>
>>
>> Feel free to enlighten me, since I was at the final LEWG meeting and no
>> issues wrt. ==/!= were raised.
>>
>
> LEWG came to concensus early in the week on optional, including all the
> relation operators, and slated it for C++14.
>
> Late Wednesday night, some members of LWG disagreed with the the choice
> LEWG made for the relation operators. Since proposals require both LEWG
> and LWG to come to consensus, we hit an impasse.
>
> A day later, during the late Thursday afternoon joint LEWG/LWG session for
> discussing optional, someone (I don't remember who) realized that there was
> no controversy for operator< and operator==, and so the compromise was to
> pull all the other relation operators, fully expecting to resolve the issue
> via NB comments after the CD is issued.
>
> The alternative was to pull optional and start at ground zero at another
> meeting, and no one wanted that.
>
> While I was present for all the LEWG discussions on optional, I was not
> present for any of the LWG-only discussions on optional; if you are
> interested in their deliberations, you might want to start by looking at
> the LWG wiki.
>
I looked, but couldn't find any LWG-only discussions or polls, etc., before
the Wednesday evening LEWG+LWG (which you were at). (According to the Wiki,
Wed evening was LEWG/LWG then it was continued on Thursday. But I lacked
sleep that week, so it is hard to piece it all together.)
> FYI: the controversy is whether you want the relation operators for
> engaged optional<T> to be consistent with the relation operators for type T
> or you want them to be consistent with the relation operators of other
> standard library classes (i.e., based only on </==). In an ideal world,
> these two cases would be indistinguishable, but that isn't the world of
> C++. :-)
> --
> 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.
--089e011604f4d9803e04dbb0045b
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 Wed, May 1, 2013 at 6:06 PM, Nevin Liber <span dir=3D"ltr"><<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo=
rd.com</a>></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 1 May 2013 13:28, DeadM=
G <span dir=3D"ltr"><<a href=3D"mailto:wolfeinstein@gmail.com" target=3D=
"_blank">wolfeinstein@gmail.com</a>></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">
I wasn't present for the other sessions covering optional so I can'=
t comment on any drive-by-redesigning.<div><br></div><div><div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
What we have in the C++14 CD working draft is known to be broken wrt. =3D=
=3D/!=3D, and the situation will not survive ballot unmodified.</blockquote=
><div><br></div></div><div>Feel free to enlighten me, since I was at the fi=
nal LEWG meeting and no issues wrt. =3D=3D/!=3D were raised.</div>
</div></blockquote></div><div><br>LEWG came to concensus early in the week =
on optional, including all the relation operators, and slated it for C++14.=
<br><br>Late Wednesday night, some members of LWG disagreed with the the ch=
oice LEWG made for the relation operators.=A0 Since proposals require both =
LEWG and LWG to come to consensus, we hit an impasse.<br>
<br>A day later, during the late Thursday afternoon joint LEWG/LWG session =
for discussing optional, someone (I don't remember who) realized that t=
here was no controversy for operator< and operator=3D=3D, and so the com=
promise was to pull all the other relation operators, fully expecting to re=
solve the issue via NB comments after the CD is issued.<br>
<br>The alternative was to pull optional and start at ground zero at anothe=
r meeting, and no one wanted that.<br><br>While I was present for all the L=
EWG discussions on optional, I was not=20
present for any of the LWG-only discussions on optional; if you are=20
interested in their deliberations, you might want to start by looking at
the LWG wiki.<br></div></div></blockquote><div><br></div><div><br>I looked=
, but couldn't find any LWG-only discussions or polls, etc., before the=
Wednesday evening LEWG+LWG (which you were at). (According to the Wiki, We=
d evening was LEWG/LWG then it was continued on Thursday.=A0 But I lacked s=
leep that week, so it is hard to piece it all together.)<br>
</div><div><br><br></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><br>FYI:=A0 the controversy is whether you want the relation o=
perators for engaged optional<T> to be consistent with the relation o=
perators for type T or you want them to be consistent with the relation ope=
rators of other standard library classes (i.e., based only on </=3D=3D).=
=A0 In an ideal world, these two cases would be indistinguishable, but that=
isn't the world of C++. :-)<span class=3D"HOEnZb"><font color=3D"#8888=
88"><br clear=3D"all">
</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888">--=
<br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@e=
viloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a hre=
f=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(84=
7) 691-1404</a></font></span><div class=3D"HOEnZb">
<div class=3D"h5">
<p></p>
--=A0 <br></div></div></blockquote></div><br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e011604f4d9803e04dbb0045b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 15:26:41 +0300
Raw View
--047d7b2e41a4c2e9bd04dbbb584c
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 01:55, Tony V E <tvaneerd@gmail.com> wrote:
> I looked, but couldn't find any LWG-only discussions or polls, etc.,
> before the Wednesday evening LEWG+LWG (which you were at). (According to
> the Wiki, Wed evening was LEWG/LWG then it was continued on Thursday. But
> I lacked sleep that week, so it is hard to piece it all together.)
>
>
>
>> FYI: the controversy is whether you want the relation operators for
>> engaged optional<T> to be consistent with the relation operators for type T
>> or you want them to be consistent with the relation operators of other
>> standard library classes (i.e., based only on </==). In an ideal world,
>> these two cases would be indistinguishable, but that isn't the world of
>> C++. :-)
>> --
>> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>>
>> --
>>
>
>
>
Here's something possibly worth remembering: boost::optional defines
operator!= in terms of operator==,
and relation operators in terms of operator<. It will happily say false for
opt1==opt2 and true for opt1!=opt2 if they are
of type optional<double> and have a NAN value, and will say false for both
opt1<opt2 and opt1>opt2. boost::optional has been out
since 2003, and apparently nobody has shouted loud enough about this being
a problem. boost::optional also does
mixed relops.
--
---
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.
--047d7b2e41a4c2e9bd04dbbb584c
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 2 May 2013 01:55, Tony V E <span dir=3D"ltr"><<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></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">I looked, but couldn't =
find any LWG-only discussions or polls, etc., before the Wednesday evening =
LEWG+LWG (which you were at). (According to the Wiki, Wed evening was LEWG/=
LWG then it was continued on Thursday.=A0 But I lacked sleep that week, so =
it is hard to piece it all together.)<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><di=
v><br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><=
div><br>
FYI:=A0 the controversy is whether you want the relation operators for enga=
ged optional<T> to be consistent with the relation operators for type=
T or you want them to be consistent with the relation operators of other s=
tandard library classes (i.e., based only on </=3D=3D).=A0 In an ideal w=
orld, these two cases would be indistinguishable, but that isn't the wo=
rld of C++. :-)<span><font color=3D"#888888"><br clear=3D"all">
</font></span></div></div><span><font color=3D"#888888">-- <br>=A0Nevin &qu=
ot;:-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a href=3D"tel:%28847%2=
9%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</a></=
font></span><div>
<div>
<p></p>
--=A0 <br></div></div></blockquote></div></div><br><br></div></div></blockq=
uote><div><br></div><div>Here's something possibly worth remembering: b=
oost::optional defines operator!=3D in terms of operator=3D=3D,<br>and rela=
tion operators in terms of operator<. It will happily say false for opt1=
=3D=3Dopt2 and true for opt1!=3Dopt2 if they are<br>
of type optional<double> and have a NAN value, and will say false for=
both opt1<opt2 and opt1>opt2. boost::optional has been out<br>since =
2003, and apparently nobody has shouted loud enough about this being a prob=
lem. boost::optional also does<br>
mixed relops.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b2e41a4c2e9bd04dbbb584c--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 09:31:29 -0300
Raw View
--089e0112cbee58cd3904dbbb6c8f
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 9:26 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 2 May 2013 01:55, Tony V E <tvaneerd@gmail.com> wrote:
>
>> I looked, but couldn't find any LWG-only discussions or polls, etc.,
>> before the Wednesday evening LEWG+LWG (which you were at). (According to
>> the Wiki, Wed evening was LEWG/LWG then it was continued on Thursday. But
>> I lacked sleep that week, so it is hard to piece it all together.)
>>
>>
>>
>>> FYI: the controversy is whether you want the relation operators for
>>> engaged optional<T> to be consistent with the relation operators for type T
>>> or you want them to be consistent with the relation operators of other
>>> standard library classes (i.e., based only on </==). In an ideal world,
>>> these two cases would be indistinguishable, but that isn't the world of
>>> C++. :-)
>>> --
>>> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>>>
>>> --
>>>
>>
>>
>>
> Here's something possibly worth remembering: boost::optional defines
> operator!= in terms of operator==,
>
FWIW, I would argue, and loud, that operator != cannot ever, ever be
anything but !(==). And to the extent that I would have liked C++ to define
that implicitly and make that operator non overloaded.
--
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.
--089e0112cbee58cd3904dbbb6c8f
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=
hu, May 2, 2013 at 9:26 AM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></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 class=3D"im">On 2 May 2013 01:5=
5, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>></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">I looked, but couldn't =
find any LWG-only discussions or polls, etc., before the Wednesday evening =
LEWG+LWG (which you were at). (According to the Wiki, Wed evening was LEWG/=
LWG then it was continued on Thursday.=A0 But I lacked sleep that week, so =
it is hard to piece it all together.)<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div><br><br></d=
iv><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><br>
FYI:=A0 the controversy is whether you want the relation operators for enga=
ged optional<T> to be consistent with the relation operators for type=
T or you want them to be consistent with the relation operators of other s=
tandard library classes (i.e., based only on </=3D=3D).=A0 In an ideal w=
orld, these two cases would be indistinguishable, but that isn't the wo=
rld of C++. :-)<span><font color=3D"#888888"><br clear=3D"all">
</font></span></div></div><span><font color=3D"#888888">-- <br>=A0Nevin &qu=
ot;:-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a href=3D"tel:%28847%2=
9%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</a></=
font></span><div>
<div>
<p></p>
--=A0 <br></div></div></blockquote></div></div><br><br></div></div></blockq=
uote><div><br></div></div><div>Here's something possibly worth remember=
ing: boost::optional defines operator!=3D in terms of operator=3D=3D,<br></=
div>
</div></div></div></blockquote><div><br></div><div>FWIW, I would argue, and=
loud, that operator !=3D cannot ever, ever be anything but !(=3D=3D). And =
to the extent that I would have liked C++ to define that implicitly and mak=
e that operator non overloaded.<br>
</div><div>=A0<br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consu=
lting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://www.=
scisoft-consulting.com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e0112cbee58cd3904dbbb6c8f--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 2 May 2013 10:41:32 -0400
Raw View
--047d7b3a897a0b14a804dbbd3ba2
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 8:31 AM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:
>
>
> FWIW, I would argue, and loud, that operator != cannot ever, ever be
> anything but !(==). And to the extent that I would have liked C++ to define
> that implicitly and make that operator non overloaded.
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>
> --
>
I agree with that, but I don't think that is optional's problem to solve.
We have double which breaks that, and users that have broken it (whether
they should have or not).
We should have an "= default" (or some other syntax) shortcut so classes
can easily get these operators generated. But again, that is not optional.
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.
--047d7b3a897a0b14a804dbbd3ba2
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 Thu, May 2, 2013 at 8:31 AM, Fernando Cacciola <span dir=3D"ltr"=
><<a href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">ferna=
ndo.cacciola@gmail.com</a>></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"><br><div><br></div></div><div>=
FWIW, I would argue, and loud, that operator !=3D cannot ever, ever be anyt=
hing but !(=3D=3D). And to the extent that I would have liked C++ to define=
that implicitly and make that operator non overloaded.<span class=3D"HOEnZ=
b"><font color=3D"#888888"><br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><div>=A0=
<br></div></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888=
"><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D=
"http://www.scisoft-consulting.com" target=3D"_blank">http://www.scisoft-co=
nsulting.com</a>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br></div></div></blockquote><div><br><br></div><div>I agree with that, =
but I don't think that is optional's problem to solve.=A0 We have d=
ouble which breaks that, and users that have broken it (whether they should=
have or not).<br>
<br></div><div>We should have an "=3D default" (or some other syn=
tax) shortcut so classes can easily get these operators generated.=A0 But a=
gain, that is not optional.<br></div></div><br></div><div class=3D"gmail_ex=
tra">
Tony<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b3a897a0b14a804dbbd3ba2--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 2 May 2013 10:54:16 -0400
Raw View
--047d7b3441fe9b127a04dbbd6893
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 8:26 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> Here's something possibly worth remembering: boost::optional defines
> operator!= in terms of operator==,
> and relation operators in terms of operator<. It will happily say false
> for opt1==opt2 and true for opt1!=opt2 if they are
> of type optional<double> and have a NAN value, and will say false for both
> opt1<opt2 and opt1>opt2. boost::optional has been out
> since 2003, and apparently nobody has shouted loud enough about this being
> a problem. boost::optional also does
> mixed relops.
>
>
>
We are definitely arguing about edge cases. Neither definition will cause
problems for normal classes. Only one might cause problems for odd
classes.
---
As for mixed relops, has anyone noticed:
optional<bool> ob = false;
if (ob) // true, as engaged (OK, tricky, but OK)
if (ob == true) // false as operator==(T) is used, not bool conversion
ie bool(ob) != (ob == true)
and, in general
!ob != (ob == false)
(I don't think that is an argument against mixed relops, I think it is an
argument against bool conversion)
Now, Boost has TriBool, and the C++ does not, so optional<bool> might
become more common than it was in the boost world.
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.
--047d7b3441fe9b127a04dbbd6893
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 Thu, May 2, 2013 at 8:26 AM, Ville Voutilainen <span dir=3D"ltr"=
><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville=
..voutilainen@gmail.com</a>></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 dir=3D"ltr"><div c=
lass=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<div class=3D"im"><div><br></div></div><div>Here's something possibly w=
orth remembering: boost::optional defines operator!=3D in terms of operator=
=3D=3D,<br>and relation operators in terms of operator<. It will happily=
say false for opt1=3D=3Dopt2 and true for opt1!=3Dopt2 if they are<br>
of type optional<double> and have a NAN value, and will say false for=
both opt1<opt2 and opt1>opt2. boost::optional has been out<br>since =
2003, and apparently nobody has shouted loud enough about this being a prob=
lem. boost::optional also does<br>
mixed relops.<br></div></div><br></div></div><div class=3D"HOEnZb"><div>=A0
<br></div></div></blockquote><div><br></div><div>We are definitely arguing =
about edge cases.=A0 Neither definition will cause problems for normal clas=
ses.=A0=A0 Only one might cause problems for odd classes.<br><br>---<br><br=
>
</div><div>As for mixed relops, has anyone noticed:<br><br></div><div>optio=
nal<bool> ob =3D false;<br><br></div><div>if (ob) // true, as engaged=
(OK, tricky, but OK)<br><br>if (ob =3D=3D true) // false as operator=3D=3D=
(T) is used, not bool conversion<br>
<br></div><div>ie bool(ob) !=3D (ob =3D=3D true)<br><br>and, in general<br>=
<br>!ob !=3D (ob =3D=3D false)<br><br></div><div><br></div><div>(I don'=
t think that is an argument against mixed relops, I think it is an argument=
against bool conversion)<br>
<br></div><div>Now, Boost has TriBool, and the C++ does not, so optional<=
;bool> might become more common than it was in the boost world.<br><br>T=
ony<br><br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b3441fe9b127a04dbbd6893--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 17:58:46 +0300
Raw View
--089e01175d63a52ffb04dbbd78ad
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 17:54, Tony V E <tvaneerd@gmail.com> wrote:
> As for mixed relops, has anyone noticed:
>
> optional<bool> ob = false;
>
> if (ob) // true, as engaged (OK, tricky, but OK)
>
Sure, I have noticed that.
>
> if (ob == true) // false as operator==(T) is used, not bool conversion
>
> ie bool(ob) != (ob == true)
>
> and, in general
>
> !ob != (ob == false)
>
Yep.
>
>
> (I don't think that is an argument against mixed relops, I think it is an
> argument against bool conversion)
>
Well, the bool conversion does exactly what it's supposed to do.
--
---
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.
--089e01175d63a52ffb04dbbd78ad
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 2 May 2013 17:54, Tony V E <span dir=3D"ltr"><<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></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">As for mixed relops, has an=
yone noticed:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div>
<div>optional<bool> ob =3D false;<br><br></div><div>if (ob) // true, =
as engaged (OK, tricky, but OK)<br></div></div></div></div></blockquote><di=
v><br></div><div>Sure, I have noticed that.<br>=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br>if (ob =3D=3D true) // false as operator=3D=3D(T) is used, not bool co=
nversion<br>
<br></div><div>ie bool(ob) !=3D (ob =3D=3D true)<br><br>and, in general<br>=
<br>!ob !=3D (ob =3D=3D false)<br></div></div></div></div></blockquote><div=
><br></div><div>Yep.<br>=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=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><br></div><div>(I don't think that is an argument again=
st mixed relops, I think it is an argument against bool conversion)<br></di=
v>
</div></div></div></blockquote><div><br></div><div>Well, the bool conversio=
n does exactly what it's supposed to do.<br><br></div></div><br></div><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e01175d63a52ffb04dbbd78ad--
.
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Thu, 2 May 2013 09:07:06 -0700
Raw View
--089e01175d631219de04dbbe6d75
Content-Type: text/plain; charset=ISO-8859-1
On May 1, 2013 1:45 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:
>
>
>
>
> On 1 May 2013 21:28, DeadMG <wolfeinstein@gmail.com> wrote:
>>
>> What we have in the C++14 CD working draft is known to be broken wrt.
==/!=, and the situation will not survive ballot unmodified.
>>
>> Feel free to enlighten me, since I was at the final LEWG meeting and no
issues wrt. ==/!= were raised.
>
>
>
> That's because sometimes people need to make concessions to get a
fundamental vocabulary
> type into a working draft, and fix its issues later.
And that's exactly what we did. :-) We accepted the imperfection of some
missing operators in order to get this vocabulary type in at all, and we
can get consensus on how to fix them in Chicago.
If you want to fix them, please come with a paper exploring the issue and
suggesting wording. If possible, it would be nice to have wording for
several options, so the committee can just vote on which one to take
instead of trying to invent options that aren't in the paper. If you choose
not to do that, it's of course fine, but you'd increase the chance that the
status quo will remain.
Jeffrey
--
---
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.
--089e01175d631219de04dbbe6d75
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On May 1, 2013 1:45 PM, "Ville Voutilainen" <<a=
href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a=
>> wrote:<br>
><br>
><br>
><br>
><br>
> On 1 May 2013 21:28, DeadMG <<a href=3D"mailto:wolfeinstein@gmail.c=
om">wolfeinstein@gmail.com</a>> wrote:<br>
>><br>
>> What we have in the C++14 CD working draft is known to be broken w=
rt. =3D=3D/!=3D, and the situation will not survive ballot unmodified.<br>
>><br>
>> Feel free to enlighten me, since I was at the final LEWG meeting a=
nd no issues wrt. =3D=3D/!=3D were raised.<br>
><br>
><br>
><br>
> That's because sometimes people need to make concessions to get a =
fundamental vocabulary<br>
> type into a working draft, and fix its issues later.</p>
<p dir=3D"ltr">And that's exactly what we did. :-)=A0 We accepted the i=
mperfection of some missing operators in order to get this vocabulary type =
in at all, and we can get consensus on how to fix them in Chicago. </p>
<p dir=3D"ltr">If you want to fix them, please come with a paper exploring =
the issue and suggesting wording. If possible, it would be nice to have wor=
ding for several options, so the committee can just vote on which one to ta=
ke instead of trying to invent options that aren't in the paper. If you=
choose not to do that, it's of course fine, but you'd increase the=
chance that the status quo will remain.</p>
<p dir=3D"ltr">Jeffrey</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e01175d631219de04dbbe6d75--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 19:48:07 +0300
Raw View
--001a11c24b7cbd0cd604dbbeff26
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 19:07, Jeffrey Yasskin <jyasskin@google.com> wrote:
> > That's because sometimes people need to make concessions to get a
> fundamental vocabulary
> > type into a working draft, and fix its issues later.
>
> And that's exactly what we did. :-) We accepted the imperfection of some
> missing operators in order to get this vocabulary type in
>
Indeed we did.
> If you want to fix them, please come with a paper exploring the issue and
> suggesting wording. If possible, it would be nice to have wording for
> several options, so the committee can just vote on which one to take
> instead of trying to invent options that aren't in the paper. If you choose
> not to do that, it's of course fine, but you'd increase the chance that the
> status quo will remain.
>
>
>
> Lucky me, the wording I want is in R4C, on the Bristol LWG wiki. It's
editorially easier to propose a post-CD fix,
so that's what I'll do. Or, more precisely, in order of importance:
1) put the R4C wording in
2) make tuple and containers use std::less, too
3) if someone has the energy, propose additional changes that allow NaNs
and 'odd types' to work. This
is separable, and should be separated, and should be done consistently for
tuples and containers.
Tony said consistency with tuple and containers is a weak argument. I find
it relatively strong. And I
find not fiddling with existing practice, which is boost::optional, an even
stronger argument. Using
std::less instead of raw operator< is a minor change to that existing
practice, so I'm fine with that bit.
--
---
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.
--001a11c24b7cbd0cd604dbbeff26
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 2 May 2013 19:07, Jeffrey Yasskin <span dir=3D"ltr"><<a href=
=3D"mailto:jyasskin@google.com" target=3D"_blank">jyasskin@google.com</a>&g=
t;</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"><p dir=3D"ltr">> That&#=
39;s because sometimes people need to make concessions to get a fundamental=
vocabulary<br>
> type into a working draft, and fix its issues later.</p>
</div><p dir=3D"ltr">And that's exactly what we did. :-)=A0 We accepted=
the imperfection of some missing operators in order to get this vocabulary=
type in </p></blockquote><div><br></div><div>Indeed we did.<br>=A0<br></di=
v>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">If you want to fix them, please come with a =
paper exploring the issue and suggesting wording. If possible, it would be =
nice to have wording for several options, so the committee can just vote on=
which one to take instead of trying to invent options that aren't in t=
he paper. If you choose not to do that, it's of course fine, but you=
9;d increase the chance that the status quo will remain.<span class=3D"HOEn=
Zb"><font color=3D"#888888">
<p dir=3D"ltr"><br></p><p dir=3D"ltr"><br></p></font></span></blockquote><d=
iv>Lucky me, the wording I want is in R4C, on the Bristol LWG wiki. It'=
s editorially easier to propose a post-CD fix,<br>so that's what I'=
ll do. Or, more precisely, in order of importance:<br>
<br></div><div>1) put the R4C wording in<br></div><div>2) make tuple and co=
ntainers use std::less, too<br></div><div>3) if someone has the energy, pro=
pose additional changes that allow NaNs and 'odd types' to work. Th=
is<br>
</div><div>is separable, and should be separated, and should be done consis=
tently for tuples and containers.<br><br></div><div>Tony said consistency w=
ith tuple and containers is a weak argument. I find it relatively strong. A=
nd I<br>
find not fiddling with existing practice, which is boost::optional, an even=
stronger argument. Using<br>std::less instead of raw operator< is a min=
or change to that existing practice, so I'm fine with that bit. <br>
</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--001a11c24b7cbd0cd604dbbeff26--
.
Author: Marc <marc.glisse@gmail.com>
Date: Thu, 2 May 2013 10:31:41 -0700 (PDT)
Raw View
------=_Part_702_19507298.1367515902020
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le mercredi 1 mai 2013 22:08:58 UTC+2, Tony V E a =E9crit :
>
> On Wed, May 1, 2013 at 10:17 AM, Ville Voutilainen <ville.vo...@gmail.com=
<javascript:>
> > wrote:
>
>> I guess so. The relational operators like less/greater etc. are one=20
>> thing. But not having !=3D has NO excuse. We should not support brain-da=
maged=20
>> types for which !(x=3D=3Dy) isn't the same as x!=3Dy.
>>
> Like double.
>
> !(NaN =3D=3D 0) !=3D (NaN !=3D 0)
>
>
Eh?
NaN=3D=3D0 is false, but NaN!=3D0 is true. It is implementing >=3D using < =
that=20
causes problems with NaN.
--=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_702_19507298.1367515902020
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le mercredi 1 mai 2013 22:08:58 UTC+2, Tony V E a =E9crit :<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote">On Wed, May 1, 2013 at 10:17 AM, Ville Voutilainen <span dir=3D"ltr=
"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"My=
pOYW6n6SMJ">ville.vo...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p>I guess so. The relational operators like=
less/greater etc. are one thing. But not having !=3D has NO excuse. We sho=
uld not support brain-damaged types for which !(x=3D=3Dy) isn't the same as=
x!=3Dy.<br>
</p></blockquote></div></div><div>Like double.<br><br></div><div>!(NaN =3D=
=3D 0) !=3D (NaN !=3D 0)<br><br></div></div></blockquote><div><br>Eh?<br>Na=
N=3D=3D0 is false, but NaN!=3D0 is true. It is implementing >=3D using &=
lt; that causes problems with NaN.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
------=_Part_702_19507298.1367515902020--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 02 May 2013 20:22:11 +0200
Raw View
This is a multi-part message in MIME format.
--------------040506020006030503050004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 02/05/13 16:58, Ville Voutilainen a =E9crit :
>
>
>
> On 2 May 2013 17:54, Tony V E <tvaneerd@gmail.com=20
> <mailto:tvaneerd@gmail.com>> wrote:
>
> As for mixed relops, has anyone noticed:
>
> optional<bool> ob =3D false;
>
> if (ob) // true, as engaged (OK, tricky, but OK)
>
>
> Sure, I have noticed that.
>
>
> if (ob =3D=3D true) // false as operator=3D=3D(T) is used, not bool c=
onversion
>
> ie bool(ob) !=3D (ob =3D=3D true)
>
> and, in general
>
> !ob !=3D (ob =3D=3D false)
>
>
> Yep.
I hope this would be fixed. It is unintuitive and a source of errors.
>
>
>
> (I don't think that is an argument against mixed relops, I think
> it is an argument against bool conversion)
>
>
> Well, the bool conversion does exactly what it's supposed to do.
>
>
Yes, but the combination with mixed relops is catastrophic.
Vicente
--=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.
--------------040506020006030503050004
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 02/05/13 16:58, Ville Voutilainen a
écrit :<br>
</div>
<blockquote
cite="mid:CAFk2RUZAVpgVaEDiapC+D0b+CUei_J8LVbvFwZHYhgcP5LooxQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 2 May 2013 17:54, Tony V E <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:tvaneerd@gmail.com" target="_blank">tvaneerd@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">As for mixed relops, has anyone noticed:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>optional<bool> ob = false;<br>
<br>
</div>
<div>if (ob) // true, as engaged (OK, tricky, but
OK)<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Sure, I have noticed that.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
if (ob == true) // false as operator==(T) is used,
not bool conversion<br>
<br>
</div>
<div>ie bool(ob) != (ob == true)<br>
<br>
and, in general<br>
<br>
!ob != (ob == false)<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yep.<br>
</div>
</div>
</div>
</div>
</blockquote>
I hope this would be fixed. It is unintuitive and a source of
errors.<br>
<blockquote
cite="mid:CAFk2RUZAVpgVaEDiapC+D0b+CUei_J8LVbvFwZHYhgcP5LooxQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<div>(I don't think that is an argument against
mixed relops, I think it is an argument against
bool conversion)<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Well, the bool conversion does exactly what it's
supposed to do.<br>
<br>
</div>
</div>
<br>
</div>
</div>
</blockquote>
Yes, but the combination with mixed relops is catastrophic.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------040506020006030503050004--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 2 May 2013 14:33:03 -0400
Raw View
--047d7b3a897a012d8904dbc07799
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, May 2, 2013 at 1:31 PM, Marc <marc.glisse@gmail.com> wrote:
> Le mercredi 1 mai 2013 22:08:58 UTC+2, Tony V E a =E9crit :
>
>> On Wed, May 1, 2013 at 10:17 AM, Ville Voutilainen <ville.vo...@gmail.co=
m
>> > wrote:
>>
>>> I guess so. The relational operators like less/greater etc. are one
>>> thing. But not having !=3D has NO excuse. We should not support brain-d=
amaged
>>> types for which !(x=3D=3Dy) isn't the same as x!=3Dy.
>>>
>> Like double.
>>
>> !(NaN =3D=3D 0) !=3D (NaN !=3D 0)
>>
>>
> Eh?
> NaN=3D=3D0 is false, but NaN!=3D0 is true. It is implementing >=3D using =
< that
> causes problems with NaN.
> --
>
>
Right. Sorry. Wrong example. >=3D via < had been my focus previously.
Doing !=3D via =3D=3D just follows the same pattern. ie
if >=3D is implemented via T's <, then !=3D should be implemented via T's =
=3D=3D
if >=3D is implemented via T's >=3D, then !=3D should be implemented via T'=
s !=3D
As mentioned earlier, =3D=3D vs !=3D wasn't debated as much as >=3D vs <.
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.
--047d7b3a897a012d8904dbc07799
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 Thu, May 2, 2013 at 1:31 PM, Marc <span dir=3D"ltr"><<a href=
=3D"mailto:marc.glisse@gmail.com" target=3D"_blank">marc.glisse@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Le mercredi 1 mai 2013 22:08:58 UTC+2, Tony =
V E a =E9crit=A0:<div class=3D"im"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, May 1, 2013 at 10:=
17 AM, Ville Voutilainen <span dir=3D"ltr"><<a>ville.vo...@gmail.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p>I guess so. The relational operators like=
less/greater etc. are one thing. But not having !=3D has NO excuse. We sho=
uld not support brain-damaged types for which !(x=3D=3Dy) isn't the sam=
e as x!=3Dy.<br>
</p></blockquote></div></div><div>Like double.<br><br></div><div>!(NaN =3D=
=3D 0) !=3D (NaN !=3D 0)<br><br></div></div></blockquote></div><div><br>Eh?=
<br>NaN=3D=3D0 is false, but NaN!=3D0 is true. It is implementing >=3D u=
sing < that causes problems with NaN.<br>
</div><div class=3D"HOEnZb"><div>
-- <br>=A0
<br></div></div></blockquote><div><br><br></div><div>Right.=A0 Sorry. Wrong=
example.=A0 >=3D via < had been my focus previously.=A0 Doing !=3D v=
ia =3D=3D just follows the same pattern.=A0 ie <br><br>if >=3D is implem=
ented via T's <, then !=3D should be implemented via T's =3D=3D<=
br>
</div><div>if >=3D is implemented via T's >=3D, then !=3D should =
be implemented via T's !=3D<br></div><div><br></div>As mentioned earlie=
r, =3D=3D vs !=3D wasn't debated as much as >=3D vs <.<br><br>Ton=
y<br></div><br>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b3a897a012d8904dbc07799--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 2 May 2013 14:38:00 -0400
Raw View
--047d7b3441feb0de6d04dbc08898
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 12:48 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 2 May 2013 19:07, Jeffrey Yasskin <jyasskin@google.com> wrote:
>
>> > That's because sometimes people need to make concessions to get a
>> fundamental vocabulary
>> > type into a working draft, and fix its issues later.
>>
>> And that's exactly what we did. :-) We accepted the imperfection of some
>> missing operators in order to get this vocabulary type in
>>
>
> Indeed we did.
>
>
>> If you want to fix them, please come with a paper exploring the issue and
>> suggesting wording. If possible, it would be nice to have wording for
>> several options, so the committee can just vote on which one to take
>> instead of trying to invent options that aren't in the paper. If you choose
>> not to do that, it's of course fine, but you'd increase the chance that the
>> status quo will remain.
>>
>>
>>
>> Lucky me, the wording I want is in R4C, on the Bristol LWG wiki. It's
> editorially easier to propose a post-CD fix,
> so that's what I'll do. Or, more precisely, in order of importance:
>
> 1) put the R4C wording in
> 2) make tuple and containers use std::less, too
> 3) if someone has the energy, propose additional changes that allow NaNs
> and 'odd types' to work. This
> is separable, and should be separated, and should be done consistently for
> tuples and containers.
>
> Tony said consistency with tuple and containers is a weak argument. I find
> it relatively strong. And I
> find not fiddling with existing practice, which is boost::optional, an
> even stronger argument. Using
> std::less instead of raw operator< is a minor change to that existing
> practice, so I'm fine with that bit.
>
>
>
implementing < via std::less is wrong as well - complex has (or will have)
std::less, but not <.
So, if < is implemented with std::less, we get:
complex < complex // doesn't compile*
optional<complex> < complex // OK
optional<complex> < optional<complex> // OK
(*none of them compile - it's not valid code, but you know what I mean).
Instead we should specialize std::less<optional<T>> to call std::less<T>.
Then none of the above work, but you can still put both complex and
optional<complex> into containers.
--
---
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.
--047d7b3441feb0de6d04dbc08898
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 Thu, May 2, 2013 at 12:48 PM, Ville Voutilainen <span dir=3D"ltr=
"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vill=
e.voutilainen@gmail.com</a>></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 class=3D"im">On 2 May 2013 19:0=
7, Jeffrey Yasskin <span dir=3D"ltr"><<a href=3D"mailto:jyasskin@google.=
com" target=3D"_blank">jyasskin@google.com</a>></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><p dir=3D"ltr">> That's because =
sometimes people need to make concessions to get a fundamental vocabulary<b=
r>
> type into a working draft, and fix its issues later.</p>
</div><p dir=3D"ltr">And that's exactly what we did. :-)=A0 We accepted=
the imperfection of some missing operators in order to get this vocabulary=
type in </p></blockquote><div><br></div></div><div>Indeed we did.<br>=A0<b=
r>
</div><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">If you want to fix them, please come with a =
paper exploring the issue and suggesting wording. If possible, it would be =
nice to have wording for several options, so the committee can just vote on=
which one to take instead of trying to invent options that aren't in t=
he paper. If you choose not to do that, it's of course fine, but you=
9;d increase the chance that the status quo will remain.<span><font color=
=3D"#888888">
<p dir=3D"ltr"><br></p><p dir=3D"ltr"><br></p></font></span></blockquote></=
div><div>Lucky me, the wording I want is in R4C, on the Bristol LWG wiki. I=
t's editorially easier to propose a post-CD fix,<br>so that's what =
I'll do. Or, more precisely, in order of importance:<br>
<br></div><div>1) put the R4C wording in<br></div><div>2) make tuple and co=
ntainers use std::less, too<br></div><div>3) if someone has the energy, pro=
pose additional changes that allow NaNs and 'odd types' to work. Th=
is<br>
</div><div>is separable, and should be separated, and should be done consis=
tently for tuples and containers.<br><br></div><div>Tony said consistency w=
ith tuple and containers is a weak argument. I find it relatively strong. A=
nd I<br>
find not fiddling with existing practice, which is boost::optional, an even=
stronger argument. Using<br>std::less instead of raw operator< is a min=
or change to that existing practice, so I'm fine with that bit. <br>
</div></div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<br></div></div></blockquote><div><br></div><div>implementing < via std:=
:less is wrong as well - complex has (or will have) std::less, but not <=
..<br><br></div><div>So, if < is implemented with std::less, we get:<br>
</div><div><br></div><div>complex < complex =A0 =A0 // doesn't compi=
le*<br></div><div>optional<complex> < complex=A0=A0=A0=A0=A0 // OK=
<br></div><div>optional<complex> < optional<complex> =A0=A0 =
// OK<br></div>
</div><br></div><div class=3D"gmail_extra">(*none of them compile - it'=
s not valid code, but you know what I mean).<br><br></div><div class=3D"gma=
il_extra">Instead we should specialize std::less<optional<T>> t=
o call std::less<T>.=A0 Then none of the above work, but you can stil=
l put both complex and optional<complex> into containers.<br>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b3441feb0de6d04dbc08898--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 23:33:55 +0300
Raw View
--047d7b33d31c4240c404dbc2274c
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 21:38, Tony V E <tvaneerd@gmail.com> wrote:
> implementing < via std::less is wrong as well - complex has (or will have)
> std::less, but not <.
>
> So, if < is implemented with std::less, we get:
>
> complex < complex // doesn't compile*
> optional<complex> < complex // OK
> optional<complex> < optional<complex> // OK
>
> (*none of them compile - it's not valid code, but you know what I mean).
>
> Instead we should specialize std::less<optional<T>> to call std::less<T>.
> Then none of the above work, but you can still put both complex and
> optional<complex> into containers.
>
>
Ok. Otherwise just requiring that op< is valid seems sufficient. So no
std::less, just use the underlying operator,
and add the specialization of less. This still doesn't require anything
else besides op<, I think we should, at least
for now, implement the others in terms of op<. NaNs be damned.
--
---
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.
--047d7b33d31c4240c404dbc2274c
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 2 May 2013 21:38, Tony V E <span dir=3D"ltr"><<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></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">implementing < via std::=
less is wrong as well - complex has (or will have) std::less, but not <.=
<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>S=
o, if < is implemented with std::less, we get:<br>
</div><div><br></div><div>complex < complex =A0 =A0 // doesn't compi=
le*<br></div><div>optional<complex> < complex=A0=A0=A0=A0=A0 // OK=
<br></div><div>optional<complex> < optional<complex> =A0=A0 =
// OK<br></div>
</div><br></div><div class=3D"gmail_extra">(*none of them compile - it'=
s not valid code, but you know what I mean).<br><br></div><div class=3D"gma=
il_extra">Instead we should specialize std::less<optional<T>> t=
o call std::less<T>.=A0 Then none of the above work, but you can stil=
l put both complex and optional<complex> into containers.<br>
</div></div><div class=3D"HOEnZb"><div>
<br></div></div></blockquote></div><br></div><div class=3D"gmail_extra">Ok.=
Otherwise just requiring that op< is valid seems sufficient. So no std:=
:less, just use the underlying operator,<br></div><div class=3D"gmail_extra=
">
and add the specialization of less. This still doesn't require anything=
else besides op<, I think we should, at least<br>for now, implement the=
others in terms of op<. NaNs be damned.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b33d31c4240c404dbc2274c--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 17:36:29 -0300
Raw View
--089e01494164d5681204dbc2324c
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 5:33 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 2 May 2013 21:38, Tony V E <tvaneerd@gmail.com> wrote:
>
>> implementing < via std::less is wrong as well - complex has (or will
>> have) std::less, but not <.
>>
>> So, if < is implemented with std::less, we get:
>>
>> complex < complex // doesn't compile*
>> optional<complex> < complex // OK
>> optional<complex> < optional<complex> // OK
>>
>> (*none of them compile - it's not valid code, but you know what I mean).
>>
>> Instead we should specialize std::less<optional<T>> to call
>> std::less<T>. Then none of the above work, but you can still put both
>> complex and optional<complex> into containers.
>>
>>
> Ok. Otherwise just requiring that op< is valid seems sufficient. So no
> std::less, just use the underlying operator,
> and add the specialization of less. This still doesn't require anything
> else besides op<, I think we should, at least
> for now, implement the others in terms of op<.
>
I guess with "others" you don't mean == / != as well.
> NaNs be damned.
>
Right
--
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.
--089e01494164d5681204dbc2324c
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=
hu, May 2, 2013 at 5:33 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></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"im"><br><div =
class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 2 May 2013 21:3=
8, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>></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">implementing < via std::=
less is wrong as well - complex has (or will have) std::less, but not <.=
<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>S=
o, if < is implemented with std::less, we get:<br>
</div><div><br></div><div>complex < complex =A0 =A0 // doesn't compi=
le*<br></div><div>optional<complex> < complex=A0=A0=A0=A0=A0 // OK=
<br></div><div>optional<complex> < optional<complex> =A0=A0 =
// OK<br></div>
</div><br></div><div class=3D"gmail_extra">(*none of them compile - it'=
s not valid code, but you know what I mean).<br><br></div><div class=3D"gma=
il_extra">Instead we should specialize std::less<optional<T>> t=
o call std::less<T>.=A0 Then none of the above work, but you can stil=
l put both complex and optional<complex> into containers.<br>
</div></div><div><div>
<br></div></div></blockquote></div><br></div></div><div class=3D"gmail_extr=
a">Ok. Otherwise just requiring that op< is valid seems sufficient. So n=
o std::less, just use the underlying operator,<br></div><div class=3D"gmail=
_extra">
and add the specialization of less. This still doesn't require anything=
else besides op<, I think we should, at least<br>for now, implement the=
others in terms of op<.</div></div></blockquote><div><br></div><div>
I guess with "others" you don't mean =3D=3D / !=3D as well.<b=
r><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 class=3D"gmail_extra">
NaNs be damned.<br></div></div></blockquote><div><br></div><div>Right<br>=
=A0<br></div></div><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSof=
t Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http=
://www.scisoft-consulting.com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e01494164d5681204dbc2324c--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 23:39:19 +0300
Raw View
--001a11c329328df88c04dbc23abd
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 23:36, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> Ok. Otherwise just requiring that op< is valid seems sufficient. So no
> std::less, just use the underlying operator,
>
>> and add the specialization of less. This still doesn't require anything
>> else besides op<, I think we should, at least
>> for now, implement the others in terms of op<.
>>
>
> I guess with "others" you don't mean == / != as well.
>
As soon as someone explains why boost::optional doesn't specify those
operators in terms of op<, maybe not.
In other words, no, I didn't mean those. ;)
>
> NaNs be damned.
>>
>
> Right
>
>
Objections to that view?
--
---
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.
--001a11c329328df88c04dbc23abd
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 2 May 2013 23:36, Fernando Cacciola <span dir=3D"ltr"><<a hre=
f=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciol=
a@gmail.com</a>></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 class=3D"h5">Ok. Otherwise just requir=
ing that op< is valid seems sufficient. So no std::less, just use the un=
derlying operator,<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">
and add the specialization of less. This still doesn't require anything=
else besides op<, I think we should, at least<br>for now, implement the=
others in terms of op<.</div></div></blockquote><div><br></div></div>
</div><div>
I guess with "others" you don't mean =3D=3D / !=3D as well.<b=
r></div></div></div></div></blockquote><div><br></div><div>As soon as someo=
ne explains why boost::optional doesn't specify those operators in term=
s of op<, maybe not.<br>
</div><div>In other words, no, I didn't mean those. ;)<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 dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<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">
NaNs be damned.<br></div></div></blockquote><div><br></div><div>Right<br><=
br></div></div></div></div></blockquote><div><br></div><div>Objections to t=
hat view? <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--001a11c329328df88c04dbc23abd--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 23:40:44 +0300
Raw View
--089e012948029c35bb04dbc23fe4
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 23:39, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
> I guess with "others" you don't mean == / != as well.
>
> As soon as someone explains why boost::optional doesn't specify those
> operators in terms of op<, maybe not.
> In other words, no, I didn't mean those. ;)
>
>
And right after writing that.. any type that wouldn't be usable with an
ordered associative container
wouldn't want its op== to be specified in terms of op<. So no, I think we
need to let op== be what
it is in boost::optional, and same for 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.
--089e012948029c35bb04dbc23fe4
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 2 May 2013 23:39, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></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 dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div>I guess with "oth=
ers" you don't mean =3D=3D / !=3D as well.<br>
</div></div></div></div><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div class=3D"im"><div><br></div></div><div>As soon as someone explains =
why boost::optional doesn't specify those operators in terms of op<,=
maybe not.<br>
</div><div>In other words, no, I didn't mean those. ;)<br><br></div></d=
iv></div></div></blockquote><div><br></div><div>And right after writing tha=
t.. any type that wouldn't be usable with an ordered associative contai=
ner<br>
wouldn't want its op=3D=3D to be specified in terms of op<. So no, I=
think we need to let op=3D=3D be what<br></div><div>it is in boost::option=
al, and same for op!=3D. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e012948029c35bb04dbc23fe4--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 23:47:35 +0300
Raw View
--089e012948022138ef04dbc2581a
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 23:40, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>
>
> On 2 May 2013 23:39, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>>
>> I guess with "others" you don't mean == / != as well.
>>
>> As soon as someone explains why boost::optional doesn't specify those
>> operators in terms of op<, maybe not.
>> In other words, no, I didn't mean those. ;)
>>
>>
> And right after writing that.. any type that wouldn't be usable with an
> ordered associative container
> wouldn't want its op== to be specified in terms of op<. So no, I think we
> need to let op== be what
> it is in boost::optional, and same for op!=.
>
>
Sigh.. so, a full circle, sort of. Use the boost::optional semantics as
they are for *all* relational operators,
and add the specialization for std::less<optional<T>>. Going further than
that should be an additional
and separate step, and should consider tuple and containers at the same
time.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--089e012948022138ef04dbc2581a
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 2 May 2013 23:40, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></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 class=3D"im">On 2 May 2013 23:3=
9, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilai=
nen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>></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 dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div>I guess with "oth=
ers" you don't mean =3D=3D / !=3D as well.<br>
</div></div></div></div><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div><div><br></div></div><div>As soon as someone explains why boost::op=
tional doesn't specify those operators in terms of op<, maybe not.<b=
r>
</div><div>In other words, no, I didn't mean those. ;)<br><br></div></d=
iv></div></div></blockquote><div><br></div></div><div>And right after writi=
ng that.. any type that wouldn't be usable with an ordered associative =
container<br>
wouldn't want its op=3D=3D to be specified in terms of op<. So no, I=
think we need to let op=3D=3D be what<br></div><div>it is in boost::option=
al, and same for op!=3D. <br></div></div><br></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">Sigh.. so, a full c=
ircle, sort of. Use the boost::optional semantics as they are for *all* rel=
ational operators,<br></div><div class=3D"gmail_extra">and add the speciali=
zation for std::less<optional<T>>. Going further than that shou=
ld be an additional<br>
and separate step, and should consider tuple and containers at the same tim=
e.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e012948022138ef04dbc2581a--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 17:53:16 -0300
Raw View
--047d7b344168d0d38404dbc26e12
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 5:47 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 2 May 2013 23:40, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>>
>>
>>
>> On 2 May 2013 23:39, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>>
>>>
>>> I guess with "others" you don't mean == / != as well.
>>>
>>> As soon as someone explains why boost::optional doesn't specify those
>>> operators in terms of op<, maybe not.
>>> In other words, no, I didn't mean those. ;)
>>>
>>>
>> And right after writing that.. any type that wouldn't be usable with an
>> ordered associative container
>> wouldn't want its op== to be specified in terms of op<. So no, I think we
>> need to let op== be what
>> it is in boost::optional, and same for op!=.
>>
>>
> Sigh.. so, a full circle, sort of. Use the boost::optional semantics as
> they are for *all* relational operators,
>
Which, for the record, is this:
optional<T> x == optional<T> y
return (!x) != (!y) ? false : ( !x ? true : (*x) == (*y) ) ;
optional<T> x != optional<T> y => ! ( x == y )
*******
optional<T> x < optional<T> y
return !y ? false : ( !x ? true : (*x) < (*y) ) ;
optional<T> x > optional<T> y => !( x < y ) ;
optional<T> x <= optional<T> y => !( y < x ) ;
optional<T> x >= optional<T> y => !( x < y ) ;
--
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.
--047d7b344168d0d38404dbc26e12
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=
hu, May 2, 2013 at 5:47 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></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"im"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"=
>On 2 May 2013 23:40, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"ma=
ilto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail=
..com</a>></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>On 2 May 201=
3 23:39, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.vo=
utilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>><=
/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=
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I g=
uess with "others" you don't mean =3D=3D / !=3D as well.<br>
</div></div></div></div><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div><div><br></div></div><div>As soon as someone explains why boost::op=
tional doesn't specify those operators in terms of op<, maybe not.<b=
r>
</div><div>In other words, no, I didn't mean those. ;)<br><br></div></d=
iv></div></div></blockquote><div><br></div></div><div>And right after writi=
ng that.. any type that wouldn't be usable with an ordered associative =
container<br>
wouldn't want its op=3D=3D to be specified in terms of op<. So no, I=
think we need to let op=3D=3D be what<br></div><div>it is in boost::option=
al, and same for op!=3D. <br></div></div><br></div></div>
</blockquote></div><br></div></div><div class=3D"gmail_extra">Sigh.. so, a =
full circle, sort of. Use the boost::optional semantics as they are for *al=
l* relational operators,<br></div></div></blockquote><div><br></div><div>
Which, for the record, is this:<br><br></div><div>optional<T> x =3D=
=3D optional<T> y<br><br>=A0 return (!x) !=3D (!y) ? false : ( !x ? t=
rue : (*x) =3D=3D (*y) ) ;<br><br>optional<T> x !=3D optional<T>=
; y=A0 =3D> ! ( x =3D=3D y )<br>
<br>*******<br><br></div><div>optional<T> x < optional<T> y<=
br><br>=A0 return !y ? false : ( !x ? true : (*x) < (*y) ) ;<br><br>opti=
onal<T> x > =A0 optional<T> y =3D>=A0=A0 !( x < y ) ;<=
br>optional<T> x <=3D optional<T> y =3D>=A0=A0 !( y < =
x ) ; <br>
optional<T> x >=3D optional<T> y =3D>=A0=A0 !( x < y )=
; <br></div><div><br></div></div><br clear=3D"all"><br>-- <br>Fernando Cac=
ciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consu=
lting.com">http://www.scisoft-consulting.com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b344168d0d38404dbc26e12--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 May 2013 23:58:38 +0300
Raw View
--001a11c32932a19fd404dbc27f1c
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 23:53, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>
> Which, for the record, is this:
>
> optional<T> x == optional<T> y
>
> return (!x) != (!y) ? false : ( !x ? true : (*x) == (*y) ) ;
>
> optional<T> x != optional<T> y => ! ( x == y )
>
> *******
>
> optional<T> x < optional<T> y
>
> return !y ? false : ( !x ? true : (*x) < (*y) ) ;
>
>
All good.
> optional<T> x > optional<T> y => !( x < y ) ;
>
Bug there. :P Should be y < x, as it is in the boost::optional
documentation. ;)
> optional<T> x <= optional<T> y => !( y < x ) ;
> optional<T> x >= optional<T> y => !( x < y ) ;
>
>
These are again correct.
--
---
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.
--001a11c32932a19fd404dbc27f1c
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 2 May 2013 23:53, Fernando Cacciola <span dir=3D"ltr"><<a hre=
f=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciol=
a@gmail.com</a>></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"><br></div><div>
Which, for the record, is this:<br><br></div><div>optional<T> x =3D=
=3D optional<T> y<br><br>=A0 return (!x) !=3D (!y) ? false : ( !x ? t=
rue : (*x) =3D=3D (*y) ) ;<br><br>optional<T> x !=3D optional<T>=
; y=A0 =3D> ! ( x =3D=3D y )<br>
<br>*******<br><br></div><div>optional<T> x < optional<T> y<=
br><br>=A0 return !y ? false : ( !x ? true : (*x) < (*y) ) ;<br><br></di=
v></div></div></div></blockquote><div><br></div><div>All good.<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 dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>optional<T> x > =A0 optional<T&=
gt; y =3D>=A0=A0 !( x < y ) ;<br>
</div></div></div></div></blockquote><div><br></div><div>Bug there. :P Shou=
ld be y < x, as it is in the boost::optional documentation. ;)<br><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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>optional<T> x <=3D optional<T> y =3D>=A0=A0 !( y < x =
) ; <br>
optional<T> x >=3D optional<T> y =3D>=A0=A0 !( x < y )=
; <br></div><div><br></div></div></div></div></blockquote><div><br><br></d=
iv><div>These are again correct.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--001a11c32932a19fd404dbc27f1c--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 18:00:01 -0300
Raw View
--001a11c33e24f6037404dbc286dd
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 5:58 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
>> optional<T> x > optional<T> y => !( x < y ) ;
>>
>
> Bug there. :P Should be y < x, as it is in the boost::optional
> documentation. ;)
>
> Good catch :)
--
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.
--001a11c33e24f6037404dbc286dd
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=
hu, May 2, 2013 at 5:58 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></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>=A0<br></div><div class=3D"im">
<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>optional<T> x > =A0 optional<T&=
gt; y =3D>=A0=A0 !( x < y ) ;<br>
</div></div></div></div></blockquote><div><br></div></div><div>Bug there. :=
P Should be y < x, as it is in the boost::optional documentation. ;)<br>=
<br></div></div></div></div></blockquote><div>Good catch :)<br>=A0<br></div=
>
</div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a hre=
f=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting.com</=
a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--001a11c33e24f6037404dbc286dd--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 2 May 2013 23:01:05 +0200
Raw View
2013/5/2 Fernando Cacciola <fernando.cacciola@gmail.com>:
> On Thu, May 2, 2013 at 5:47 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>>
>> On 2 May 2013 23:40, Ville Voutilainen <ville.voutilainen@gmail.com>
>> wrote:
>>>
>>>
>>> On 2 May 2013 23:39, Ville Voutilainen <ville.voutilainen@gmail.com>
>>> wrote:
>>>>
>>>>
>>>> I guess with "others" you don't mean == / != as well.
>>>>
>>>> As soon as someone explains why boost::optional doesn't specify those
>>>> operators in terms of op<, maybe not.
>>>> In other words, no, I didn't mean those. ;)
>>>>
>>>
>>> And right after writing that.. any type that wouldn't be usable with an
>>> ordered associative container
>>> wouldn't want its op== to be specified in terms of op<. So no, I think we
>>> need to let op== be what
>>> it is in boost::optional, and same for op!=.
>>>
>>
>> Sigh.. so, a full circle, sort of. Use the boost::optional semantics as
>> they are for *all* relational operators,
>
>
> Which, for the record, is this:
>
> optional<T> x == optional<T> y
>
> return (!x) != (!y) ? false : ( !x ? true : (*x) == (*y) ) ;
>
> optional<T> x != optional<T> y => ! ( x == y )
>
> *******
>
> optional<T> x < optional<T> y
>
> return !y ? false : ( !x ? true : (*x) < (*y) ) ;
>
> optional<T> x > optional<T> y => !( x < y ) ;
modulo the typo here.
> optional<T> x <= optional<T> y => !( y < x ) ;
> optional<T> x >= optional<T> y => !( x < y ) ;
... and these are all consistent with pair/tuple. In fact we had in a
previous iteration a state of the proposal where we had exactly these
semantics suggested.
- Daniel
--
---
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.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 00:05:08 +0300
Raw View
--089e013a1978e0db6504dbc29602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 3 May 2013 00:01, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
> .. and these are all consistent with pair/tuple. In fact we had in a
> previous iteration a state of the proposal where we had exactly these
> semantics suggested.
>
>
>
Precisely. And I want to restore that state, and add a std::less
specialization, and do anything more elaborate
separately, _if at all_. However, regarding std::less, we need to look at
whether we want to do a specialization
of it for pair/tuple too, I guess. tuple<T*> will not work right as an
ordered associative container key, if I
understand correctly.
--=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.
--089e013a1978e0db6504dbc29602
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 00:01, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=
=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">.. and these are all consistent with pair/tu=
ple. In fact we had in a<br>
previous iteration a state of the proposal where we had exactly these<br>
semantics suggested.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>Precisely. And I want to restore that state, and=
add a std::less specialization, and do anything more elaborate<br>separate=
ly, _if at all_. However, regarding std::less, we need to look at whether w=
e want to do a specialization<br>
of it for pair/tuple too, I guess. tuple<T*> will not work right as a=
n ordered associative container key, if I<br>understand correctly.<br></div=
></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--089e013a1978e0db6504dbc29602--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 2 May 2013 23:08:19 +0200
Raw View
2013/5/2 Ville Voutilainen <ville.voutilainen@gmail.com>:
>
> On 3 May 2013 00:01, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
>>
>> .. and these are all consistent with pair/tuple. In fact we had in a
>> previous iteration a state of the proposal where we had exactly these
>> semantics suggested.
>>
> Precisely. And I want to restore that state, and add a std::less
> specialization, and do anything more elaborate
> separately, _if at all_. However, regarding std::less, we need to look at
> whether we want to do a specialization
> of it for pair/tuple too, I guess. tuple<T*> will not work right as an
> ordered associative container key, if I
> understand correctly.
IMO the addition of specialization of less for either pair, tuple, and
optional should be done be a separate proposal or issue. I don't
understand why optional should be considered so much special in that
regard. Of-course, if consensus could *only* be found by also adding a
specialization std::less<optional<T>>, this would be acceptable to me.
- Daniel
--=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.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 00:09:39 +0300
Raw View
--047d7b2e0887075c4604dbc2a761
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 3 May 2013 00:08, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
> 2013/5/2 Ville Voutilainen <ville.voutilainen@gmail.com>:
> > Precisely. And I want to restore that state, and add a std::less
> > specialization, and do anything more elaborate
> > separately, _if at all_. However, regarding std::less, we need to look =
at
> > whether we want to do a specialization
> > of it for pair/tuple too, I guess. tuple<T*> will not work right as an
> > ordered associative container key, if I
> > understand correctly.
>
> IMO the addition of specialization of less for either pair, tuple, and
> optional should be done be a separate proposal or issue. I don't
>
Sounds good to me.
> understand why optional should be considered so much special in that
> regard. Of-course, if consensus could *only* be found by also adding a
> specialization std::less<optional<T>>, this would be acceptable to me.
>
>
>
Likewise.
--=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.
--047d7b2e0887075c4604dbc2a761
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 00:08, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=
=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/5/2 Ville Voutilainen <<a href=3D"ma=
ilto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>>:<br>
<div><div class=3D"h5">> Precisely. And I want to restore that state, an=
d add a std::less<br>
> specialization, and do anything more elaborate<br>
> separately, _if at all_. However, regarding std::less, we need to look=
at<br>
> whether we want to do a specialization<br>
> of it for pair/tuple too, I guess. tuple<T*> will not work right=
as an<br>
> ordered associative container key, if I<br>
> understand correctly.<br>
<br>
</div></div>IMO the addition of specialization of less for either pair, tup=
le, and<br>
optional should be done be a separate proposal or issue. I don't<br></b=
lockquote><div><br></div><div>Sounds good to me.<br>=A0<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
understand why optional should be considered so much special in that<br>
regard. Of-course, if consensus could *only* be found by also adding a<br>
specialization std::less<optional<T>>, this would be acceptable=
to me.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br><br></div></div></blockquote><d=
iv><br></div><div>Likewise. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b2e0887075c4604dbc2a761--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 18:12:51 -0300
Raw View
--001a11c2a884de8d3d04dbc2b47c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, May 2, 2013 at 6:01 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.com=
>wrote:
>
> .. and these are all consistent with pair/tuple. In fact we had in a
> previous iteration a state of the proposal where we had exactly these
> semantics suggested.
>
>
Indeed.
This is the semantics that Andrzej and I (or at least I) really wanted. But
during the discussion here, before Bristol, it generated a lot of
controversy and somehow we ended up shaping it into what was finally
proposed.
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--001a11c2a884de8d3d04dbc2b47c
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=
hu, May 2, 2013 at 6:01 PM, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=
=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>.. and these are all consistent with pai=
r/tuple. In fact we had in a<br>
previous iteration a state of the proposal where we had exactly these<br>
semantics suggested.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>Indeed.<br></div><div>This is the semantics that And=
rzej and I (or at least I) really wanted. But during the discussion here, b=
efore Bristol, it generated a lot of controversy and somehow we ended up sh=
aping it into what was finally proposed.<br>
<br></div></div><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft C=
onsulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://=
www.scisoft-consulting.com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--001a11c2a884de8d3d04dbc2b47c--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 00:18:03 +0300
Raw View
--14dae93b5e3616a62304dbc2c5a3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 3 May 2013 00:12, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Thu, May 2, 2013 at 6:01 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.c=
om>wrote:
>
>>
>> .. and these are all consistent with pair/tuple. In fact we had in a
>> previous iteration a state of the proposal where we had exactly these
>> semantics suggested.
>>
>>
> Indeed.
> This is the semantics that Andrzej and I (or at least I) really wanted.
> But during the discussion here, before Bristol, it generated a lot of
> controversy and somehow we ended up shaping it into what was finally
> proposed.
>
>
>
While that discussion was illuminating, it was also confusing, and the
right evolution path is to use the boost::optional semantics
(which happen to be consistent with pair/tuple as a bonus point), and take
separate steps for the
other wishlist items.
--=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.
--14dae93b5e3616a62304dbc2c5a3
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 00:12, Fernando Cacciola <span dir=3D"ltr"><<a hre=
f=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciol=
a@gmail.com</a>></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 Thu, May 2, 2013 at 6:01 PM=
, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=3D"mailto:daniel.kruegler@=
gmail.com" target=3D"_blank">daniel.kruegler@gmail.com</a>></span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>.. and these are all consistent with pai=
r/tuple. In fact we had in a<br>
previous iteration a state of the proposal where we had exactly these<br>
semantics suggested.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
></div><div>Indeed.<br></div><div>This is the semantics that Andrzej and I =
(or at least I) really wanted. But during the discussion here, before Brist=
ol, it generated a lot of controversy and somehow we ended up shaping it in=
to what was finally proposed.<br>
<br><br></div></div></div></div></blockquote><div><br></div><div>While that=
discussion was illuminating, it was also confusing, and the right evolutio=
n path is to use the boost::optional semantics<br></div><div>(which happen =
to be consistent with pair/tuple as a bonus point), and take separate steps=
for the<br>
other wishlist items. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--14dae93b5e3616a62304dbc2c5a3--
.