Topic: Fixing Standard Library relational operators (was:
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 2 May 2013 16:19:35 -0500
Raw View
--00151757716404d22204dbc2cdd6
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 16:05, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>
> 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.
>
If we are going for consistency and correctness among everything in the
standard library, is this correct solution:
operator< should be implemented in terms of operator< of the underlying
component(s)
operator== should be implemented in terms of operator== of the underlying
component(s)
std::less should be implemented in terms of std::less of the underlying
component(s)
std::equal_to should be implemented in terms of std::equal_to of the
underlying component(s)
operator>, operator<=, operator>= should be written in terms of operator<
operator!= should be written in terms of operator==
std::greater, std::less_equal, std::greater_equal should be written in
terms of std::less
std::not_equal_to should be written in terms of std::equal_to
--
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.
--00151757716404d22204dbc2cdd6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 2 May 2013 16:05, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mai=
lto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.=
com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div>Precisely. And I want to restore that state, and add a std::less s=
pecialization, and do anything more elaborate<br>separately, _if at all_. H=
owever, regarding std::less, we need to look at whether we want to do a spe=
cialization<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></div></div></blockquote><div><br>If we are going for consistency an=
d correctness among everything in the standard library, is this correct sol=
ution:<br>
<br>operator< should be implemented in terms of operator< of the unde=
rlying component(s)<br>operator=3D=3D should be implemented in terms of ope=
rator=3D=3D of the underlying component(s)<br>std::less should be implement=
ed in terms of std::less of the underlying component(s)<br>
std::equal_to should be implemented in terms of std::equal_to of the underl=
ying component(s)<br><br>operator>, operator<=3D, operator>=3D sho=
uld be written in terms of operator<<br>operator!=3D should be written i=
n terms of operator=3D=3D<br>
std::greater, std::less_equal, std::greater_equal should be written in term=
s of std::less<br>std::not_equal_to should be written in terms of std::equa=
l_to<br></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 />
--00151757716404d22204dbc2cdd6--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 00:24:09 +0300
Raw View
--089e01175d63ee959504dbc2da63
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 00:19, Nevin Liber <nevin@eviloverlord.com> wrote:
> If we are going for consistency and correctness among everything in the
> standard library, is this correct solution:
>
> operator< should be implemented in terms of operator< of the underlying
> component(s)
> operator== should be implemented in terms of operator== of the underlying
> component(s)
> std::less should be implemented in terms of std::less of the underlying
> component(s)
> std::equal_to should be implemented in terms of std::equal_to of the
> underlying component(s)
>
> operator>, operator<=, operator>= should be written in terms of operator<
> operator!= should be written in terms of operator==
> std::greater, std::less_equal, std::greater_equal should be written in
> terms of std::less
> std::not_equal_to should be written in terms of std::equal_to
>
>
Seems correct to me, off the top of my hat.
--
---
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.
--089e01175d63ee959504dbc2da63
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:19, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">If we are going for consistency and correctn=
ess among everything in the standard library, is this correct solution:<br>
<div class=3D"gmail_quote"><div>
<br>operator< should be implemented in terms of operator< of the unde=
rlying component(s)<br>operator=3D=3D should be implemented in terms of ope=
rator=3D=3D of the underlying component(s)<br>std::less should be implement=
ed in terms of std::less of the underlying component(s)<br>
std::equal_to should be implemented in terms of std::equal_to of the underl=
ying component(s)<br><br>operator>, operator<=3D, operator>=3D sho=
uld be written in terms of operator<<br>operator!=3D should be written i=
n terms of operator=3D=3D<br>
std::greater, std::less_equal, std::greater_equal should be written in term=
s of std::less<br>std::not_equal_to should be written in terms of std::equa=
l_to<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div>
</div><span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></bl=
ockquote><div><br></div><div>Seems correct to me, off the top of my hat. <b=
r></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 />
--089e01175d63ee959504dbc2da63--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 18:24:51 -0300
Raw View
--001a11c33e24c3b1eb04dbc2dfb6
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 6:19 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 2 May 2013 16:05, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>>
>>
>> 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.
>>
>
> If we are going for consistency and correctness among everything in the
> standard library, is this correct solution:
>
> operator< should be implemented in terms of operator< of the underlying
> component(s)
> operator== should be implemented in terms of operator== of the underlying
> component(s)
> std::less should be implemented in terms of std::less of the underlying
> component(s)
> std::equal_to should be implemented in terms of std::equal_to of the
> underlying component(s)
>
> operator>, operator<=, operator>= should be written in terms of operator<
> operator!= should be written in terms of operator==
> std::greater, std::less_equal, std::greater_equal should be written in
> terms of std::less
> std::not_equal_to should be written in terms of std::equal_to
>
Actually, if we are going to fix the *entire* library, then we *could*
chose to have all operators boild down to the underlying component(s)
IIRC, the main reason for not doing so is consistency across the SCL.
--
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.
--001a11c33e24c3b1eb04dbc2dfb6
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:19 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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">On 2 May 2013 16:05, 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>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div>Precisely. And I want to restore that state, and add a std::less s=
pecialization, and do anything more elaborate<br>separately, _if at all_. H=
owever, regarding std::less, we need to look at whether we want to do a spe=
cialization<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></div></div></blockquote><div><br>If we are going for consistency an=
d correctness among everything in the standard library, is this correct sol=
ution:<br>
<br>operator< should be implemented in terms of operator< of the unde=
rlying component(s)<br>operator=3D=3D should be implemented in terms of ope=
rator=3D=3D of the underlying component(s)<br>std::less should be implement=
ed in terms of std::less of the underlying component(s)<br>
std::equal_to should be implemented in terms of std::equal_to of the underl=
ying component(s)<br><br>operator>, operator<=3D, operator>=3D sho=
uld be written in terms of operator<<br>operator!=3D should be written i=
n terms of operator=3D=3D<br>
std::greater, std::less_equal, std::greater_equal should be written in term=
s of std::less<br>std::not_equal_to should be written in terms of std::equa=
l_to<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div>
</div></blockquote><div><br></div><div>Actually, if we are going to fix the=
*entire* library, then we *could* chose to have all operators boild down t=
o the underlying component(s)<br><br></div><div>IIRC, the main reason for n=
ot doing so is consistency across the SCL.<br>
<br></div><div>=A0<br clear=3D"all"></div></div><br>-- <br>Fernando Cacciol=
a<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consultin=
g.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 />
--001a11c33e24c3b1eb04dbc2dfb6--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 2 May 2013 16:29:31 -0500
Raw View
--20cf3074d4e87c3f2a04dbc2f0b7
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 16:24, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>
> Actually, if we are going to fix the *entire* library, then we *could*
> chose to have all operators boild down to the underlying component(s)
>
That would be a major breaking change, since some people count on the
standard library synthesizing operators for them. I'm certainly not going
to propose that.
--
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.
--20cf3074d4e87c3f2a04dbc2f0b7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 2 May 2013 16:24, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mai=
lto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.=
com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div class=3D"h5"><br></div></div><div>Actually, if we are going to fix th=
e *entire* library, then we *could* chose to have all operators boild down =
to the underlying component(s)<br>
</div></div></div></div></blockquote><div><br>That would be a major breakin=
g change, since some people count on the standard library synthesizing oper=
ators for them. I'm certainly not going to propose that.<br clear=3D"al=
l">
</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 />
--20cf3074d4e87c3f2a04dbc2f0b7--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 18:29:55 -0300
Raw View
--001a11c2a9b8ec844704dbc2f1e2
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 6:24 PM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:
> On Thu, May 2, 2013 at 6:19 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
>
>> On 2 May 2013 16:05, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>>
>>>
>>>
>>> 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.
>>>
>>
>> If we are going for consistency and correctness among everything in the
>> standard library, is this correct solution:
>>
>> operator< should be implemented in terms of operator< of the underlying
>> component(s)
>> operator== should be implemented in terms of operator== of the underlying
>> component(s)
>> std::less should be implemented in terms of std::less of the underlying
>> component(s)
>> std::equal_to should be implemented in terms of std::equal_to of the
>> underlying component(s)
>>
>> operator>, operator<=, operator>= should be written in terms of operator<
>> operator!= should be written in terms of operator==
>> std::greater, std::less_equal, std::greater_equal should be written in
>> terms of std::less
>> std::not_equal_to should be written in terms of std::equal_to
>>
>
> Actually, if we are going to fix the *entire* library, then we *could*
> chose to have all operators boild down to the underlying component(s)
>
> IIRC, the main reason for not doing so is consistency across the SCL.
>
> But let me clarify, I'm NOT saying we should do that (in fact, I like your
proposal here a lot), only that we might not have a good reason to make
everything based on < and == if we are completely consistent.
IIRC, the issue with defining > in terms of < is that it messes up with
non-totally ordered types.
OTOH, if you do have such a type (why would you, but that's not up to me),
I guess it would be reasonable to require you to specialize wrappers and
containers accordingly (which is always possible in any case)
--
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.
--001a11c2a9b8ec844704dbc2f1e2
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:24 PM, Fernando Cacciola <span dir=3D"ltr"><<a href=
=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.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">On Thu, May 2, 2013 at 6:19 PM=
, Nevin Liber <span dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.co=
m" target=3D"_blank">nevin@eviloverlord.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">On 2 May 2013 16:05, 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>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div>Precisely. And I want to restore that state, and add a std::less s=
pecialization, and do anything more elaborate<br>separately, _if at all_. H=
owever, regarding std::less, we need to look at whether we want to do a spe=
cialization<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></div></div></blockquote><div><br>If we are going for consistency an=
d correctness among everything in the standard library, is this correct sol=
ution:<br>
<br>operator< should be implemented in terms of operator< of the unde=
rlying component(s)<br>operator=3D=3D should be implemented in terms of ope=
rator=3D=3D of the underlying component(s)<br>std::less should be implement=
ed in terms of std::less of the underlying component(s)<br>
std::equal_to should be implemented in terms of std::equal_to of the underl=
ying component(s)<br><br>operator>, operator<=3D, operator>=3D sho=
uld be written in terms of operator<<br>operator!=3D should be written i=
n terms of operator=3D=3D<br>
std::greater, std::less_equal, std::greater_equal should be written in term=
s of std::less<br>std::not_equal_to should be written in terms of std::equa=
l_to<span><font color=3D"#888888"><br></font></span></div>
</div></blockquote><div><br></div></div><div>Actually, if we are going to f=
ix the *entire* library, then we *could* chose to have all operators boild =
down to the underlying component(s)<br><br></div><div>IIRC, the main reason=
for not doing so is consistency across the SCL.<span class=3D"HOEnZb"><fon=
t color=3D"#888888"><br>
<br></font></span></div></div></div></div></blockquote><div>But let me clar=
ify, I'm NOT saying we should do that (in fact, I like your proposal he=
re a lot), only that we might not have a good reason to make everything bas=
ed on < and =3D=3D if we are completely consistent.<br>
<br></div><div>IIRC, the issue with defining > in terms of < is that =
it messes up with non-totally ordered types. <br></div><div>OTOH, if you do=
have such a type (why would you, but that's not up to me), I guess it =
would be reasonable to require you to specialize wrappers and containers ac=
cordingly (which is always possible in any case)<br>
<br clear=3D"all"></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 />
--001a11c2a9b8ec844704dbc2f1e2--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 18:31:30 -0300
Raw View
--047d7b344168942af404dbc2f747
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 6:29 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 2 May 2013 16:24, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>>
>> Actually, if we are going to fix the *entire* library, then we *could*
>> chose to have all operators boild down to the underlying component(s)
>>
>
> That would be a major breaking change, since some people count on the
> standard library synthesizing operators for them. I'm certainly not going
> to propose that.
>
Hmm, of course. We can't change what's already defined that way.
Well, then I'm all sold.
>
>
--
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.
--047d7b344168942af404dbc2f747
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:29 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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">On 2 May 2013 16:24, Ferna=
ndo Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmai=
l.com" target=3D"_blank">fernando.cacciola@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">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div><br></div></div><div>Actually, if we are going to fix the *entire* li=
brary, then we *could* chose to have all operators boild down to the underl=
ying component(s)<br>
</div></div></div></div></blockquote></div><div><br>That would be a major b=
reaking change, since some people count on the standard library synthesizin=
g operators for them. I'm certainly not going to propose that.<br clear=
=3D"all">
</div></div></blockquote><div><br></div><div>Hmm, of course. We can't c=
hange what's already defined that way.<br><br>Well,=A0 then I'm all=
sold.<br>=A0<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>
</div></div><br></blockquote></div><br clear=3D"all"><br>-- <br>Fernando Ca=
cciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-cons=
ulting.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 />
--047d7b344168942af404dbc2f747--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 00:33:15 +0300
Raw View
--047d7b33d31c749e6104dbc2fbab
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 00:31, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>
> Well, then I'm all sold.
>
>
We haven't yet heard such statements from the people who are harder to
convince. ;)
--
---
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.
--047d7b33d31c749e6104dbc2fbab
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:31, 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"><br><div>Well,=A0 then I'm all sold.<br><br>=
</div></div>
</div></div></blockquote><div><br></div><div>We haven't yet heard such =
statements from the people who are harder to convince.=A0 ;)<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 />
--047d7b33d31c749e6104dbc2fbab--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 18:38:15 -0300
Raw View
--047d7b344168bc030104dbc30fa5
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 6:33 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 3 May 2013 00:31, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>>
>> Well, then I'm all sold.
>>
>>
> We haven't yet heard such statements from the people who are harder to
> convince. ;)
>
> And actually vote :)
I don't see myself going to a meeting as a National Body representative in
any future... I still haven't got the standards organization here in
Argentina (IRAM) to even note there is something called C++.
--
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.
--047d7b344168bc030104dbc30fa5
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: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"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 3 May 2013 00:3=
1, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacci=
ola@gmail.com" target=3D"_blank">fernando.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"><br><div>Well,=A0 then I'm all sold.<br><br>=
</div></div>
</div></div></blockquote><div><br></div></div><div>We haven't yet heard=
such statements from the people who are harder to convince.=A0 ;)<br></div=
></div><br></div></div></blockquote><div>And actually vote :)<br><br></div>
<div>I don't see myself going to a meeting as a National Body represent=
ative in any future... I still haven't got the standards organization h=
ere in Argentina (IRAM) to even note there is something called C++. </div>
<br></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a=
href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting.c=
om</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 />
--047d7b344168bc030104dbc30fa5--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Thu, 2 May 2013 17:08:42 -0500
Raw View
--089e01176f719a4c3e04dbc37cd2
Content-Type: text/plain; charset=ISO-8859-1
As far as I know, ballot voting does not require that an NB representative
attends the meeting. However I think it requires that the country is a
P-Member.
I do not know if Argentina is P-Member or O-Member for SC22.
Regards!
--
J. Daniel Garcia
On Thu, May 2, 2013 at 4:38 PM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:
> On Thu, May 2, 2013 at 6:33 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>>
>>
>> On 3 May 2013 00:31, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>>
>>>
>>> Well, then I'm all sold.
>>>
>>>
>> We haven't yet heard such statements from the people who are harder to
>> convince. ;)
>>
>> And actually vote :)
>
> I don't see myself going to a meeting as a National Body representative
> in any future... I still haven't got the standards organization here in
> Argentina (IRAM) to even note there is something called C++.
>
>
> --
> 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.
>
>
>
--
---
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.
--089e01176f719a4c3e04dbc37cd2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As far as I know, ballot voting does not require that an N=
B representative attends the meeting. However I think it requires that the =
country is a P-Member.<div><br></div><div style>I do not know if Argentina =
is P-Member or O-Member for SC22.</div>
<div style><br></div><div style>Regards!</div><div style>--</div><div style=
>=A0 J. Daniel Garcia</div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">On Thu, May 2, 2013 at 4:38 PM, Fernando Cacciola <span dir=
=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blan=
k">fernando.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">On Thu, May 2, 2013 at 6:33 PM=
, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilain=
en@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>On 3 May 2013 00:31, Fernando C=
acciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmail.com=
" target=3D"_blank">fernando.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"><br><div>Well,=A0 then I'm all sold.<br><br>=
</div></div>
</div></div></blockquote><div><br></div></div><div>We haven't yet heard=
such statements from the people who are harder to convince.=A0 ;)<br></div=
></div><br></div></div></blockquote></div><div>And actually vote :)<br><br>
</div>
<div>I don't see myself going to a meeting as a National Body represent=
ative in any future... I still haven't got the standards organization h=
ere in Argentina (IRAM) to even note there is something called C++. </div>
<br></div><div class=3D"im"><br>-- <br>Fernando Cacciola<br>SciSoft Consult=
ing, Founder<br><a href=3D"http://www.scisoft-consulting.com" target=3D"_bl=
ank">http://www.scisoft-consulting.com</a>
</div></div></div>
<p></p>
-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=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 />
--089e01176f719a4c3e04dbc37cd2--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 19:15:35 -0300
Raw View
--047d7b3a897a3fe14704dbc395ac
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 7:08 PM, J. Daniel Garcia
<josedaniel.garcia@uc3m.es>wrote:
> As far as I know, ballot voting does not require that an NB representative
> attends the meeting. However I think it requires that the country is a
> P-Member.
>
>
That's what I understood as well.
> I do not know if Argentina is P-Member or O-Member for SC22.
>
> Me neither. As far as I could trace on the ISO pages, I should consult
IRAM. That's what I did, and I'm waiting for them to get back to me with
the answer. It's been a year :(
(and I did try again a few timews)
--
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.
--047d7b3a897a3fe14704dbc395ac
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 7:08 PM, J. Daniel Garcia <span dir=3D"ltr"><<a href=
=3D"mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garcia@u=
c3m.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">As far as I know, ballot vo=
ting does not require that an NB representative attends the meeting. Howeve=
r I think it requires that the country is a P-Member.<div>
<br></div></div></blockquote><div><br></div><div>That's what I understo=
od as well.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>
</div><div>I do not know if Argentina is P-Member or O-Member for SC22.</di=
v>
<div><br></div></div></blockquote><div>Me neither. As far as I could trace =
on the ISO pages, I should consult IRAM. That's what I did, and I'm=
waiting for them to get back to me with the answer. It's been a year :=
(<br>
</div><div>(and I did try again a few timews)<br><br></div></div>-- <br>Fer=
nando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scis=
oft-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 />
--047d7b3a897a3fe14704dbc395ac--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 01:25:06 +0300
Raw View
--001a11c35fbada774704dbc3b477
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 01:15, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Thu, May 2, 2013 at 7:08 PM, J. Daniel Garcia <
> josedaniel.garcia@uc3m.es> wrote:
>
>> As far as I know, ballot voting does not require that an NB
>> representative attends the meeting. However I think it requires that the
>> country is a P-Member.
>>
>>
> That's what I understood as well.
>
>
>> I do not know if Argentina is P-Member or O-Member for SC22.
>>
>> Me neither. As far as I could trace on the ISO pages, I should consult
> IRAM. That's what I did, and I'm waiting for them to get back to me with
> the answer. It's been a year :(
> (and I did try again a few timews)
>
>
Looks like IRAM is an O-member.
http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee_participation.htm?commid=45202
--
---
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.
--001a11c35fbada774704dbc3b477
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 01:15, 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:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im">On Thu, May=
2, 2013 at 7:08 PM, J. Daniel Garcia <span dir=3D"ltr"><<a href=3D"mail=
to:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.es</=
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">As far a=
s I know, ballot voting does not require that an NB representative attends =
the meeting. However I think it requires that the country is a P-Member.<di=
v>
<br></div></div></blockquote><div><br></div></div><div>That's what I un=
derstood as well.<br>=A0<br></div><div class=3D"im"><blockquote class=3D"gm=
ail_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>
</div><div>I do not know if Argentina is P-Member or O-Member for SC22.</di=
v>
<div><br></div></div></blockquote></div><div>Me neither. As far as I could =
trace on the ISO pages, I should consult IRAM. That's what I did, and I=
'm waiting for them to get back to me with the answer. It's been a =
year :(<br>
</div><div>(and I did try again a few timews)<br><br></div></div></div></di=
v></blockquote><div><br></div><div>Looks like IRAM is an O-member. <br><a h=
ref=3D"http://www.iso.org/iso/home/standards_development/list_of_iso_techni=
cal_committees/iso_technical_committee_participation.htm?commid=3D45202">ht=
tp://www.iso.org/iso/home/standards_development/list_of_iso_technical_commi=
ttees/iso_technical_committee_participation.htm?commid=3D45202</a> <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 />
--001a11c35fbada774704dbc3b477--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 19:31:54 -0300
Raw View
--089e013d17a495e6e004dbc3cfe1
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 7:25 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 3 May 2013 01:15, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> On Thu, May 2, 2013 at 7:08 PM, J. Daniel Garcia <
>> josedaniel.garcia@uc3m.es> wrote:
>>
>>> As far as I know, ballot voting does not require that an NB
>>> representative attends the meeting. However I think it requires that the
>>> country is a P-Member.
>>>
>>>
>> That's what I understood as well.
>>
>>
>>> I do not know if Argentina is P-Member or O-Member for SC22.
>>>
>>> Me neither. As far as I could trace on the ISO pages, I should consult
>> IRAM. That's what I did, and I'm waiting for them to get back to me with
>> the answer. It's been a year :(
>> (and I did try again a few timews)
>>
>>
> Looks like IRAM is an O-member.
>
> http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee_participation.htm?commid=45202
>
> Oh.. thanks :) Time to retrained my web searching techniques.
I happen to found on the isocpp pages that I can pay U$S 1200 a year to
join as a member of the US NB. I'll think I'll fire up GNU Cash and run
some numbers, this could be a very good idea.
--
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.
--089e013d17a495e6e004dbc3cfe1
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 7:25 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 3 May 2013 01:1=
5, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacci=
ola@gmail.com" target=3D"_blank">fernando.cacciola@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"gmail_extra"><div class=3D"gmail_quote"><div>On Thu, May 2, 2013 at 7=
:08 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:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">As far a=
s I know, ballot voting does not require that an NB representative attends =
the meeting. However I think it requires that the country is a P-Member.<di=
v>
<br></div></div></blockquote><div><br></div></div><div>That's what I un=
derstood as well.<br>=A0<br></div><div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
<div dir=3D"ltr"><div>
</div><div>I do not know if Argentina is P-Member or O-Member for SC22.</di=
v>
<div><br></div></div></blockquote></div><div>Me neither. As far as I could =
trace on the ISO pages, I should consult IRAM. That's what I did, and I=
'm waiting for them to get back to me with the answer. It's been a =
year :(<br>
</div><div>(and I did try again a few timews)<br><br></div></div></div></di=
v></blockquote><div><br></div></div><div>Looks like IRAM is an O-member. <b=
r><a href=3D"http://www.iso.org/iso/home/standards_development/list_of_iso_=
technical_committees/iso_technical_committee_participation.htm?commid=3D452=
02" target=3D"_blank">http://www.iso.org/iso/home/standards_development/lis=
t_of_iso_technical_committees/iso_technical_committee_participation.htm?com=
mid=3D45202</a> <br>
</div></div><br></div></div></blockquote><div>Oh.. thanks :) Time to retrai=
ned my web searching techniques.<br><br></div><div>I happen to found on the=
isocpp pages that I can pay U$S 1200 a year to join as a member of the US =
NB. I'll think I'll fire up GNU Cash and run some numbers, this cou=
ld be a very good idea.<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 />
--089e013d17a495e6e004dbc3cfe1--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 01:36:12 +0300
Raw View
--089e013a197895610504dbc3dcaa
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 01:31, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> Me neither. As far as I could trace on the ISO pages, I should consult
> IRAM. That's what I did, and I'm waiting for them to get back to me with
> the answer. It's been a year :(
>
>> (and I did try again a few timews)
>>>
>>>
>> Looks like IRAM is an O-member.
>>
>> http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee_participation.htm?commid=45202
>>
>> Oh.. thanks :) Time to retrained my web searching techniques.
>
> I happen to found on the isocpp pages that I can pay U$S 1200 a year to
> join as a member of the US NB. I'll think I'll fire up GNU Cash and run
> some numbers, this could be a very good idea.
>
>
>
For Argentinian bodies, you should probably contact INTI first, they seem
to deal with software. IRAM
might not grok it. See http://www.inti.gob.ar/nanotecnologia/contacto.htm,
apparently Hector Laiz
is the INTI person in IRAM. That guy might even have a slightest clue about
what programming languages
are. ;)
--
---
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.
--089e013a197895610504dbc3dcaa
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 01:31, 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:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5">Me nei=
ther. As far as I could trace on the ISO pages, I should consult IRAM. That=
's what I did, and I'm waiting for them to get back to me with the =
answer. It's been a year :(<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>(and I did try again a few timews)<br><br></div></div></div></div></blockq=
uote><div><br></div></div><div>Looks like IRAM is an O-member. <br><a href=
=3D"http://www.iso.org/iso/home/standards_development/list_of_iso_technical=
_committees/iso_technical_committee_participation.htm?commid=3D45202" targe=
t=3D"_blank">http://www.iso.org/iso/home/standards_development/list_of_iso_=
technical_committees/iso_technical_committee_participation.htm?commid=3D452=
02</a> <br>
</div></div><br></div></div></blockquote></div></div><div>Oh.. thanks :) Ti=
me to retrained my web searching techniques.<br><br></div><div>I happen to =
found on the isocpp pages that I can pay U$S 1200 a year to join as a membe=
r of the US NB. I'll think I'll fire up GNU Cash and run some numbe=
rs, this could be a very good idea.<br>
</div><div><br><br></div></div></div></div></blockquote><div><br></div><div=
>For Argentinian bodies, you should probably contact INTI first, they seem =
to deal with software. IRAM<br>might not grok it. See <a href=3D"http://www=
..inti.gob.ar/nanotecnologia/contacto.htm">http://www.inti.gob.ar/nanotecnol=
ogia/contacto.htm</a>, apparently Hector Laiz<br>
is the INTI person in IRAM. That guy might even have a slightest clue about=
what programming languages<br>are. ;) <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 />
--089e013a197895610504dbc3dcaa--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 19:38:52 -0300
Raw View
--001a11c2a9b88110f404dbc3e893
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 7:36 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 3 May 2013 01:31, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> Me neither. As far as I could trace on the ISO pages, I should consult
>> IRAM. That's what I did, and I'm waiting for them to get back to me with
>> the answer. It's been a year :(
>>
>>> (and I did try again a few timews)
>>>>
>>>>
>>> Looks like IRAM is an O-member.
>>>
>>> http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee_participation.htm?commid=45202
>>>
>>> Oh.. thanks :) Time to retrained my web searching techniques.
>>
>> I happen to found on the isocpp pages that I can pay U$S 1200 a year to
>> join as a member of the US NB. I'll think I'll fire up GNU Cash and run
>> some numbers, this could be a very good idea.
>>
>>
>>
> For Argentinian bodies, you should probably contact INTI first, they seem
> to deal with software. IRAM
> might not grok it. See http://www.inti.gob.ar/nanotecnologia/contacto.htm,
> apparently Hector Laiz
> is the INTI person in IRAM. That guy might even have a slightest clue
> about what programming languages
> are. ;)
>
> :) thank you!! I'll sure do that!
>
>
--
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.
--001a11c2a9b88110f404dbc3e893
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 7:36 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 3 May 2013 01:3=
1, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacci=
ola@gmail.com" target=3D"_blank">fernando.cacciola@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"gmail_extra"><div class=3D"gmail_quote"><div><div>Me neither. As far =
as I could trace on the ISO pages, I should consult IRAM. That's what I=
did, and I'm waiting for them to get back to me with the answer. It=
9;s been a year :(<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>(and I did try again a few timews)<br><br></div></div></div></div></blockq=
uote><div><br></div></div><div>Looks like IRAM is an O-member. <br><a href=
=3D"http://www.iso.org/iso/home/standards_development/list_of_iso_technical=
_committees/iso_technical_committee_participation.htm?commid=3D45202" targe=
t=3D"_blank">http://www.iso.org/iso/home/standards_development/list_of_iso_=
technical_committees/iso_technical_committee_participation.htm?commid=3D452=
02</a> <br>
</div></div><br></div></div></blockquote></div></div><div>Oh.. thanks :) Ti=
me to retrained my web searching techniques.<br><br></div><div>I happen to =
found on the isocpp pages that I can pay U$S 1200 a year to join as a membe=
r of the US NB. I'll think I'll fire up GNU Cash and run some numbe=
rs, this could be a very good idea.<br>
</div><div><br><br></div></div></div></div></blockquote><div><br></div></di=
v><div>For Argentinian bodies, you should probably contact INTI first, they=
seem to deal with software. IRAM<br>might not grok it. See <a href=3D"http=
://www.inti.gob.ar/nanotecnologia/contacto.htm" target=3D"_blank">http://ww=
w.inti.gob.ar/nanotecnologia/contacto.htm</a>, apparently Hector Laiz<br>
is the INTI person in IRAM. That guy might even have a slightest clue about=
what programming languages<br>are. ;) <br></div></div><br></div></div></bl=
ockquote><div>:) thank you!! I'll sure do that!<br>=A0<br></div><blockq=
uote 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></div><div class=3D"HOEnZ=
b"><div class=3D"h5">
<p></p><br></div></div></blockquote></div><br>-- <br>Fernando Cacciola<br>S=
ciSoft 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 />
--001a11c2a9b88110f404dbc3e893--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 01:48:05 +0300
Raw View
--089e0115ef6012a9c504dbc407d3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 3 May 2013 01:38, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> For Argentinian bodies, you should probably contact INTI first, they seem
> to deal with software. IRAM
>
>> might not grok it. See http://www.inti.gob.ar/nanotecnologia/contacto.ht=
m,
>> apparently Hector Laiz
>> is the INTI person in IRAM. That guy might even have a slightest clue
>> about what programming languages
>> are. ;)
>>
>> :) thank you!! I'll sure do that!
>
>
I should probably explain how I conjured that up. :) Usually, NBs are full
of people who deal with nuts
and bolts. Literally. :) So, you need to find something software-related.
IRAM web pages seemed to
indicate that INTI deals with technology industry, and _their_ web pages
mention software, specifically.
Hector Laiz of INTI was mentioned to be in some sort of a tech industry rep
role in IRAM. This may of course be
way off base, because yo no comprendo Espa=F1ol. :D Perhaps Daniel could tr=
y
and dig up some
IRAM SC22 people via his AENOR connections...
--=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.
--089e0115ef6012a9c504dbc407d3
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 01:38, 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">For Argentinian bodies, y=
ou should probably contact INTI first, they seem to deal with software. IRA=
M<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>might not grok it. See <a href=3D"http://ww=
w.inti.gob.ar/nanotecnologia/contacto.htm" target=3D"_blank">http://www.int=
i.gob.ar/nanotecnologia/contacto.htm</a>, apparently Hector Laiz<br>
is the INTI person in IRAM. That guy might even have a slightest clue about=
what programming languages<br>are. ;) <br></div></div><br></div></div></bl=
ockquote></div></div><div>:) thank you!! I'll sure do that!<br><br>
</div></div></div></div></blockquote><div><br></div><div>I should probably =
explain how I conjured that up. :) Usually, NBs are full of people who deal=
with nuts<br>and bolts. Literally. :) So, you need to find something softw=
are-related. IRAM web pages seemed to<br>
indicate that INTI deals with technology industry, and _their_ web pages me=
ntion software, specifically.<br></div><div>Hector Laiz of INTI was mention=
ed to be in some sort of a tech industry rep role in IRAM. This may of cour=
se be<br>
</div><div>way off base, because yo no comprendo Espa=F1ol. :D Perhaps Dani=
el could try and dig up some<br></div><div>IRAM SC22 people via his AENOR c=
onnections... <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 />
--089e0115ef6012a9c504dbc407d3--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Thu, 2 May 2013 18:04:11 -0500
Raw View
--bcaec518677815dacf04dbc44331
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Thanks Ville. I have provided some additional info directly to Fernando. I
hope this may eventually result in having another national body on board :-=
)
On Thu, May 2, 2013 at 5:48 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 3 May 2013 01:38, Fernando Cacciola <fernando.cacciola@gmail.com>wrote=
:
>
>> For Argentinian bodies, you should probably contact INTI first, they see=
m
>> to deal with software. IRAM
>>
>>> might not grok it. See
>>> http://www.inti.gob.ar/nanotecnologia/contacto.htm, apparently Hector
>>> Laiz
>>> is the INTI person in IRAM. That guy might even have a slightest clue
>>> about what programming languages
>>> are. ;)
>>>
>>> :) thank you!! I'll sure do that!
>>
>>
> I should probably explain how I conjured that up. :) Usually, NBs are ful=
l
> of people who deal with nuts
> and bolts. Literally. :) So, you need to find something software-related.
> IRAM web pages seemed to
> indicate that INTI deals with technology industry, and _their_ web pages
> mention software, specifically.
> Hector Laiz of INTI was mentioned to be in some sort of a tech industry
> rep role in IRAM. This may of course be
> way off base, because yo no comprendo Espa=F1ol. :D Perhaps Daniel could =
try
> and dig up some
> IRAM SC22 people via his AENOR connections...
>
> --
>
> ---
> 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=3Den.
>
>
>
--=20
Prof. J. Daniel Garcia
Associate Professor - Profesor Titular de Universidad
Computer Architecture Group
University Carlos III of Madrid
Avda. Universidad Carlos III, 22
28270 Colmenarejo, Madrid. Spain
Tel: +34 918561316
Fax: +34 91 856 1270
e-mail: josedaniel.garcia@uc3m.es
Web: http://www.arcos.inf.uc3m.es/~jdaniel
Linked-In: http://es.linkedin.com/in/jdanielgarcia
Twitter: http://www.twitter.com/jdgarciauc3m
--=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.
--bcaec518677815dacf04dbc44331
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks Ville. I have provided some additional info directl=
y to Fernando. I hope this may eventually result in having another national=
body on board :-)</div><div class=3D"gmail_extra"><br><br><div class=3D"gm=
ail_quote">
On Thu, May 2, 2013 at 5:48 PM, Ville Voutilainen <span dir=3D"ltr"><<a =
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutila=
inen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 3 May 2013 01:38, Fernando Cacciola <span dir=
=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blan=
k">fernando.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><div>For Argentinian bodies, you should pro=
bably contact INTI first, they seem to deal with software. IRAM<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>might not grok it. See <a href=3D"http://ww=
w.inti.gob.ar/nanotecnologia/contacto.htm" target=3D"_blank">http://www.int=
i.gob.ar/nanotecnologia/contacto.htm</a>, apparently Hector Laiz<br>
is the INTI person in IRAM. That guy might even have a slightest clue about=
what programming languages<br>are. ;) <br></div></div><br></div></div></bl=
ockquote></div></div><div>:) thank you!! I'll sure do that!<br><br>
</div></div></div></div></blockquote><div><br></div></div><div>I should pro=
bably explain how I conjured that up. :) Usually, NBs are full of people wh=
o deal with nuts<br>and bolts. Literally. :) So, you need to find something=
software-related. IRAM web pages seemed to<br>
indicate that INTI deals with technology industry, and _their_ web pages me=
ntion software, specifically.<br></div><div>Hector Laiz of INTI was mention=
ed to be in some sort of a tech industry rep role in IRAM. This may of cour=
se be<br>
</div><div>way off base, because yo no comprendo Espa=F1ol. :D Perhaps Dani=
el could try and dig up some<br></div><div>IRAM SC22 people via his AENOR c=
onnections... <br></div></div><br></div></div><div class=3D"HOEnZb"><div cl=
ass=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>=
Prof. J. Daniel Garcia<br>Associate Professor - Profesor Titular de Univers=
idad<br>Computer Architecture Group<br>University Carlos III of Madrid<br>
Avda. Universidad Carlos III, 22<br>28270 Colmenarejo, Madrid. Spain<br>Tel=
: +34 918561316<br>Fax: +34 91 856 1270<br>e-mail: <a href=3D"mailto:joseda=
niel.garcia@uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.es</a><br>Web=
: <a href=3D"http://www.arcos.inf.uc3m.es/~jdaniel" target=3D"_blank">http:=
//www.arcos.inf.uc3m.es/~jdaniel</a><br>
=A0<br>Linked-In: <a href=3D"http://es.linkedin.com/in/jdanielgarcia" targe=
t=3D"_blank">http://es.linkedin.com/in/jdanielgarcia</a><br>Twitter:=A0<a h=
ref=3D"http://www.twitter.com/jdgarciauc3m" target=3D"_blank">http://www.tw=
itter.com/jdgarciauc3m</a>
</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 />
--bcaec518677815dacf04dbc44331--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 23:15:40 -0300
Raw View
--001a11c2a884d4ea5f04dbc6ef8a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, May 2, 2013 at 7:48 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 3 May 2013 01:38, Fernando Cacciola <fernando.cacciola@gmail.com>wrote=
:
>
>> For Argentinian bodies, you should probably contact INTI first, they see=
m
>> to deal with software. IRAM
>>
>>> might not grok it. See
>>> http://www.inti.gob.ar/nanotecnologia/contacto.htm, apparently Hector
>>> Laiz
>>> is the INTI person in IRAM. That guy might even have a slightest clue
>>> about what programming languages
>>> are. ;)
>>>
>>> :) thank you!! I'll sure do that!
>>
>>
> I should probably explain how I conjured that up. :) Usually, NBs are ful=
l
> of people who deal with nuts
> and bolts. Literally. :) So, you need to find something software-related.
> IRAM web pages seemed to
> indicate that INTI deals with technology industry, and _their_ web pages
> mention software, specifically.
> Hector Laiz of INTI was mentioned to be in some sort of a tech industry
> rep role in IRAM. This may of course be
> way off base, because yo no comprendo Espa=F1ol. :D Perhaps Daniel could =
try
> and dig up some
> IRAM SC22 people via his AENOR connections...
>
Ah... this makes a lot of sense yet I wouldn't have figured it out myself
alone, so thank you again!
--=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.
--001a11c2a884d4ea5f04dbc6ef8a
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 7:48 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 3 May 2013 01:3=
8, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacci=
ola@gmail.com" target=3D"_blank">fernando.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><div>For Argentinian bodies, you should pro=
bably contact INTI first, they seem to deal with software. IRAM<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>might not grok it. See <a href=3D"http://ww=
w.inti.gob.ar/nanotecnologia/contacto.htm" target=3D"_blank">http://www.int=
i.gob.ar/nanotecnologia/contacto.htm</a>, apparently Hector Laiz<br>
is the INTI person in IRAM. That guy might even have a slightest clue about=
what programming languages<br>are. ;) <br></div></div><br></div></div></bl=
ockquote></div></div><div>:) thank you!! I'll sure do that!<br><br>
</div></div></div></div></blockquote><div><br></div></div><div>I should pro=
bably explain how I conjured that up. :) Usually, NBs are full of people wh=
o deal with nuts<br>and bolts. Literally. :) So, you need to find something=
software-related. IRAM web pages seemed to<br>
indicate that INTI deals with technology industry, and _their_ web pages me=
ntion software, specifically.<br></div><div>Hector Laiz of INTI was mention=
ed to be in some sort of a tech industry rep role in IRAM. This may of cour=
se be<br>
</div><div>way off base, because yo no comprendo Espa=F1ol. :D Perhaps Dani=
el could try and dig up some<br></div><div>IRAM SC22 people via his AENOR c=
onnections... <br></div></div></div></div></blockquote><div><br></div><div>
Ah... this makes a lot of sense yet I wouldn't have figured it out myse=
lf alone, so thank you again!<br>=A0<br clear=3D"all"></div></div>-- <br>Fe=
rnando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.sci=
soft-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 />
--001a11c2a884d4ea5f04dbc6ef8a--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 2 May 2013 23:21:05 -0300
Raw View
--001a11c2a9b83a4e4204dbc70334
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 8:04 PM, J. Daniel Garcia
<josedaniel.garcia@uc3m.es>wrote:
> Thanks Ville. I have provided some additional info directly to Fernando. I
> hope this may eventually result in having another national body on board :-)
>
> Thanks to the info you both gave me, I'm working on it amd I'm optimistic
this time.
--
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.
--001a11c2a9b83a4e4204dbc70334
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 8:04 PM, J. Daniel Garcia <span dir=3D"ltr"><<a href=
=3D"mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garcia@u=
c3m.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">Thanks Ville. I have provid=
ed some additional info directly to Fernando. I hope this may eventually re=
sult in having another national body on board :-)</div>
<div class=3D"gmail_extra"><div><div class=3D"h5"><br></div></div></div></b=
lockquote><div>Thanks to the info you both gave me, I'm working on it a=
md I'm optimistic this time.<br><br></div></div><br>-- <br>Fernando Cac=
ciola<br>
SciSoft 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 />
--001a11c2a9b83a4e4204dbc70334--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 3 May 2013 09:27:13 -0500
Raw View
--047d7bb050824982d904dbd12847
Content-Type: text/plain; charset=ISO-8859-1
On 2 May 2013 16:19, Nevin Liber <nevin@eviloverlord.com> wrote:
> operator< should be implemented in terms of operator< of the underlying
> component(s)
> operator== should be implemented in terms of operator== of the underlying
> component(s)
> std::less should be implemented in terms of std::less of the underlying
> component(s)
> std::equal_to should be implemented in terms of std::equal_to of the
> underlying component(s)
>
> operator>, operator<=, operator>= should be written in terms of operator<
> operator!= should be written in terms of operator==
> std::greater, std::less_equal, std::greater_equal should be written in
> terms of std::less
> std::not_equal_to should be written in terms of std::equal_to
>
The other, simpler possibility is to not specialize the arithmetic
operations:
operator< should be implemented in terms of std::less of the underlying
component(s)
operator== should be implemented in terms of std::equal_to of the
underlying component(s)
operator>, operator<=, operator>= should be written in terms of operator<
operator!= should be written in terms of operator==
This may have surprising results for those who, for instance, think
operator< and std::less should do different things (the only place in the
standard which does this as far as I know is for pointers, and that is only
because C doesn't give them a total ordering), but I see that being as
insane as NaN.
Thoughts?
--
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.
--047d7bb050824982d904dbd12847
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 2 May 2013 16:19, Nevin Liber <span dir=3D"ltr"><<a href=3D"mailto:ne=
vin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>></spa=
n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
operator< should be implemented in terms of operator< of the underlyi=
ng component(s)<br><div class=3D"gmail_quote"><div>operator=3D=3D should be=
implemented in terms of operator=3D=3D of the underlying component(s)<br>s=
td::less should be implemented in terms of std::less of the underlying comp=
onent(s)<br>
std::equal_to should be implemented in terms of std::equal_to of the underl=
ying component(s)<br><br>operator>, operator<=3D, operator>=3D sho=
uld be written in terms of operator<<br>operator!=3D should be written i=
n terms of operator=3D=3D<br>
std::greater, std::less_equal, std::greater_equal should be written in term=
s of std::less<br>std::not_equal_to should be written in terms of std::equa=
l_to<span></span></div></div></blockquote><div><br>The other, simpler possi=
bility is to not specialize the arithmetic operations:<br>
<br>operator< should be implemented in terms of std::less of the underly=
ing component(s)<br>operator=3D=3D should be implemented in terms of std::e=
qual_to of the underlying component(s)<br><br>operator>, operator<=3D=
, operator>=3D should be written in terms of operator<<br>
operator!=3D should be written in terms of operator=3D=3D<br><br>This may h=
ave surprising results for those who, for instance, think operator< and =
std::less should do different things (the only place in the standard which =
does this as far as I know is for pointers, and that is only because C does=
n't give them a total ordering), but I see that being as insane as NaN.=
<br>
<br>Thoughts?<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=
=3D"_blank">(847) 691-1404</a>
<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 />
--047d7bb050824982d904dbd12847--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 17:43:58 +0300
Raw View
--047d7b2e41a499ac3604dbd16174
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 17:27, Nevin Liber <nevin@eviloverlord.com> wrote:
> The other, simpler possibility is to not specialize the arithmetic
> operations:
>
> operator< should be implemented in terms of std::less of the underlying
> component(s)
> operator== should be implemented in terms of std::equal_to of the
> underlying component(s)
>
I think Tony has a valid point about the first one - it will give a wrapper
of a complex an operator<,
and potentially for other types of the kind where operator< isn't
desirable, but an std::less specialization
is. I fail to see what equal_to brings into this, but that's just because I
fail to imagine when is it
ever not the same as operator==.
> This may have surprising results for those who, for instance, think
> operator< and std::less should do different things (the only place in the
> standard which does this as far as I know is for pointers, and that is only
> because C doesn't give them a total ordering), but I see that being as
> insane as NaN.
>
>
>
Agreed, the pointer situation is unfortunate, but it seems likely that
other types will have this difference
between op< and less.
--
---
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.
--047d7b2e41a499ac3604dbd16174
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 17:27, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The other, simpler possibility is to not spe=
cialize the arithmetic operations:<br><div class=3D"gmail_quote"><div>
<br>operator< should be implemented in terms of std::less of the underly=
ing component(s)<br>operator=3D=3D should be implemented in terms of std::e=
qual_to of the underlying component(s)</div></div></blockquote><div><br></d=
iv>
<div>I think Tony has a valid point about the first one - it will give a wr=
apper of a complex an operator<,<br></div><div>and potentially for other=
types of the kind where operator< isn't desirable, but an std::less=
specialization<br>
is. I fail to see what equal_to brings into this, but that's just becau=
se I fail to imagine when is it<br>ever not the same as operator=3D=3D. <br=
>=A0<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>This may have surprising results for those =
who, for instance, think operator< and std::less should do different thi=
ngs (the only place in the standard which does this as far as I know is for=
pointers, and that is only because C doesn't give them a total orderin=
g), but I see that being as insane as NaN.<br>
<br><br></div></div></blockquote><div><br></div><div>Agreed, the pointer si=
tuation is unfortunate, but it seems likely that other types will have this=
difference<br>between op< and less. <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 />
--047d7b2e41a499ac3604dbd16174--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 17:56:26 +0300
Raw View
--001a11c329322a20f204dbd18efa
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 17:43, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> This may have surprising results for those who, for instance, think
> operator< and std::less should do different things (the only place in the
> standard which does this as far as I know is for pointers, and that is only
> because C doesn't give them a total ordering), but I see that being as
> insane as NaN.
>
>>
>>
>>
> Agreed, the pointer situation is unfortunate, but it seems likely that
> other types will have this difference
> between op< and less.
>
>
A further 0.02: I find it unfortunate that the operator-functors are ever
anything but alternative ways
to perform their underlying operators. It's pragmatically important that
putting types into sets and maps
is easy, but making less and op< different is, from a pedantic standpoint,
a gross hack. It would be
much cleaner to not use std::less by default in maps and sets, but use some
AssocComp that invokes
std::less by default, and allow specialization of that AssocComp for funny
types. I'm not sure whether
that cleaner solution is attainable, that particular cat may well be so far
out of the bag that wooing
it back isn't practical.
--
---
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.
--001a11c329322a20f204dbd18efa
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 17:43, 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">This may have surprising re=
sults for those who, for instance, think operator< and std::less should =
do different things (the only place in the standard which does this as far =
as I know is for pointers, and that is only because C doesn't give them=
a total ordering), but I see that being as insane as NaN.<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><bl=
ockquote 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><br></div></div></blockquote><div><br></div></div><div>Agreed, the poin=
ter situation is unfortunate, but it seems likely that other types will hav=
e this difference<br>between op< and less. <br></div></div><br></div>
</div>
</blockquote></div><br></div><div class=3D"gmail_extra">A further 0.02: I f=
ind it unfortunate that the operator-functors are ever anything but alterna=
tive ways<br></div><div class=3D"gmail_extra">to perform their underlying o=
perators. It's pragmatically important that putting types into sets and=
maps<br>
is easy, but making less and op< different is, from a pedantic standpoin=
t, a gross hack. It would be<br>much cleaner to not use std::less by defaul=
t in maps and sets, but use some AssocComp that invokes<br>std::less by def=
ault, and allow specialization of that AssocComp for funny types. I'm n=
ot sure whether<br>
</div><div class=3D"gmail_extra">that cleaner solution is attainable, that =
particular cat may well be so far out of the bag that wooing<br></div><div =
class=3D"gmail_extra">it back isn't practical.<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 />
--001a11c329322a20f204dbd18efa--
.
Author: Marc <marc.glisse@gmail.com>
Date: Fri, 3 May 2013 10:55:48 -0700 (PDT)
Raw View
------=_Part_59_1628107.1367603748798
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le jeudi 2 mai 2013 23:29:55 UTC+2, Fernando Cacciola a =E9crit :
>
> On Thu, May 2, 2013 at 6:24 PM, Fernando Cacciola <fernando...@gmail.com<=
javascript:>
> > wrote:
>
>> On Thu, May 2, 2013 at 6:19 PM, Nevin Liber <ne...@eviloverlord.com<java=
script:>
>> > wrote:
>>
>>> If we are going for consistency and correctness among everything in the=
=20
>>> standard library, is this correct solution:
>>>
>>> operator< should be implemented in terms of operator< of the underlying=
=20
>>> component(s)
>>> operator=3D=3D should be implemented in terms of operator=3D=3D of the=
=20
>>> underlying component(s)
>>> std::less should be implemented in terms of std::less of the underlying=
=20
>>> component(s)
>>> std::equal_to should be implemented in terms of std::equal_to of the=20
>>> underlying component(s)
>>>
>>> operator>, operator<=3D, operator>=3D should be written in terms of ope=
rator<
>>> operator!=3D should be written in terms of operator=3D=3D
>>> std::greater, std::less_equal, std::greater_equal should be written in=
=20
>>> terms of std::less
>>> std::not_equal_to should be written in terms of std::equal_to
>>>
>>>
>> Actually, if we are going to fix the *entire* library, then we *could*=
=20
>> chose to have all operators boild down to the underlying component(s)
>>
>> IIRC, the main reason for not doing so is consistency across the SCL.
>>
>> But let me clarify, I'm NOT saying we should do that (in fact, I like=20
> your proposal here a lot), only that we might not have a good reason to=
=20
> make everything based on < and =3D=3D if we are completely consistent.
>
> IIRC, the issue with defining > in terms of < is that it messes up with=
=20
> non-totally ordered types.=20
> OTOH, if you do have such a type (why would you, but that's not up to me)=
,=20
> I guess it would be reasonable to require you to specialize wrappers and=
=20
> containers accordingly (which is always possible in any case)
>
But why should I, as someone using a non total order, have to specialize=20
anything? If the underlying type has operator>, then optional should use it=
=20
for >. If it doesn't, then optional shouldn't either. If you are using=20
rel_ops with T, you can just as well use rel_ops with optional<T>.
--=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_59_1628107.1367603748798
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le jeudi 2 mai 2013 23:29:55 UTC+2, Fernando Cacciola a =E9crit :<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">On Thu, May 2, 2013 at 6:24 PM, Fernando Cacciola <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"7xt0KyXE_vsJ">fernando...@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><div class=3D"gmail_qu=
ote"><div>On Thu, May 2, 2013 at 6:19 PM, Nevin Liber <span dir=3D"ltr"><=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"7xt0KyX=
E_vsJ">ne...@eviloverlord.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"gmail_quote"><div>If we are go=
ing for consistency and correctness among everything in the standard librar=
y, is this correct solution:<br>
<br>operator< should be implemented in terms of operator< of the unde=
rlying component(s)<br>operator=3D=3D should be implemented in terms of ope=
rator=3D=3D of the underlying component(s)<br>std::less should be implement=
ed in terms of std::less of the underlying component(s)<br>
std::equal_to should be implemented in terms of std::equal_to of the underl=
ying component(s)<br><br>operator>, operator<=3D, operator>=3D sho=
uld be written in terms of operator<<br>operator!=3D should be written i=
n terms of operator=3D=3D<br>
std::greater, std::less_equal, std::greater_equal should be written in term=
s of std::less<br>std::not_equal_to should be written in terms of std::equa=
l_to<span><font color=3D"#888888"><br></font></span></div>
</div><br></blockquote><div><br></div></div><div>Actually, if we are going =
to fix the *entire* library, then we *could* chose to have all operators bo=
ild down to the underlying component(s)<br><br></div><div>IIRC, the main re=
ason for not doing so is consistency across the SCL.<span><font color=3D"#8=
88888"><br>
<br></font></span></div></div></div></div></blockquote><div>But let me clar=
ify, I'm NOT saying we should do that (in fact, I like your proposal here a=
lot), only that we might not have a good reason to make everything based o=
n < and =3D=3D if we are completely consistent.<br>
<br></div><div>IIRC, the issue with defining > in terms of < is that =
it messes up with non-totally ordered types. <br></div><div>OTOH, if you do=
have such a type (why would you, but that's not up to me), I guess it woul=
d be reasonable to require you to specialize wrappers and containers accord=
ingly (which is always possible in any case)</div></div></div></div></block=
quote><div><br>But why should I, as someone using a non total order, have t=
o specialize anything? If the underlying type has operator>, then option=
al should use it for >. If it doesn't, then optional shouldn't either. I=
f you are using rel_ops with T, you can just as well use rel_ops with=
optional<T>.<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_59_1628107.1367603748798--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 21:12:40 +0300
Raw View
--089e013a1978f63bf204dbd44b62
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 20:55, Marc <marc.glisse@gmail.com> wrote:
>
> But why should I, as someone using a non total order, have to specialize
> anything? If the underlying type has operator>, then optional should use it
> for >. If it doesn't, then optional shouldn't either. If you are using
> rel_ops with T, you can just as well use rel_ops with optional<T>.
>
>
>
>
Currently tuple, pair and containers don't do that. It would be reasonable
to be consistent in that regard
with optional, and consider further changes separately afterwards.
--
---
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.
--089e013a1978f63bf204dbd44b62
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 20:55, Marc <span dir=3D"ltr"><<a href=3D"mailto:m=
arc.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"><br><div>But why should I, as someone using =
a non total order, have to specialize anything? If the underlying type has =
operator>, then optional should use it for >. If it doesn't, then=
optional shouldn't either. If=A0 you are using rel_ops with T, you can=
just as well use rel_ops with optional<T>.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Currently tuple, pair =
and containers don't do that. It would be reasonable to be consistent i=
n that regard<br>with optional, and consider further changes separately aft=
erwards.<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 />
--089e013a1978f63bf204dbd44b62--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Fri, 3 May 2013 12:27:14 -0700 (PDT)
Raw View
------=_Part_132_4089484.1367609234487
Content-Type: text/plain; charset=ISO-8859-1
As was raised repeatedly in Bristol, none of those types are types that try
to be as close to the original type as possible, unlike optional.
Personally, I think that optional<T> is more like a T than a tuple<T>.
--
---
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_132_4089484.1367609234487
Content-Type: text/html; charset=ISO-8859-1
As was raised repeatedly in Bristol, none of those types are types that try to be as close to the original type as possible, unlike optional. Personally, I think that optional<T> is more like a T than a tuple<T>.
<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 />
------=_Part_132_4089484.1367609234487--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 22:34:36 +0300
Raw View
--089e013a1978f6608e04dbd5707a
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 22:27, DeadMG <wolfeinstein@gmail.com> wrote:
> As was raised repeatedly in Bristol, none of those types are types that
> try to be as close to the original type as possible, unlike optional.
> Personally, I think that optional<T> is more like a T than a tuple<T>.
>
>
>
>
Perhaps so. So what? What's your point?
--
---
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.
--089e013a1978f6608e04dbd5707a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 3 May 2013 22:27, 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">As was raised repeatedly in Bristol, none of=
those types are types that try to be as close to the original type as poss=
ible, unlike optional. Personally, I think that optional<T> is more l=
ike a T than a tuple<T>.
<div class=3D"HOEnZb"><div class=3D"h5"><p></p>
<br><br></div></div></blockquote><div><br></div><div>Perhaps so. So what? W=
hat's your point? <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 />
--089e013a1978f6608e04dbd5707a--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Fri, 3 May 2013 12:35:37 -0700 (PDT)
Raw View
------=_Part_40_33490151.1367609737376
Content-Type: text/plain; charset=ISO-8859-1
Your argument is consistency with tuple<T>. My argument is consistency with
T. So what's *your* point?
--
---
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_40_33490151.1367609737376
Content-Type: text/html; charset=ISO-8859-1
Your argument is consistency with tuple<T>. My argument is consistency with T. So what's <i>your</i> point?
<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 />
------=_Part_40_33490151.1367609737376--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 3 May 2013 15:45:38 -0400
Raw View
--001a11c34a3a79194504dbd59811
Content-Type: text/plain; charset=ISO-8859-1
On Fri, May 3, 2013 at 2:12 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 3 May 2013 20:55, Marc <marc.glisse@gmail.com> wrote:
>
>>
>> But why should I, as someone using a non total order, have to specialize
>> anything? If the underlying type has operator>, then optional should use it
>> for >. If it doesn't, then optional shouldn't either. If you are using
>> rel_ops with T, you can just as well use rel_ops with optional<T>.
>>
>>
>>
> Currently tuple, pair and containers don't do that. It would be reasonable
> to be consistent in that regard
> with optional, and consider further changes separately afterwards.
>
>
>
>
You know that we will never change tuple, unless we can somehow come up
with a backwards compatible change (ie generate > only if not defined by
underlying type - that would at least break *less* people).
I don't understand the importance of consistency with tuple.
You currently cannot do
tuple<int>() < int()
You *can* do
optional<int>() < int()
Mixed relops are part of "optional acts like T with one more value".
If you must pick "consistency" then consistency with T is more important
than consistency with tuple. There really isn't much analogy between tuple
and optional. Yes they are both templated structs. The End.
I find tuple<> more like a cheap struct, like the classic EmployeeRecord
struct. And it doesn't bother me that EmployeeRecord isn't sorted exactly
like its members, so I can live with tuple<> not sorting like its members.
(still bothers me, but I can live with it)
When will *any* code get a surprising result because optional works
differently than tuple?
There *will* be code that is surprised that optional ordered T differently
than T did. Not much code, but some.
The opening paragraphs of the optional proposal described a number of
mental models for optinoal<> and chose "T with one more value". If that is
the model, then acting like T is more important than acting like tuple.
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.
--001a11c34a3a79194504dbd59811
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 2:12 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"><br><div=
class=3D"h5"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 3 May=
2013 20:55, 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:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br><div>But why should I=
, as someone using a non total order, have to specialize anything? If the u=
nderlying type has operator>, then optional should use it for >. If i=
t doesn't, then optional shouldn't either. If=A0 you are using rel_=
ops with T, you can just as well use rel_ops with optional<T>.<br>
</div><div><div>
<br><br></div></div></blockquote><div><br></div></div><div>Currently tuple,=
pair and containers don't do that. It would be reasonable to be consis=
tent in that regard<br>with optional, and consider further changes separate=
ly afterwards.<br>
</div></div><br>
<br><br></div></div></blockquote><div><br></div><div>You know that we will =
never change tuple, unless we can somehow come up with a backwards compatib=
le change (ie generate > only if not defined by underlying type - that w=
ould at least break *less* people).<br>
<br><br></div><div>I don't understand the importance of consistency wit=
h tuple.<br><br>You currently cannot do<br><br></div><div>tuple<int>(=
)=A0 <=A0 int()<br><br><br></div><div>You *can* do<br><br></div><div>opt=
ional<int>()=A0=A0 <=A0 int()<br>
<br><br></div><div>Mixed relops are part of "optional acts like T with=
one more value".<br><br></div><div>If you must pick "consistency=
" then consistency with T is more important than consistency with tupl=
e.=A0 There really isn't much analogy between tuple and optional.=A0 Ye=
s they are both templated structs.=A0 The End.<br>
<br>I=20
find tuple<> more like a cheap struct, like the classic=20
EmployeeRecord struct.=A0 And it doesn't bother me that EmployeeRecord=
=20
isn't sorted exactly like its members, so I can live with tuple<>=
=20
not sorting like its members.=A0 (still bothers me, but I can live with=20
it)<br><br><br>When will *any* code get a surprising result because optiona=
l works differently than tuple?<br></div><div>There *will* be code that is =
surprised that optional ordered T differently than T did.=A0 Not much code,=
but some.<br>
<br><br></div><div>The opening paragraphs of the optional proposal describe=
d a number of mental models for optinoal<> and chose "T with one=
more value".=A0 If that is the model, then acting like T is more impo=
rtant than acting like tuple.<br>
<br></div><div>Tony<br><br></div><div>=A0<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 />
--001a11c34a3a79194504dbd59811--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 22:57:59 +0300
Raw View
--001a11c24b7c9d378404dbd5c4cc
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 22:35, DeadMG <wolfeinstein@gmail.com> wrote:
> Your argument is consistency with tuple<T>. My argument is consistency
> with T. So what's *your* point?
>
>
>
>
The current optional has neither. And I've yet to hear an explanation why
it shouldn't be consistent with
tuple. Whether tuple as it currently is needs some fixes, I have proposed a
dozen times already that
those problems would be the next step.
--
---
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.
--001a11c24b7c9d378404dbd5c4cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 3 May 2013 22:35, 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">Your argument is consistency with tuple<T=
>. My argument is consistency with T. So what's <i>your</i>=A0point?
<div class=3D"HOEnZb"><div class=3D"h5"><p></p>
<br><br></div></div></blockquote><div><br></div><div>The current optional h=
as neither. And I've yet to hear an explanation why it shouldn't be=
consistent with<br></div><div>tuple. Whether tuple as it currently is need=
s some fixes, I have proposed a dozen times already that<br>
</div><div>those problems would be the next step. <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 />
--001a11c24b7c9d378404dbd5c4cc--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 23:04:55 +0300
Raw View
--047d7b2e41a468fa2404dbd5dde5
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 22:45, Tony V E <tvaneerd@gmail.com> wrote:
> You know that we will never change tuple, unless we can somehow come up
> with a backwards compatible change (ie generate > only if not defined by
> underlying type - that would at least break *less* people).
>
I don't have any idea how you come to the conclusion that I "know" that. I
don't think that's the case at
all, because currently a tuple<T*> doesn't even work as a key for an
associative container, so that's
something that needs to be looked at.
Whether generating an op> is an issue is a completely different discussion,
and then we need to answer
the question whether the library needs to support types that would break if
op> is generated via op<.
My answer to that question is no.
> I don't understand the importance of consistency with tuple.
>
I don't understand why optional should act differently from a tuple,
especially for cases when the
optional is engaged.
>
> You currently cannot do
>
> tuple<int>() < int()
>
There are already suggestions to make tuple's constructor from the
underlying type implicit.
Then you can do that.
>
> If you must pick "consistency" then consistency with T is more important
> than consistency with tuple. There really isn't much analogy between tuple
> and optional. Yes they are both templated structs. The End.
>
Neither tuple<T> nor optional<T> is a T. optional<T> may currently act more
like a T, but it does that for comparisons
only, and that's for convenience.
>
> I find tuple<> more like a cheap struct, like the classic EmployeeRecord
> struct. And it doesn't bother me that EmployeeRecord isn't sorted exactly
> like its members, so I can live with tuple<> not sorting like its members.
> (still bothers me, but I can live with it)
>
I find optional like a cheap discriminated union, which is what it is.
>
>
> When will *any* code get a surprising result because optional works
> differently than tuple?
>
Whenever you treat these library wrappers, especially for cases when the
optional is engaged, in a generic
manner.
> There *will* be code that is surprised that optional ordered T differently
> than T did. Not much code, but some.
>
I would love to see an example of such code, then.
>
>
> The opening paragraphs of the optional proposal described a number of
> mental models for optinoal<> and chose "T with one more value". If that is
> the model, then acting like T is more important than acting like tuple.
>
It chose "A discriminated union of types nullopt_t and T."
--
---
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.
--047d7b2e41a468fa2404dbd5dde5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 3 May 2013 22:45, 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:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">You know=
that we will never change tuple, unless we can somehow come up with a back=
wards compatible change (ie generate > only if not defined by underlying=
type - that would at least break *less* people).<br>
</div></blockquote><div><br></div><div>I don't have any idea how you co=
me to the conclusion that I "know" that. I don't think that&#=
39;s the case at<br>all, because currently a tuple<T*> doesn't ev=
en work as a key for an associative container, so that's<br>
something that needs to be looked at.<br><br></div><div>Whether generating =
an op> is an issue is a completely different discussion, and then we nee=
d to answer<br>the question whether the library needs to support types that=
would break if op> is generated via op<.<br>
</div><div>My answer to that question is no.<br>=A0<br></div><blockquote cl=
ass=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 class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">
<div>I don't understand the importance of consistency with tuple.<br></=
div></div></div></div></blockquote><div><br></div><div>I don't understa=
nd why optional should act differently from a tuple, especially for cases w=
hen the<br>
</div><div>optional is engaged.<br>=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">
<div><br>You currently cannot do<br><br></div><div>tuple<int>()=A0 &l=
t;=A0 int()<br></div></div></div></div></blockquote><div><br></div><div>The=
re are already suggestions to make tuple's constructor from the underly=
ing type implicit.<br>
</div><div>Then you can do that.<br>=A0<br></div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote">
<div><br></div><div>If you must pick "consistency" then consisten=
cy with T is more important than consistency with tuple.=A0 There really is=
n't much analogy between tuple and optional.=A0 Yes they are both templ=
ated structs.=A0 The End.<br>
</div></div></div></div></blockquote><div><br></div><div>Neither tuple<T=
> nor optional<T> is a T. optional<T> may currently act more=
like a T, but it does that for comparisons<br>only, and that's for con=
venience.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>
<br>I=20
find tuple<> more like a cheap struct, like the classic=20
EmployeeRecord struct.=A0 And it doesn't bother me that EmployeeRecord=
=20
isn't sorted exactly like its members, so I can live with tuple<>=
=20
not sorting like its members.=A0 (still bothers me, but I can live with=20
it)<br></div></div></div></div></blockquote><div><br></div><div>I find opti=
onal like a cheap discriminated union, which is what it is. <br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br><br>When will *any* code get a surprising result because optional work=
s differently than tuple?<br></div></div></div></div></blockquote><div><br>=
</div>
<div>Whenever you treat these library wrappers, especially for cases when t=
he optional is engaged, in a generic<br>manner. <br>=A0<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>There *will* be code that is surprised that optional ordered T =
differently than T did.=A0 Not much code, but some.<br></div></div></div></=
div>
</blockquote><div><br></div><div>I would love to see an example of such cod=
e, then.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>
<br><br></div><div>The opening paragraphs of the optional proposal describe=
d a number of mental models for optinoal<> and chose "T with one=
more value".=A0 If that is the model, then acting like T is more impo=
rtant than acting like tuple.<span class=3D""><font color=3D"#888888"><br>
</font></span></div></div></div></div></blockquote><div><br></div><div>It c=
hose "A discriminated union of types <code>nullopt_t</code> and <code>=
T</code>."<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 />
--047d7b2e41a468fa2404dbd5dde5--
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Fri, 3 May 2013 17:09:27 -0300
Raw View
--089e013a214a67d21704dbd5efb3
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 7:25 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> Looks like IRAM is an O-member.
>
> http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee_participation.htm?commid=45202
>
Brazil is neither.
>
Regards,
--
Felipe Magno de Almeida
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--089e013a214a67d21704dbd5efb3
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 7:25 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>Looks like IRAM is an O-member. <br><a =
href=3D"http://www.iso.org/iso/home/standards_development/list_of_iso_techn=
ical_committees/iso_technical_committee_participation.htm?commid=3D45202" t=
arget=3D"_blank">http://www.iso.org/iso/home/standards_development/list_of_=
iso_technical_committees/iso_technical_committee_participation.htm?commid=
=3D45202</a> <br>
</div></div></div></div></blockquote><div><br></div><div>Brazil is neither.=
<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"><di=
v class=3D"gmail_extra">
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
</div></div></blockquote></div><br></div><div class=3D"gmail_extra">Regards=
,<br></div><div class=3D"gmail_extra">-- <br>Felipe Magno de Almeida
</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 />
--089e013a214a67d21704dbd5efb3--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Fri, 3 May 2013 13:35:07 -0700 (PDT)
Raw View
------=_Part_273_8662731.1367613307228
Content-Type: text/plain; charset=ISO-8859-1
Only because the Committee could not agree. I am arguing that it *should*
be consistent with T.
And I've yet to hear an explanation why it shouldn't be consistent with
> tuple.
Because then it is inconsistent with T, which is a bigger problem than
being inconsistent with tuple. Just because tuple is currently broken in
this regard does not mean that optional should be.
--
---
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_273_8662731.1367613307228
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Only because the Committee could not agree. I am arguing that it *should* b=
e consistent with T.<div><br></div><div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-colo=
r: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">And I'=
ve yet to hear an explanation why it shouldn't be consistent with tuple.</b=
lockquote><div><br></div><div>Because then it is inconsistent with T, which=
is a bigger problem than being inconsistent with tuple. Just because tuple=
is currently broken in this regard does not mean that optional should be.&=
nbsp;</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 />
------=_Part_273_8662731.1367613307228--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 3 May 2013 23:40:31 +0300
Raw View
--089e01229c30b1a5b404dbd65c85
Content-Type: text/plain; charset=ISO-8859-1
On 3 May 2013 23:35, DeadMG <wolfeinstein@gmail.com> wrote:
>
> And I've yet to hear an explanation why it shouldn't be consistent with
>> tuple.
>
>
> Because then it is inconsistent with T, which is a bigger problem than
> being inconsistent with tuple. Just because tuple is currently broken in
> this regard does not mean that optional should be.
>
>
I would much prefer them being consistent, and fix the leftover breakage
separately. But I have said that enough
times already. Just an addition, I don't think optional's allowing mixed
comparisons is any more reason for it
to need to be less "broken" than a comparison of two tuples.
--
---
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.
--089e01229c30b1a5b404dbd65c85
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 23:35, 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"><br><div><div class=3D"im"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And I've yet to hear an explanation why it shouldn't be consistent =
with tuple.</blockquote><div><br></div></div><div>Because then it is incons=
istent with T, which is a bigger problem than being inconsistent with tuple=
.. Just because tuple is currently broken in this regard does not mean that =
optional should be. <br>
=A0</div></div></blockquote></div><br></div><div class=3D"gmail_extra">I wo=
uld much prefer them being consistent, and fix the leftover breakage separa=
tely. But I have said that enough<br>times already. Just an addition, I don=
't think optional's allowing mixed comparisons is any more reason f=
or it<br>
</div><div class=3D"gmail_extra">to need to be less "broken" than=
a comparison of two tuples.<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 />
--089e01229c30b1a5b404dbd65c85--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 3 May 2013 17:19:03 -0400
Raw View
--047d7b3a8e607f532904dbd6e67d
Content-Type: text/plain; charset=ISO-8859-1
On Fri, May 3, 2013 at 4:04 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 3 May 2013 22:45, Tony V E <tvaneerd@gmail.com> wrote:
>
>> You know that we will never change tuple, unless we can somehow come up
>> with a backwards compatible change (ie generate > only if not defined by
>> underlying type - that would at least break *less* people).
>>
>
> I don't have any idea how you come to the conclusion that I "know" that.
>
Because you have been around the committee long enough to know how rarely
it breaks backwards compatibility. Maybe "know" was too strong, but close.
> I don't think that's the case at
> all, because currently a tuple<T*> doesn't even work as a key for an
> associative container, so that's
> something that needs to be looked at.
>
> Whether generating an op> is an issue is a completely different
> discussion, and then we need to answer
> the question whether the library needs to support types that would break
> if op> is generated via op<.
> My answer to that question is no.
>
>
>> I don't understand the importance of consistency with tuple.
>>
>
> I don't understand why optional should act differently from a tuple,
> especially for cases when the
> optional is engaged.
>
>
Really, don't understand? I assume you understand my reasoning, and just
find it unconvincing:
it should work differently than tuple because it is more important to work
the same as T - especially in the cases when the optional is engaged.
I *do* understand the reasoning of be consistent with other library
templates, I just find it less important, and I find those other templates
not really that similar to optional, thus making an analogy at all seems
incorrect. But I do understand the reasoning (just find it unconvincing
:-).
>> You currently cannot do
>>
>> tuple<int>() < int()
>>
>
> There are already suggestions to make tuple's constructor from the
> underlying type implicit.
>
"suggestions", maybe. But I'm not sure it is a good idea, and obviously
wasn't part of the design or "essence" of tuple.
Then you can do that.
>
>
>
>>
>> If you must pick "consistency" then consistency with T is more important
>> than consistency with tuple. There really isn't much analogy between tuple
>> and optional. Yes they are both templated structs. The End.
>>
>
> Neither tuple<T> nor optional<T> is a T. optional<T> may currently act
> more like a T, but it does that for comparisons
> only, and that's for convenience.
>
And comparisons are what we are talking about. (Also, not 'only'
comparisons - it also already has the implicit converting constructor -
another indicator of a *design* of 'act like T', and assignment from T.)
>
>
>>
>> I find tuple<> more like a cheap struct, like the classic EmployeeRecord
>> struct. And it doesn't bother me that EmployeeRecord isn't sorted exactly
>> like its members, so I can live with tuple<> not sorting like its members.
>> (still bothers me, but I can live with it)
>>
>
> I find optional like a cheap discriminated union, which is what it is.
>
>>
>>
>> When will *any* code get a surprising result because optional works
>> differently than tuple?
>>
>
> Whenever you treat these library wrappers, especially for cases when the
> optional is engaged, in a generic
> manner.
>
Yes, code that is using a template-template where the template-template
might be an optional or a tuple...
>
>
>> There *will* be code that is surprised that optional ordered T
>> differently than T did. Not much code, but some.
>>
>
> I would love to see an example of such code, then.
>
People do use doubles. People do use NaN behaviour.
People do make > different than < for their own types. I agree that they
typically shouldn't, but we allow it, and they do it. The odd time it
might even be for a good reason.
We assume people will use optional. The intersection may be small, but
probably not empty.
>
>
>>
>>
>> The opening paragraphs of the optional proposal described a number of
>> mental models for optinoal<> and chose "T with one more value". If that is
>> the model, then acting like T is more important than acting like tuple.
>>
>
> It chose "A discriminated union of types nullopt_t and T."
>
>
>
Huh, I see it did. I think the "T+value" version was earlier, or elsewhere
- actually in the doc in a couple of places. Like the reasoning for why
the mixed relops originally forwarded, while the non-mixed did not.
(as it turns out, the not-yet-initialized-T is probably best model, since
it is closest to how things like optional assignment really work (ie
construct-or-assign), but that's a separate story.)
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.
--047d7b3a8e607f532904dbd6e67d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 4:04 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>On 3 May 2013 22:45, 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:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">You know=
that we will never change tuple, unless we can somehow come up with a back=
wards compatible change (ie generate > only if not defined by underlying=
type - that would at least break *less* people).<br>
</div></blockquote><div><br></div></div><div>I don't have any idea how =
you come to the conclusion that I "know" that.</div></div></div><=
/div></blockquote><div><br></div><div>Because you have been around the comm=
ittee long enough to know how rarely it breaks backwards compatibility.=A0 =
Maybe "know" was too strong, but close.<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 cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div> I don't think that=
's the case at<br>
all, because currently a tuple<T*> doesn't even work as a key for=
an associative container, so that's<br>
something that needs to be looked at.<br><br></div><div>Whether generating =
an op> is an issue is a completely different discussion, and then we nee=
d to answer<br>the question whether the library needs to support types that=
would break if op> is generated via op<.<br>
</div><div>My answer to that question is no.<br>=A0<br></div><div><blockquo=
te 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 class=3D"gma=
il_extra">
<div class=3D"gmail_quote">
<div>I don't understand the importance of consistency with tuple.<br></=
div></div></div></div></blockquote><div><br></div></div><div>I don't un=
derstand why optional should act differently from a tuple, especially for c=
ases when the<br>
</div><div>optional is engaged.<br>=A0<br></div></div></div></div></blockqu=
ote><div><br></div><div>Really, don't understand?=A0 I assume you under=
stand my reasoning, and just find it unconvincing:<br><br></div><div>it sho=
uld work differently than tuple because it is more important to work the sa=
me as T - especially in the cases when the optional is engaged.<br>
<br></div><div>I *do* understand the reasoning of be consistent with other =
library templates, I just find it less important, and I find those other te=
mplates not really that similar to optional, thus making an analogy at all =
seems incorrect.=A0 But I do understand the reasoning (just find it unconvi=
ncing :-).<br>
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div></div><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>You currently cannot do<br><br></div><div>tuple<int>()=A0 &l=
t;=A0 int()<br></div></div></div></div></blockquote><div><br></div></div><d=
iv>There are already suggestions to make tuple's constructor from the u=
nderlying type implicit.<br>
</div></div></div></div></blockquote><div><br></div><div>"suggestions&=
quot;, maybe.=A0 But I'm not sure it is a good idea, and obviously wasn=
't part of the design or "essence" of tuple.<br><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=
>
</div><div>Then you can do that.<br>=A0<br></div><div><div>=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra">
<div class=3D"gmail_quote">
<div><br></div><div>If you must pick "consistency" then consisten=
cy with T is more important than consistency with tuple.=A0 There really is=
n't much analogy between tuple and optional.=A0 Yes they are both templ=
ated structs.=A0 The End.<br>
</div></div></div></div></blockquote><div><br></div></div><div>Neither tupl=
e<T> nor optional<T> is a T. optional<T> may currently ac=
t more like a T, but it does that for comparisons<br>only, and that's f=
or convenience.<br>
</div></div></div></div></blockquote><div><br></div><div>And comparisons ar=
e what we are talking about.=A0 (Also, not 'only' comparisons - it =
also already has the implicit converting constructor - another indicator of=
a *design* of 'act like T', and assignment from T.)<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>
=A0<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>
<br>I=20
find tuple<> more like a cheap struct, like the classic=20
EmployeeRecord struct.=A0 And it doesn't bother me that EmployeeRecord=
=20
isn't sorted exactly like its members, so I can live with tuple<>=
=20
not sorting like its members.=A0 (still bothers me, but I can live with=20
it)<br></div></div></div></div></blockquote><div><br></div></div><div>I fin=
d optional like a cheap discriminated union, which is what it is. <br></div=
><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br><br>When will *any* code get a surprising result because optional work=
s differently than tuple?<br></div></div></div></div></blockquote><div><br>=
</div>
</div><div>Whenever you treat these library wrappers, especially for cases =
when the optional is engaged, in a generic<br>manner. <br></div></div></div=
></div></blockquote><div><br><br></div><div>Yes, code that is using a templ=
ate-template where the template-template might be an optional or a tuple...=
<br>
<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>=A0<br></div><div><blockqu=
ote 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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>There *will* be code that is surprised that optional ordered T =
differently than T did.=A0 Not much code, but some.<br></div></div></div></=
div>
</blockquote><div><br></div></div><div>I would love to see an example of su=
ch code, then.<br></div></div></div></div></blockquote><div><br></div><div>=
People do use doubles.=A0 People do use NaN behaviour.<br><br></div><div>
People do make > different than < for their own types.=A0 I agree tha=
t they typically shouldn't, but we allow it, and they do it.=A0 The odd=
time it might even be for a good reason.<br><br></div><div>We assume peopl=
e will use optional. The intersection may be small, but probably not empty.=
<br>
</div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>=A0<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>
<br><br></div><div>The opening paragraphs of the optional proposal describe=
d a number of mental models for optinoal<> and chose "T with one=
more value".=A0 If that is the model, then acting like T is more impo=
rtant than acting like tuple.<span><font color=3D"#888888"><br>
</font></span></div></div></div></div></blockquote><div><br></div></div><di=
v>It chose "A discriminated union of types <code>nullopt_t</code> and =
<code>T</code>."<br><br></div></div><br></div></div></blockquote>
<div><br></div><div>Huh, I see it did.=A0 I think the "T+value" v=
ersion was earlier, or elsewhere - actually in the doc in a couple of place=
s.=A0 Like the reasoning for why the mixed relops originally forwarded, whi=
le the non-mixed did not.<br>
<br></div><div><br>(as it turns out, the not-yet-initialized-T is probably =
best model, since it is closest to how things like optional assignment real=
ly work (ie construct-or-assign), but that's a separate story.)<br>
=A0<br></div></div>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 />
--047d7b3a8e607f532904dbd6e67d--
.
Author: Marc <marc.glisse@gmail.com>
Date: Fri, 3 May 2013 15:09:30 -0700 (PDT)
Raw View
------=_Part_168_4037042.1367618970991
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le vendredi 3 mai 2013 20:12:40 UTC+2, Ville Voutilainen a =E9crit :
>
>
> On 3 May 2013 20:55, Marc <marc....@gmail.com <javascript:>> wrote:
>
>>
>> But why should I, as someone using a non total order, have to specialize=
=20
>> anything? If the underlying type has operator>, then optional should use=
it=20
>> for >. If it doesn't, then optional shouldn't either. If you are using=
=20
>> rel_ops with T, you can just as well use rel_ops with optional<T>.
>> =20
>> Currently tuple, pair and containers don't do that. It would be=20
> reasonable to be consistent in that regard
> with optional, and consider further changes separately afterwards.
>
It is not clear how to define a lexicographic ordering (for >=3D2 elements)=
=20
based on a weird ordering of the elements, so basing it on < only is not an=
=20
absurd choice (not providing those operators might have been better, I=20
don't think special casing containers of size 1 would be a good idea). On=
=20
the other hand, it is obvious how to define an ordering on T based on a=20
weird ordering on T. So if operator> is provided on optional<T> and=20
operator> disagrees between T and tuple<T>, I'd rather have it return the=
=20
same as with T. While I am here, I would also argue that it shouldn't=20
return bool but decltype(auto), in case operator< returns a tribool for=20
instance. And maybe add a noexcept(auto) (using the current heavy syntax=20
instead)?
But mostly, the rational for providing operator< seems to be so we can put=
=20
it in an std::set, but that's already handled by specializing std::less=20
(which I agree should have had a better name), so in my opinion=20
std::optional should simply not provide operator< at all. That seems the=20
safest thing.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_168_4037042.1367618970991
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le vendredi 3 mai 2013 20:12:40 UTC+2, Ville Voutilainen a =E9crit :<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><div c=
lass=3D"gmail_quote">On 3 May 2013 20:55, Marc <span dir=3D"ltr"><<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"OFgL3H-XcdUJ">=
marc....@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><div>But why should I, as someone using =
a non total order, have to specialize anything? If the underlying type has =
operator>, then optional should use it for >. If it doesn't, then opt=
ional shouldn't either. If you are using rel_ops with T, you can just=
as well use rel_ops with optional<T>.<br>
</div><div><div>
<br></div></div></blockquote><div>Currently tuple, pair and containers don'=
t do that. It would be reasonable to be consistent in that regard<br>with o=
ptional, and consider further changes separately afterwards.<br></div></div=
></div></div></blockquote><div><br>It is not clear how to define a lexicogr=
aphic ordering (for >=3D2 elements) based on a weird ordering of the ele=
ments, so basing it on < only is not an absurd choice (not providing tho=
se operators might have been better, I don't think special casing container=
s of size 1 would be a good idea). On the other hand, it is obvious how to =
define an ordering on T based on a weird ordering on T. So if operator> =
is provided on optional<T> and operator> disagrees between T and t=
uple<T>, I'd rather have it return the same as with T. While I am her=
e, I would also argue that it shouldn't return bool but decltype(auto), in =
case operator< returns a tribool for instance. And maybe add a noexcept(=
auto) (using the current heavy syntax instead)?<br><br>But mostly, the rati=
onal for providing operator< seems to be so we can put it in an std::set=
, but that's already handled by specializing std::less (which I agree shoul=
d have had a better name), so in my opinion std::optional should simply not=
provide operator< at all. That seems the safest thing.<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_168_4037042.1367618970991--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 4 May 2013 02:50:12 +0300
Raw View
--047d7b2e41a40c276604dbd903d7
Content-Type: text/plain; charset=ISO-8859-1
On 4 May 2013 00:19, Tony V E <tvaneerd@gmail.com> wrote:
>
> You know that we will never change tuple, unless we can somehow come up
> with a backwards compatible change (ie generate > only if not defined by
> underlying type - that would at least break *less* people).
>
>>
>> I don't have any idea how you come to the conclusion that I "know" that.
>>
>
> Because you have been around the committee long enough to know how rarely
> it breaks backwards compatibility. Maybe "know" was too strong, but close.
>
I've been around the committee long enough to know that it breaks backwards
compatibility in every
(F)CD it releases, if need be.
> I don't understand why optional should act differently from a tuple,
> especially for cases when the
>
>> optional is engaged.
>>
>>
>
> Really, don't understand? I assume you understand my reasoning, and just
> find it unconvincing:
>
Really, "don't understand why optional _should_", if we read what I wrote
without cherry-picking
individual words out of context. That's perhaps less a statement about my
cognitive capabilities,
and more a statement about my finding the reasoning unconvincing.
> Neither tuple<T> nor optional<T> is a T. optional<T> may currently act
>> more like a T, but it does that for comparisons
>> only, and that's for convenience.
>>
>
> And comparisons are what we are talking about. (Also, not 'only'
> comparisons - it also already has the implicit converting constructor -
> another indicator of a *design* of 'act like T', and assignment from T.)
>
Yes, and the convenience remark above is trying to say that those
comparisons are for convenience, not
for making optional<T> act like a T. The difference is thin, but it's there.
>
> Whenever you treat these library wrappers, especially for cases when the
>> optional is engaged, in a generic
>> manner.
>>
>
>
> Yes, code that is using a template-template where the template-template
> might be an optional or a tuple...
>
template <class T> bool operator<(const T& t, int i)
{
return t<i;
}
No need for a template-template there.
>
>
>
>>
>>
>>> There *will* be code that is surprised that optional ordered T
>>> differently than T did. Not much code, but some.
>>>
>>
>> I would love to see an example of such code, then.
>>
>
> People do use doubles. People do use NaN behaviour.
>
I don't find that a convincing argument. boost::optional was shipped in
2003 and it doesn't treat doubles
transparently, so it has always had the NaN behaviour you say is
problematic. Ever since I actually
tested the NaN case with boost::optional, I have become convinced that it
would need a much stronger
argument to change that behaviour than what we have
> People do make > different than < for their own types. I agree that they
> typically shouldn't, but we allow it, and they do it. The odd time it
> might even be for a good reason.
>
> We assume people will use optional. The intersection may be small, but
> probably not empty.
>
And I find it perfectly reasonable to not support such types transparently.
--
---
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.
--047d7b2e41a40c276604dbd903d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 May 2013 00:19, 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 dir=3D"ltr">You kn=
ow that we will never change tuple, unless we can somehow come up with a ba=
ckwards compatible change (ie generate > only if not defined by underlyi=
ng type - that would at least break *less* people).<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"i=
m"><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_extr=
a"><div class=3D"gmail_quote">
<div><div><br></div></div><div>I don't have any idea how you come to th=
e conclusion that I "know" that.</div></div></div></div></blockqu=
ote><div><br></div></div><div>Because you have been around the committee lo=
ng enough to know how rarely it breaks backwards compatibility.=A0 Maybe &q=
uot;know" was too strong, but close.<br>
</div></div></div></div></blockquote><div><br></div><div>I've been arou=
nd the committee long enough to know that it breaks backwards compatibility=
in every<br></div><div>(F)CD it releases, if need be.<br>=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">I do=
n't understand why optional should act differently from a tuple, especi=
ally for cases when the<br>
<div class=3D"im"><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 clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>optional is engaged.<br>=
=A0<br></div>
</div></div></div></blockquote><div><br></div></div><div>Really, don't =
understand?=A0 I assume you understand my reasoning, and just find it uncon=
vincing:<br></div></div></div></div></blockquote><div><br></div><div>Really=
, "don't understand why optional _should_", if we read what I=
wrote without cherry-picking<br>
</div><div>individual words out of context. That's perhaps less a state=
ment about my cognitive capabilities,<br>and more a statement about my find=
ing the reasoning unconvincing.<br>=A0<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<div class=3D"im"><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 clas=
s=3D"gmail_extra">
<div class=3D"gmail_quote"><div>Neither tuple<T> nor optional<T>=
; is a T. optional<T> may currently act more like a T, but it does th=
at for comparisons<br>only, and that's for convenience.<br>
</div></div></div></div></blockquote><div><br></div></div><div>And comparis=
ons are what we are talking about.=A0 (Also, not 'only' comparisons=
- it also already has the implicit converting constructor - another indica=
tor of a *design* of 'act like T', and assignment from T.)<br>
</div></div></div></div></blockquote><div><br></div><div>Yes, and the conve=
nience remark above is trying to say that those comparisons are for conveni=
ence, not<br></div><div>for making optional<T> act like a T. The diff=
erence is thin, but it's there.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><br><div class=3D"im"><blockquote c=
lass=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=
>Whenever you treat these library wrappers, especially for cases when the o=
ptional is engaged, in a generic<br>manner. <br></div></div></div></div></b=
lockquote>
<div><br><br></div></div><div>Yes, code that is using a template-template w=
here the template-template might be an optional or a tuple...<br></div></di=
v></div></div></blockquote><div><br></div><div>template <class T> boo=
l operator<(const T& t, int i)<br>
{<br></div><div>=A0=A0 return t<i;<br></div><div>}<br><br></div><div>No =
need for a template-template there.<br>=A0<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>
<br>=A0<br></div><div class=3D"im"><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>=A0<br>=
</div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>There *will* be code that is surprised that optional ordered T =
differently than T did.=A0 Not much code, but some.<br></div></div></div></=
div>
</blockquote><div><br></div></div><div>I would love to see an example of su=
ch code, then.<br></div></div></div></div></blockquote><div><br></div></div=
><div>People do use doubles.=A0 People do use NaN behaviour.<br></div></div=
>
</div></div></blockquote><div><br></div><div>I don't find that a convin=
cing argument. boost::optional was shipped in 2003 and it doesn't treat=
doubles<br>transparently, so it has always had the NaN behaviour you say i=
s problematic. Ever since I actually<br>
tested the NaN case with boost::optional, I have become convinced that it w=
ould need a much stronger<br>argument to change that behaviour than what we=
have <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div><div>
People do make > different than < for their own types.=A0 I agree tha=
t they typically shouldn't, but we allow it, and they do it.=A0 The odd=
time it might even be for a good reason.<br><br></div><div>We assume peopl=
e will use optional. The intersection may be small, but probably not empty.=
<br>
</div></div></div></div></blockquote><div><br></div><div>And I find it perf=
ectly reasonable to not support such types transparently.<br>=A0<br></div><=
/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 />
--047d7b2e41a40c276604dbd903d7--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 4 May 2013 02:52:53 +0300
Raw View
--047d7b2e0887a2133604dbd90ce3
Content-Type: text/plain; charset=ISO-8859-1
On 4 May 2013 01:09, Marc <marc.glisse@gmail.com> wrote:
>
> But mostly, the rational for providing operator< seems to be so we can put
> it in an std::set, but that's already handled by specializing std::less
> (which I agree should have had a better name), so in my opinion
> std::optional should simply not provide operator< at all. That seems the
> safest thing.
>
> --
>
>
I have no trouble with the name of std::less. What I wrote before was that
I'd prefer not using std::less for
ordering keys of associative 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.
--047d7b2e0887a2133604dbd90ce3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 May 2013 01:09, Marc <span dir=3D"ltr"><<a href=3D"mailto:m=
arc.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"><div><br>But mostly, the rational for provid=
ing operator< seems to be so we can put it in an std::set, but that'=
s already handled by specializing std::less (which I agree should have had =
a better name), so in my opinion std::optional should simply not provide op=
erator< at all. That seems the safest thing.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
--<br><br></div></div></blockquote><div><br></div><div>I have no trouble wi=
th the name of std::less. What I wrote before was that I'd prefer not u=
sing std::less for<br></div><div>ordering keys of associative 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 />
--047d7b2e0887a2133604dbd90ce3--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 3 May 2013 21:17:36 -0400
Raw View
--089e013d17009bf0e404dbda3bff
Content-Type: text/plain; charset=ISO-8859-1
On Fri, May 3, 2013 at 7:52 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 4 May 2013 01:09, Marc <marc.glisse@gmail.com> wrote:
>
>>
>> But mostly, the rational for providing operator< seems to be so we can
>> put it in an std::set, but that's already handled by specializing std::less
>> (which I agree should have had a better name), so in my opinion
>> std::optional should simply not provide operator< at all. That seems the
>> safest thing.
>>
>> --
>>
>>
> I have no trouble with the name of std::less. What I wrote before was that
> I'd prefer not using std::less for
> ordering keys of associative container. ;)
>
>
That I agree with. I always felt map should use something like
std::map_less<T>, for example. Which would default to std::less<T>.
(Possibly via std::container_less<T> in the middle as well?)
I actually don't think that would be a breaking change.
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.
--089e013d17009bf0e404dbda3bff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 7:52 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 4 May 2013 01:0=
9, Marc <span dir=3D"ltr"><<a href=3D"mailto:marc.glisse@gmail.com" targ=
et=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"><div><br>But mostly, the rational for provid=
ing operator< seems to be so we can put it in an std::set, but that'=
s already handled by specializing std::less (which I agree should have had =
a better name), so in my opinion std::optional should simply not provide op=
erator< at all. That seems the safest thing.<br>
</div><div><div>
<p></p>
--<br><br></div></div></blockquote><div><br></div></div><div>I have no trou=
ble with the name of std::less. What I wrote before was that I'd prefer=
not using std::less for<br></div><div>ordering keys of associative contain=
er. ;) <br>
</div></div><br></div></div></blockquote><div><br></div><div>That I agree w=
ith. =A0I always felt map should use something like std::map_less<T>,=
for example. =A0Which would default to std::less<T>. =A0(Possibly vi=
a std::container_less<T> in the middle as well?)</div>
<div>=A0</div><div>I actually don't think that would be a breaking chan=
ge.</div><div><br></div><div>Tony</div><div><br></div></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 />
--089e013d17009bf0e404dbda3bff--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 3 May 2013 21:41:45 -0400
Raw View
--089e0118451004e17004dbda92f8
Content-Type: text/plain; charset=ISO-8859-1
On Fri, May 3, 2013 at 7:50 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 4 May 2013 00:19, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>> You know that we will never change tuple, unless we can somehow come up
>> with a backwards compatible change (ie generate > only if not defined by
>> underlying type - that would at least break *less* people).
>>
>>>
>>> I don't have any idea how you come to the conclusion that I "know" that.
>>>
>>
>> Because you have been around the committee long enough to know how rarely
>> it breaks backwards compatibility. Maybe "know" was too strong, but close.
>>
>
> I've been around the committee long enough to know that it breaks
> backwards compatibility in every
> (F)CD it releases, if need be.
>
>
>> I don't understand why optional should act differently from a tuple,
>> especially for cases when the
>>
>>> optional is engaged.
>>>
>>>
>>
>> Really, don't understand? I assume you understand my reasoning, and just
>> find it unconvincing:
>>
>
> Really, "don't understand why optional _should_", if we read what I wrote
> without cherry-picking
> individual words out of context. That's perhaps less a statement about my
> cognitive capabilities,
> and more a statement about my finding the reasoning unconvincing.
>
>
OK, their your words, so I'll take your word for it :-)
(But I could see myself saying "I understand why optional should work like
tuple, I also understand why it shouldn't". Regardless of which I found
most convincing.)
>
>
>> Neither tuple<T> nor optional<T> is a T. optional<T> may currently act
>>> more like a T, but it does that for comparisons
>>> only, and that's for convenience.
>>>
>>
>> And comparisons are what we are talking about. (Also, not 'only'
>> comparisons - it also already has the implicit converting constructor -
>> another indicator of a *design* of 'act like T', and assignment from T.)
>>
>
> Yes, and the convenience remark above is trying to say that those
> comparisons are for convenience, not
> for making optional<T> act like a T. The difference is thin, but it's
> there.
>
>
>>
>> Whenever you treat these library wrappers, especially for cases when the
>>> optional is engaged, in a generic
>>> manner.
>>>
>>
>>
>> Yes, code that is using a template-template where the template-template
>> might be an optional or a tuple...
>>
>
> template <class T> bool operator<(const T& t, int i)
> {
> return t<i;
> }
>
> No need for a template-template there.
>
So T is either optional<X> or tuple<X> (or more likely optional<int> or
tuple<int>)? And assuming tuple<int> < i some day works? Or do I
misunderstand?
>
>>
>>
>>
>>>
>>>
>>>> There *will* be code that is surprised that optional ordered T
>>>> differently than T did. Not much code, but some.
>>>>
>>>
>>> I would love to see an example of such code, then.
>>>
>>
>> People do use doubles. People do use NaN behaviour.
>>
>
> I don't find that a convincing argument. boost::optional was shipped in
> 2003 and it doesn't treat doubles
> transparently, so it has always had the NaN behaviour you say is
> problematic. Ever since I actually
> tested the NaN case with boost::optional, I have become convinced that it
> would need a much stronger
> argument to change that behaviour than what we have
>
>
>> People do make > different than < for their own types. I agree that they
>> typically shouldn't, but we allow it, and they do it. The odd time it
>> might even be for a good reason.
>>
>> We assume people will use optional. The intersection may be small, but
>> probably not empty.
>>
>
> And I find it perfectly reasonable to not support such types transparently.
>
Note that if you don't care about NaN and such types, then you probably
shouldn't care about this issue at all. For any "sane" types, either
definition of optional gives the same answer.
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.
--089e0118451004e17004dbda92f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 7:50 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>On 4 May 2013 00:19, 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"><br><div dir=3D"ltr">You kn=
ow that we will never change tuple, unless we can somehow come up with a ba=
ckwards compatible change (ie generate > only if not defined by underlyi=
ng type - that would at least break *less* people).<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<div><div><br></div></div><div>I don't have any idea how you come to th=
e conclusion that I "know" that.</div></div></div></div></blockqu=
ote><div><br></div></div><div>Because you have been around the committee lo=
ng enough to know how rarely it breaks backwards compatibility.=A0 Maybe &q=
uot;know" was too strong, but close.<br>
</div></div></div></div></blockquote><div><br></div></div><div>I've bee=
n around the committee long enough to know that it breaks backwards compati=
bility in every<br></div><div>(F)CD it releases, if need be.<br>=A0<br></di=
v>
<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">I do=
n't understand why optional should act differently from a tuple, especi=
ally for cases when the<br>
<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div>optional is engaged.<br>=A0<br></div>
</div></div></div></blockquote><div><br></div></div><div>Really, don't =
understand?=A0 I assume you understand my reasoning, and just find it uncon=
vincing:<br></div></div></div></div></blockquote><div><br></div></div><div>
Really, "don't understand why optional _should_", if we read =
what I wrote without cherry-picking<br>
</div><div>individual words out of context. That's perhaps less a state=
ment about my cognitive capabilities,<br>and more a statement about my find=
ing the reasoning unconvincing.<br>=A0<br></div></div></div></div></blockqu=
ote>
<div><br></div><div>OK, their your words, so I'll take your word for it=
:-)=A0</div><div>(But I could see myself saying "I understand why opt=
ional should work like tuple, I also understand why it shouldn't".=
=A0Regardless of which I found most convincing.)</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><br></div><div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra">
<div class=3D"gmail_quote"><div>Neither tuple<T> nor optional<T>=
; is a T. optional<T> may currently act more like a T, but it does th=
at for comparisons<br>only, and that's for convenience.<br>
</div></div></div></div></blockquote><div><br></div></div><div>And comparis=
ons are what we are talking about.=A0 (Also, not 'only' comparisons=
- it also already has the implicit converting constructor - another indica=
tor of a *design* of 'act like T', and assignment from T.)<br>
</div></div></div></div></blockquote><div><br></div></div><div>Yes, and the=
convenience remark above is trying to say that those comparisons are for c=
onvenience, not<br></div><div>for making optional<T> act like a T. Th=
e difference is thin, but it's there.<br>
=A0<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><br><div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Whenever you treat these library wrappers, especially for cases when the o=
ptional is engaged, in a generic<br>manner. <br></div></div></div></div></b=
lockquote>
<div><br><br></div></div><div>Yes, code that is using a template-template w=
here the template-template might be an optional or a tuple...<br></div></di=
v></div></div></blockquote><div><br></div></div><div>template <class T&g=
t; bool operator<(const T& t, int i)<br>
{<br></div><div>=A0=A0 return t<i;<br></div><div>}<br><br></div><div>No =
need for a template-template there.<br></div></div></div></div></blockquote=
><div><br></div><div>So T is either optional<X> or tuple<X> (or=
more likely optional<int> or tuple<int>)? =A0And assuming tupl=
e<int> < i some day works? =A0Or do I misunderstand?</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>=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 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>
<br>=A0<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=A0<br></div><div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>There *will* be code that is surprised that optional ordered T =
differently than T did.=A0 Not much code, but some.<br></div></div></div></=
div>
</blockquote><div><br></div></div><div>I would love to see an example of su=
ch code, then.<br></div></div></div></div></blockquote><div><br></div></div=
><div>People do use doubles.=A0 People do use NaN behaviour.<br></div></div=
>
</div></div></blockquote><div><br></div></div><div>I don't find that a =
convincing argument. boost::optional was shipped in 2003 and it doesn't=
treat doubles<br>transparently, so it has always had the NaN behaviour you=
say is problematic. Ever since I actually<br>
tested the NaN case with boost::optional, I have become convinced that it w=
ould need a much stronger<br>argument to change that behaviour than what we=
have <br><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div><div>
People do make > different than < for their own types.=A0 I agree tha=
t they typically shouldn't, but we allow it, and they do it.=A0 The odd=
time it might even be for a good reason.<br><br></div><div>We assume peopl=
e will use optional. The intersection may be small, but probably not empty.=
<br>
</div></div></div></div></blockquote><div><br></div></div><div>And I find i=
t perfectly reasonable to not support such types transparently.<br></div></=
div></div></div></blockquote><div><br></div><div>=A0</div><div>Note that if=
you don't care about NaN and such types, then you probably shouldn'=
;t care about this issue at all. =A0For any "sane" types, either =
definition of optional gives the same answer.</div>
<div><br></div><div>Tony</div><div><br></div></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 />
--089e0118451004e17004dbda92f8--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 3 May 2013 21:42:31 -0400
Raw View
--047d7b3441febaa86604dbda9472
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, May 3, 2013 at 6:09 PM, Marc <marc.glisse@gmail.com> wrote:
> Le vendredi 3 mai 2013 20:12:40 UTC+2, Ville Voutilainen a =E9crit :
>
>>
>> On 3 May 2013 20:55, Marc <marc....@gmail.com> wrote:
>>
>>>
>>> But why should I, as someone using a non total order, have to specializ=
e
>>> anything? If the underlying type has operator>, then optional should us=
e it
>>> for >. If it doesn't, then optional shouldn't either. If you are using
>>> rel_ops with T, you can just as well use rel_ops with optional<T>.
>>>
>>> Currently tuple, pair and containers don't do that. It would be
>> reasonable to be consistent in that regard
>> with optional, and consider further changes separately afterwards.
>>
>
> It is not clear how to define a lexicographic ordering (for >=3D2 element=
s)
> based on a weird ordering of the elements, so basing it on < only is not =
an
> absurd choice
>
It is actually the same as how it is done for <. My initial thought was
the same - that it would need to work differently (ie back to front or
something) but it doesn't.
> (not providing those operators might have been better, I don't think
> special casing containers of size 1 would be a good idea). On the other
> hand, it is obvious how to define an ordering on T based on a weird
> ordering on T. So if operator> is provided on optional<T> and operator>
> disagrees between T and tuple<T>, I'd rather have it return the same as
> with T. While I am here, I would also argue that it shouldn't return bool
> but decltype(auto), in case operator< returns a tribool for instance. And
> maybe add a noexcept(auto) (using the current heavy syntax instead)?
>
>
Interesting. We can't actually return decltype(auto) unless we allow T to
decide how nullopt and T compare. optional<T> decides how nullopt is
ordered against T (nullopt is least-most) - and returns true or false for
that comparison, then lets T order the rest. So you either dictate that
the return type be at least convertible from bool, or give the client some
way to define how nullopt is ordered (via traits or something).
> But mostly, the rational for providing operator< seems to be so we can pu=
t
> it in an std::set, but that's already handled by specializing std::less
> (which I agree should have had a better name), so in my opinion
> std::optional should simply not provide operator< at all. That seems the
> safest thing.
>
> --
>
>
I'd be OK with that if there was an easy way to enable the comparisons when
you actually did want them (an opt-in strategy). ie - easier than writing
them all yourself.
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.
--047d7b3441febaa86604dbda9472
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 3, 2013 at 6:09 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 vendredi 3 mai 2013 20:12:40 UTC+2, Ville=
Voutilainen a =E9crit=A0:<div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div><div class=3D"gmail_quote">On 3 May 2013 20:55, M=
arc <span dir=3D"ltr"><<a>marc....@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><div>But why should I, as someone using =
a non total order, have to specialize anything? If the underlying type has =
operator>, then optional should use it for >. If it doesn't, then=
optional shouldn't either. If=A0 you are using rel_ops with T, you can=
just as well use rel_ops with optional<T>.<br>
</div><div><div>
<br></div></div></blockquote><div>Currently tuple, pair and containers don&=
#39;t do that. It would be reasonable to be consistent in that regard<br>wi=
th optional, and consider further changes separately afterwards.<br></div>
</div></div></div></blockquote></div><div><br>It is not clear how to define=
a lexicographic ordering (for >=3D2 elements) based on a weird ordering=
of the elements, so basing it on < only is not an absurd choice </div>
</blockquote><div><br></div><div>It is actually the same as how it is done =
for <. =A0My initial thought was the same - that it would need to work d=
ifferently (ie back to front or something) but it doesn't.</div><div>
<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>(not providing =
those operators might have been better, I don't think special casing co=
ntainers of size 1 would be a good idea). On the other hand, it is obvious =
how to define an ordering on T based on a weird ordering on T. So if operat=
or> is provided on optional<T> and operator> disagrees between =
T and tuple<T>, I'd rather have it return the same as with T. Whi=
le I am here, I would also argue that it shouldn't return bool but decl=
type(auto), in case operator< returns a tribool for instance. And maybe =
add a noexcept(auto) (using the current heavy syntax instead)?<br>
<br></div></blockquote><div><br></div><div>Interesting. =A0We can't act=
ually return decltype(auto) unless we allow T to decide how nullopt and T c=
ompare. =A0optional<T> decides how nullopt is ordered against T (null=
opt is least-most) - and returns true or false for that comparison, then le=
ts T order the rest. =A0So you either dictate that the return type be at le=
ast convertible from bool, or give the client some way to define how nullop=
t is ordered (via traits or something).</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>But mostly=
, the rational for providing operator< seems to be so we can put it in a=
n std::set, but that's already handled by specializing std::less (which=
I agree should have had a better name), so in my opinion std::optional sho=
uld simply not provide operator< at all. That seems the safest thing.<br=
>
</div><div><div>
<p></p>
-- <br>=A0=A0</div></div></blockquote><div><br></div><div>I'd be OK wit=
h that if there was an easy way to enable the comparisons when you actually=
did want them (an opt-in strategy). ie - easier than writing them all your=
self.</div>
<div>=A0</div><div>Tony</div></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 />
--047d7b3441febaa86604dbda9472--
.
Author: Marc <marc.glisse@gmail.com>
Date: Sat, 4 May 2013 01:30:27 -0700 (PDT)
Raw View
------=_Part_754_24065199.1367656227501
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le samedi 4 mai 2013 03:42:31 UTC+2, Tony V E a =E9crit :
>
> On Fri, May 3, 2013 at 6:09 PM, Marc <marc....@gmail.com <javascript:>>wr=
ote:
>
>> It is not clear how to define a lexicographic ordering (for >=3D2 elemen=
ts)=20
>> based on a weird ordering of the elements, so basing it on < only is not=
an=20
>> absurd choice=20
>
>
> It is actually the same as how it is done for <. My initial thought was=
=20
> the same - that it would need to work differently (ie back to front or=20
> something) but it doesn't.
>
But for a weird ordering, it isn't clear that you want the lexicographic <=
=3D=20
to be defined only in terms of <=3D, defining it with some mix of < and <=
=3D=20
might make more sense. And since there is no clear answer...
(not providing those operators might have been better, I don't think=20
>> special casing containers of size 1 would be a good idea). On the other=
=20
>> hand, it is obvious how to define an ordering on T based on a weird=20
>> ordering on T. So if operator> is provided on optional<T> and operator>=
=20
>> disagrees between T and tuple<T>, I'd rather have it return the same as=
=20
>> with T. While I am here, I would also argue that it shouldn't return boo=
l=20
>> but decltype(auto), in case operator< returns a tribool for instance. An=
d=20
>> maybe add a noexcept(auto) (using the current heavy syntax instead)?
>>
>>
> Interesting. We can't actually return decltype(auto) unless we allow T t=
o=20
> decide how nullopt and T compare. optional<T> decides how nullopt is=20
> ordered against T (nullopt is least-most) - and returns true or false for=
=20
> that comparison, then lets T order the rest. So you either dictate that=
=20
> the return type be at least convertible from bool, or give the client som=
e=20
> way to define how nullopt is ordered (via traits or something).
>
The example implementation for operator< had a single return statement, so=
=20
using decltype(auto) should be ok (although something more explicit could=
=20
be better), and it used cond?true:(*a<*b) which is already assuming that=20
bool and the return type can find some common type.
=20
> But mostly, the rational for providing operator< seems to be so we can pu=
t=20
>> it in an std::set, but that's already handled by specializing std::less=
=20
>> (which I agree should have had a better name), so in my opinion=20
>> std::optional should simply not provide operator< at all. That seems the=
=20
>> safest thing.=20
>>
>> I'd be OK with that if there was an easy way to enable the comparisons=
=20
> when you actually did want them (an opt-in strategy). ie - easier than=20
> writing them all yourself.
>
But why for comparisons in particular? Why not for operator+ as well (it=20
could return a disengaged result whenever one argument is disengaged, like=
=20
a NaN)? By the way, comparisons could return an optional<bool> (aka=20
tribool), it would make just as much sense. And maybe overload operator. (I=
=20
know it doesn't exist) to forward to members of T? optional has an=20
interface similar to pointers, and... well, we do seem to provide all the=
=20
comparisons on shared_ptr (they forward to the underlying pointer).
It seems to me that providing operator< (and the others) is outside the=20
scope of optional. Whereas providing a specialization for=20
std::default_arbitrary_set_ordering (aka std::less) and std::hash and=20
possibly an overload for =3D=3D (and maybe !=3D) is what's needed for a goo=
d=20
integration with the rest of the standard library. But re-reading through=
=20
the library, I see that providing all the comparison operators is what's=20
done everywhere, so I'll stop complaining and simply refrain from using=20
optional in sensitive cases.
Sorry for contributing to the extra-length of this discussion.
--=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_754_24065199.1367656227501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le samedi 4 mai 2013 03:42:31 UTC+2, Tony V E a =E9crit :<blockquote c=
lass=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_q=
uote">On Fri, May 3, 2013 at 6:09 PM, Marc <span dir=3D"ltr"><<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"UhCmNRrTQ-cJ">marc=
.....@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 is not clear how to define a lexicographi=
c ordering (for >=3D2 elements) based on a weird ordering of the element=
s, so basing it on < only is not an absurd choice=20
</blockquote><div><br></div><div>It is actually the same as how it is done =
for <. My initial thought was the same - that it would need to wor=
k differently (ie back to front or something) but it doesn't.</div></div></=
div></div></blockquote><div><br>But for a weird ordering, it isn't clear th=
at you want the lexicographic <=3D to be defined only in terms of <=
=3D, defining it with some mix of < and <=3D might make more sense. A=
nd since there is no clear answer...<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div><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>(not providing those operators m=
ight have been better, I don't think special casing containers of size 1 wo=
uld be a good idea). On the other hand, it is obvious how to define an orde=
ring on T based on a weird ordering on T. So if operator> is provided on=
optional<T> and operator> disagrees between T and tuple<T>,=
I'd rather have it return the same as with T. While I am here, I would als=
o argue that it shouldn't return bool but decltype(auto), in case operator&=
lt; returns a tribool for instance. And maybe add a noexcept(auto) (using t=
he current heavy syntax instead)?<br>
<br></div></blockquote><div><br></div><div>Interesting. We can't actu=
ally return decltype(auto) unless we allow T to decide how nullopt and T co=
mpare. optional<T> decides how nullopt is ordered against T (nu=
llopt is least-most) - and returns true or false for that comparison, then =
lets T order the rest. So you either dictate that the return type be =
at least convertible from bool, or give the client some way to define how n=
ullopt is ordered (via traits or something).</div></div></div></div></block=
quote><div><br>The example implementation for operator< had a single ret=
urn statement, so using decltype(auto) should be ok (although something mor=
e explicit could be better), and it used cond?true:(*a<*b) which is alre=
ady assuming that bool and the return type can find some common type.<br>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>But mostly, the rational for providing =
operator< seems to be so we can put it in an std::set, but that's alread=
y handled by specializing std::less (which I agree should have had a better=
name), so in my opinion std::optional should simply not provide operator&l=
t; at all. That seems the safest thing.
</div><div><div>
<br></div></div></blockquote><div>I'd be OK with that if there was an easy =
way to enable the comparisons when you actually did want them (an opt-in st=
rategy). ie - easier than writing them all yourself.</div></div></div></div=
></blockquote><div><br>But why for comparisons in particular? Why not for o=
perator+ as well (it could return a disengaged result whenever one argument=
is disengaged, like a NaN)? By the way, comparisons could return an option=
al<bool> (aka tribool), it would make just as much sense. And maybe o=
verload operator. (I know it doesn't exist) to forward to members of T? opt=
ional has an interface similar to pointers, and... well, we do seem to prov=
ide all the comparisons on shared_ptr (they forward to the underlying point=
er).<br><br>It seems to me that providing operator< (and the others) is =
outside the scope of optional. Whereas providing a specialization for std::=
default_arbitrary_set_ordering (aka std::less) and std::hash and possibly a=
n overload for =3D=3D (and maybe !=3D) is what's needed for a good integrat=
ion with the rest of the standard library. But re-reading through the libra=
ry, I see that providing all the comparison operators is what's done everyw=
here, so I'll stop complaining and simply refrain from using optional in se=
nsitive cases.<br><br>Sorry for contributing to the extra-length of this di=
scussion.<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_754_24065199.1367656227501--
.
Author: Rafael Fourquet <fourquet.d@gmail.com>
Date: Sat, 4 May 2013 16:33:19 +0530
Raw View
--089e0122f12eb49e7f04dbe26c0f
Content-Type: text/plain; charset=ISO-8859-1
FWIW, as a simple user:
I wouldn't by default expect (and rely on) tuple<T,...> to take into
account all my comparisons operators (but why not?), I can accept there has
to be compromises for handling generality.
But I perceive optional<T> as a very thin wrapper around T. I would be
1) fine if it didn't have comparisons operators, or only < and == for
storing in containers (as a convenience for the user);
2) upset that e.g. "op1 < op2" and "op1 <= op2" and "op1 > op2" worked out
of the box (for optional<T> op1, op2), to discover only later they didn't
use underlying operators defined for T (and I fail, as a non-expert, to see
a situation where I would want that). I wouldn't be less upset if someone
tells me it is for consistency with tuples etc.
In some code, I could want to replace the type T of a variable by
optional<T>. Although it should be done carefully, I may forget in some
place to change e.g. "a>=b" by "*a>=*b", and my program would then silently
become wrong. I would never do a drop-in replacement of T by tuple<T>.
The point for > not to be defined in terms of < is again obviously for
non-totally ordered sets.
I have an example where I use a class storing only an unsigned int to be
used as a binary vector. I need the following partial order: x <= y IFF x_i
<= y_i for all indices i (x_i, y_i are in {0,1}). I chose "<=" because it
is very close to the mathematical notation (which is like mathematical <=
where the "<" is curved). But: it is also very convenient to have the
usual operator< defined (in terms of < for ints, as a total order, for
map/set, or in loops). C++ permits that, nice. This type is not confusing.
If I want auto-generated operators, I prefer doing it explicitly, with e.g.
boost::totally_ordered.
--
---
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.
--089e0122f12eb49e7f04dbe26c0f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>FWIW, as a simple user:<br><br></div>I wouldn=
9;t by default expect (and rely on) <span style=3D"background:none repeat s=
croll 0% 0% yellow" class=3D"">tuple</span><T,...> to take into accou=
nt all my comparisons operators (but why not?), I can accept there has to b=
e compromises for handling generality. <br>
</div><br>But I perceive optional<T> as a very thin wrapper around T.=
I would be <br><br>1) fine if it didn't have comparisons operators, or=
only < and =3D=3D for storing in containers (as a convenience for the u=
ser);<br>
<br>2) upset that e.g. "op1=A0 < op2" and "op1 <=3D op=
2" and "op1 > op2" worked out of the box (for optional<=
;T> op1, op2), to discover only=A0 later they didn't use underlying =
operators defined for T (and I fail, as a non-expert, to see a situation wh=
ere I would want that). I wouldn't be less upset if someone tells me it=
is for consistency with <span style=3D"background:none repeat scroll 0% 0%=
yellow" class=3D"">tuples</span> etc.<br>
In some code, I could want to replace the type T of a variable by optional&=
lt;T>. Although it should be done carefully, I may forget in some place =
to change e.g. "a>=3Db" by "*a>=3D*b", and my pro=
gram would then silently become wrong. I would never do a drop-in replaceme=
nt of T by <span style=3D"background:none repeat scroll 0% 0% yellow" class=
=3D"">tuple</span><T>. <br>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The point f=
or > not to be defined in terms of < is again obviously for non-total=
ly ordered sets.<br></div><div class=3D"gmail_extra">I have an example wher=
e I use a class storing only an unsigned int to be used as a binary vector.=
I need the following partial order: x <=3D y <span style=3D"background:=
none repeat scroll 0% 0% yellow" class=3D"">IFF</span> x_i <=3D y_i for =
all indices i (x_i, y_i are in {0,1}). I chose "<=3D" because =
it is very close to the mathematical notation (which is like mathematical &=
lt;=3D where the "<" is curved).=A0 But: it is also very conve=
nient to have the usual operator< defined (in terms of < for <span st=
yle=3D"background:none repeat scroll 0% 0% yellow" class=3D"">ints</span>, =
as a total order, for map/set, or in loops). C++ permits that, nice. This t=
ype is not confusing.<br>
</div><div class=3D"gmail_extra"><br>If I want auto-generated operators, I =
prefer doing it explicitly, with e.g. boost::totally_ordered.<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 />
--089e0122f12eb49e7f04dbe26c0f--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 4 May 2013 14:15:27 +0300
Raw View
--089e0115ef60b2d84e04dbe2954b
Content-Type: text/plain; charset=ISO-8859-1
On 4 May 2013 04:41, Tony V E <tvaneerd@gmail.com> wrote:
>
>
>> No need for a template-template there.
>>
>
> So T is either optional<X> or tuple<X> (or more likely optional<int> or
> tuple<int>)? And assuming tuple<int> < i some day works? Or do I
> misunderstand?
>
Let's try a complete example:
#include <boost/optional.hpp>
#include <tuple>
#include <vector>
template <class T> void cull(std::vector<T>& vec, const T& max)
{
for (int i = vec.size()-1; i >= 0; --i) {
if (vec[i] > max)
vec.erase(vec.begin() + i);
}
}
int main()
{
std::vector<std::tuple<int>> itv{std::tuple<int>{1},
std::tuple<int>{2},std::tuple<int>{3}};
std::tuple<int> maxt{2};
std::vector<boost::optional<int>> iov{{1},{2},{3}};
boost::optional<int> maxo{2};
cull(itv, maxt);
cull(iov, maxo);
}
This works today. It doesn't work with std::optional.
Note that if you don't care about NaN and such types, then you probably
> shouldn't care about this issue at all. For any "sane" types, either
> definition of optional gives the same answer.
>
>
>
The current one certainly doesn't.
--
---
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.
--089e0115ef60b2d84e04dbe2954b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 May 2013 04:41, 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: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"><div class=3D"gmail_quote"><div class=3D"im"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div><div>No need for a template-template there.<br></div></div></div=
></div></blockquote><div><br></div></div><div>So T is either optional<X&=
gt; or tuple<X> (or more likely optional<int> or tuple<int&g=
t;)? =A0And assuming tuple<int> < i some day works? =A0Or do I mis=
understand?</div>
</div></div></div></blockquote><div><br></div><div>Let's try a complete=
example:<br><br>#include <boost/optional.hpp><br>#include <tuple&=
gt;<br>#include <vector><br><br>template <class T> void cull(st=
d::vector<T>& vec, const T& max)<br>
{<br>=A0 for (int i =3D vec.size()-1; i >=3D 0; --i) {<br>=A0=A0=A0 if (=
vec[i] > max)<br>=A0=A0=A0=A0=A0 vec.erase(vec.begin() + i);<br>=A0 }<br=
>}<br><br>int main()<br>{<br>=A0 std::vector<std::tuple<int>> i=
tv{std::tuple<int>{1},<br>
=A0=A0=A0=A0=A0 std::tuple<int>{2},std::tuple<int>{3}};<br>=A0 =
std::tuple<int> maxt{2};<br>=A0 std::vector<boost::optional<int=
>> iov{{1},{2},{3}};<br>=A0 boost::optional<int> maxo{2};<br>=
=A0 cull(itv, maxt);<br>
=A0 cull(iov, maxo);<br>}<br><br></div><div>This works today. It doesn'=
t work with std::optional. <br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Note that if you don't care about NaN and such types, then you probabl=
y shouldn't care about this issue at all. =A0For any "sane" t=
ypes, either definition of optional gives the same answer.</div>
<span class=3D""><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div><div>The current one certainly doesn't.=A0 <br></div></div><br></di=
v></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 />
--089e0115ef60b2d84e04dbe2954b--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 4 May 2013 10:32:26 -0400
Raw View
--089e013d10062adf3704dbe556cb
Content-Type: text/plain; charset=ISO-8859-1
On Sat, May 4, 2013 at 7:15 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> Let's try a complete example:
>
> #include <boost/optional.hpp>
> #include <tuple>
> #include <vector>
>
> template <class T> void cull(std::vector<T>& vec, const T& max)
> {
> for (int i = vec.size()-1; i >= 0; --i) {
> if (vec[i] > max)
> vec.erase(vec.begin() + i);
> }
> }
>
> int main()
> {
> std::vector<std::tuple<int>> itv{std::tuple<int>{1},
> std::tuple<int>{2},std::tuple<int>{3}};
> std::tuple<int> maxt{2};
> std::vector<boost::optional<int>> iov{{1},{2},{3}};
> boost::optional<int> maxo{2};
> cull(itv, maxt);
> cull(iov, maxo);
> }
>
> This works today. It doesn't work with std::optional.
>
> Note that if you don't care about NaN and such types, then you probably
>> shouldn't care about this issue at all. For any "sane" types, either
>> definition of optional gives the same answer.
>>
>>
>>
> The current one certainly doesn't.
>
Although the question of *whether* optional should define > has come up,
the conversation has mostly been about *how* it is defined. You have
proposed "NaNs be damned". If you don't care about NaNs and other
"non-normal" types, either definition that we have been discussing will
work fine. They have the same behaviour for normal types.
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.
--089e013d10062adf3704dbe556cb
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 Sat, May 4, 2013 at 7:15 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">Let's try a complete ex=
ample:<br><br>#include <boost/optional.hpp><br>#include <tuple>=
<br>
#include <vector><br><br>template <class T> void cull(std::vect=
or<T>& vec, const T& max)<br>
{<br>=A0 for (int i =3D vec.size()-1; i >=3D 0; --i) {<br>=A0=A0=A0 if (=
vec[i] > max)<br>=A0=A0=A0=A0=A0 vec.erase(vec.begin() + i);<br>=A0 }<br=
>}<br><br>int main()<br>{<br>=A0 std::vector<std::tuple<int>> i=
tv{std::tuple<int>{1},<br>
=A0=A0=A0=A0=A0 std::tuple<int>{2},std::tuple<int>{3}};<br>=A0 =
std::tuple<int> maxt{2};<br>=A0 std::vector<boost::optional<int=
>> iov{{1},{2},{3}};<br>=A0 boost::optional<int> maxo{2};<br>=
=A0 cull(itv, maxt);<br>
=A0 cull(iov, maxo);<br>}<br><br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>This works today. It doesn't work with std::optional. =
<br><br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Note that if you don't care about NaN and such types, then you probabl=
y shouldn't care about this issue at all. =A0For any "sane" t=
ypes, either definition of optional gives the same answer.</div>
<span><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div></div><div>The current one certainly doesn't.=A0 <br></div></div></=
div></div></blockquote><div><br></div><div><br></div><div>Although the ques=
tion of *whether* optional should define > has come up, the conversation=
has =A0mostly been about *how* it is defined. =A0You have proposed "N=
aNs be damned". =A0If you don't care about NaNs and other "no=
n-normal" types, either definition that we have been discussing will w=
ork fine. =A0They have the same behaviour for normal types.</div>
<div><br></div><div>Tony</div><div><br></div></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 />
--089e013d10062adf3704dbe556cb--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 4 May 2013 17:46:19 +0300
Raw View
--089e01175d63db0e7404dbe58718
Content-Type: text/plain; charset=ISO-8859-1
On 4 May 2013 17:32, Tony V E <tvaneerd@gmail.com> wrote:
>
>
> Although the question of *whether* optional should define > has come up,
> the conversation has mostly been about *how* it is defined. You have
> proposed "NaNs be damned". If you don't care about NaNs and other
> "non-normal" types, either definition that we have been discussing will
> work fine. They have the same behaviour for normal types.
>
>
>
Indeed. And failing to achieve consensus means we'll get the current lovely
situation, where
we can't even do opt1 != opt2 because people are so concerned about double
NaNs, apparently.
Not for optional<int>, not for optional<string>, not for the gazillion
types for which it would be useful,
because of the holy NaN. Pardon me for the sardonic overtone, but the
current situation has been
designed by people who have completely lost their marbles.
--
---
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.
--089e01175d63db0e7404dbe58718
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 May 2013 17:32, 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><br></div><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div>Although the question of=
*whether* optional should define > has come up, the conversation has =
=A0mostly been about *how* it is defined. =A0You have proposed "NaNs b=
e damned". =A0If you don't care about NaNs and other "non-nor=
mal" types, either definition that we have been discussing will work f=
ine. =A0They have the same behaviour for normal types.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div><div>Indeed. And failing to achieve consensus means we'll get the c=
urrent lovely situation, where<br>we can't even do opt1 !=3D opt2 becau=
se people are so concerned about double NaNs, apparently. <br>
</div></div>Not for optional<int>, not for optional<string>, no=
t for the gazillion types for which it would be useful,<br>because of the h=
oly NaN. Pardon me for the sardonic overtone, but the current situation has=
been<br>
</div><div class=3D"gmail_extra">designed by people who have completely los=
t their marbles.<br></div><div class=3D"gmail_extra"><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 />
--089e01175d63db0e7404dbe58718--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 4 May 2013 11:16:45 -0400
Raw View
--089e01184510ac00d004dbe5f4df
Content-Type: text/plain; charset=ISO-8859-1
On Sat, May 4, 2013 at 10:46 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 4 May 2013 17:32, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>> Although the question of *whether* optional should define > has come up,
>> the conversation has mostly been about *how* it is defined. You have
>> proposed "NaNs be damned". If you don't care about NaNs and other
>> "non-normal" types, either definition that we have been discussing will
>> work fine. They have the same behaviour for normal types.
>>
>>
>>
> Indeed. And failing to achieve consensus means we'll get the current
> lovely situation, where
> we can't even do opt1 != opt2 because people are so concerned about double
> NaNs, apparently.
> Not for optional<int>, not for optional<string>, not for the gazillion
> types for which it would be useful,
> because of the holy NaN. Pardon me for the sardonic overtone, but the
> current situation has been
> designed by people who have completely lost their marbles.
>
>
>
Agreed. Some people have lost their marbles.
So you are OK if we end up with either (so far discussed) definition of
optional > and optional != because
- you get the operators
- they are equivalent for normal types - the types you care about
?
:-)
Note the original proposal used both definitions (one for opt > opt, the
other for opt > T) and there *was* consensus in LEWG on which definition to
pick. So, in a sense, we don't have != because people were so concerned
about matching tuple.
--
---
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.
--089e01184510ac00d004dbe5f4df
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 Sat, May 4, 2013 at 10:46 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 dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 4 May 2013 17:3=
2, 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"><br><div><br></div><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div>Although the question of=
*whether* optional should define > has come up, the conversation has =
=A0mostly been about *how* it is defined. =A0You have proposed "NaNs b=
e damned". =A0If you don't care about NaNs and other "non-nor=
mal" types, either definition that we have been discussing will work f=
ine. =A0They have the same behaviour for normal types.</div>
<span><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div></div><div>Indeed. And failing to achieve consensus means we'll get=
the current lovely situation, where<br>we can't even do opt1 !=3D opt2=
because people are so concerned about double NaNs, apparently. <br>
</div></div>Not for optional<int>, not for optional<string>, no=
t for the gazillion types for which it would be useful,<br>because of the h=
oly NaN. Pardon me for the sardonic overtone, but the current situation has=
been<br>
</div><div class=3D"gmail_extra">designed by people who have completely los=
t their marbles.<br></div><div class=3D"gmail_extra"><br></div></div><div c=
lass=3D"HOEnZb"><div class=3D"h5">
=A0=A0</div></div></blockquote><div><br></div><div>Agreed. =A0Some people h=
ave lost their marbles.</div><div><br></div><div>So you are OK if we end up=
with either (so far discussed) definition of optional > and optional !=
=3D because=A0</div>
<div>- you get the operators</div><div>- they are equivalent for normal typ=
es - the types you care about</div><div>?</div><div>:-)</div><div><br></div=
><div>Note the original proposal used both definitions (one for opt > op=
t, the other for opt > T) and there *was* consensus in LEWG on which def=
inition to pick.=A0 So, in a sense, we don't have !=3D because people w=
ere so concerned about matching tuple.</div>
<div><br></div><div>=A0</div><div><br></div><div><br></div><div><br></div><=
div><br></div></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 />
--089e01184510ac00d004dbe5f4df--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 4 May 2013 18:51:00 +0300
Raw View
--089e01175d632701f204dbe66f8e
Content-Type: text/plain; charset=ISO-8859-1
On 4 May 2013 18:16, Tony V E <tvaneerd@gmail.com> wrote:
>
> Agreed. Some people have lost their marbles.
>
> So you are OK if we end up with either (so far discussed) definition of
> optional > and optional != because
> - you get the operators
> - they are equivalent for normal types - the types you care about
> ?
> :-)
>
>
Sounds reasonable to me. I may be able to live with inconsistencies with
tuple and such, but that's not my preference.
For the sake of my health, happiness and sanity, I should stay far away
from anything
above clause 16. And after looking at what's in clause 16, make that
anything above clause 15.
--
---
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.
--089e01175d632701f204dbe66f8e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 May 2013 18:16, 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"><div class=3D"gmail_quote"><div>Agreed. =A0Some people have lost their =
marbles.</div>
<div><br></div><div>So you are OK if we end up with either (so far discusse=
d) definition of optional > and optional !=3D because=A0</div>
<div>- you get the operators</div><div>- they are equivalent for normal typ=
es - the types you care about</div><div>?</div><div>:-)</div><div><br></div=
></div></div></div></blockquote><div><br></div><div>Sounds reasonable to me=
.. I may be able to live with inconsistencies with tuple and such, but that&=
#39;s not my preference.<br>
For the sake of my health, happiness and sanity, I should stay far away fro=
m anything<br></div><div>above clause 16. And after looking at what's i=
n clause 16, make that anything above clause 15.<br></div></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 />
--089e01175d632701f204dbe66f8e--
.
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Sun, 5 May 2013 23:40:07 -0500
Raw View
--001a11c24b7c928a5a04dc054bf2
Content-Type: text/plain; charset=ISO-8859-1
On May 3, 2013 8:17 PM, "Tony V E" <tvaneerd@gmail.com> wrote:
>
>
>
>
> On Fri, May 3, 2013 at 7:52 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>>
>>
>>
>>
>> On 4 May 2013 01:09, Marc <marc.glisse@gmail.com> wrote:
>>>
>>>
>>> But mostly, the rational for providing operator< seems to be so we can
put it in an std::set, but that's already handled by specializing std::less
(which I agree should have had a better name), so in my opinion
std::optional should simply not provide operator< at all. That seems the
safest thing.
>>>
>>> --
>>>
>>
>> I have no trouble with the name of std::less. What I wrote before was
that I'd prefer not using std::less for
>> ordering keys of associative container. ;)
>>
>
> That I agree with. I always felt map should use something like
std::map_less<T>, for example. Which would default to std::less<T>.
(Possibly via std::container_less<T> in the middle as well?)
>
It ought to be default_strict_weak_order<T> to avoid any implication that
it's meaningful for any other purpose.
> I actually don't think that would be a breaking change.
>
> 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.
>
>
--
---
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.
--001a11c24b7c928a5a04dc054bf2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On May 3, 2013 8:17 PM, "Tony V E" <<a href=3D"=
mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Fri, May 3, 2013 at 7:52 PM, Ville Voutilainen <<a href=3D"mailt=
o:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<b=
r>
>><br>
>><br>
>><br>
>><br>
>> On 4 May 2013 01:09, Marc <<a href=3D"mailto:marc.glisse@gmail.=
com">marc.glisse@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>> But mostly, the rational for providing operator< seems to b=
e so we can put it in an std::set, but that's already handled by specia=
lizing std::less (which I agree should have had a better name), so in my op=
inion std::optional should simply not provide operator< at all. That see=
ms the safest thing.<br>
>>><br>
>>> --<br>
>>><br>
>><br>
>> I have no trouble with the name of std::less. What I wrote before =
was that I'd prefer not using std::less for<br>
>> ordering keys of associative container. ;) <br>
>><br>
><br>
> That I agree with. =A0I always felt map should use something like std:=
:map_less<T>, for example. =A0Which would default to std::less<T&g=
t;. =A0(Possibly via std::container_less<T> in the middle as well?)<b=
r>
> =A0</p>
<p dir=3D"ltr">It ought to be default_strict_weak_order<T> to avoid a=
ny implication that it's meaningful for any other purpose. </p>
<p dir=3D"ltr">> I actually don't think that would be a breaking cha=
nge.<br>
><br>
> Tony<br>
><br>
> -- <br>
> =A0<br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/st=
d-proposals/?hl=3Den</a>.<br>
> =A0<br>
> =A0<br>
</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 />
--001a11c24b7c928a5a04dc054bf2--
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 7 May 2013 15:14:37 -0700
Raw View
On 2 May 2013, Nevin Liber <nevin@eviloverlord.com> wrote:
> operator< should be implemented in terms of operator< of the
> underlying component(s).
> operator== should be implemented in terms of operator== of the
> underlying component(s).
> std::less should be implemented in terms of std::less of the
> underlying component(s).
> std::equal_to should be implemented in terms of std::equal_to
> of the underlying component(s)
>
> operator>, operator<=, operator>= should be written in terms of
> operator<.
> operator!= should be written in terms of operator==.
> std::greater, std::less_equal, std::greater_equal should be
> written in terms of std::less.
> std::not_equal_to should be written in terms of std::equal_to
On 3 May 2013, Nevin Liber <nevin@eviloverlord.com> wrote:
> The other, simpler possibility is to not specialize the arithmetic
> operations:
>
> operator< should be implemented in terms of std::less of the
> underlying component(s).
> operator== should be implemented in terms of std::equal_to of the
> underlying component(s).
> operator>, operator<=, operator>= should be written in terms of
> operator<
> operator!= should be written in terms of operator==
>
> This may have surprising results for those who, for instance, think
> operator< and std::less should do different things (the only place
> in the standard which does this as far as I know is for pointers,
> and that is only because C doesn't give them a total ordering),
> but I see that being as insane as NaN.
There are two orderings that we need to worry about, value ordering
and representation ordering.
You call NaNs insane, but they are insane only because they cannot
participate in a total order with other floating-point values.
As such, you can have (a<b||a==b||a>b) be false. In this realm,
defining operator> in terms of operator< is just plain wrong.
On the other hand, for purposes of associative lookup, we can impose
an arbitrary total order on representations because they are strings
of bits. Defining std::greater in terms of std::less is fine.
On 3 May 2013, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> Agreed, the pointer situation is unfortunate, but it seems likely
> that other types will have this difference between op< and less.
Likewise, size 30/34 trousers are neither smaller nor larger
than size 34/30 trousers. Nor are they equal. But we can still
arbitrarily use the first number as more significant to association.
> A further 0.02: I find it unfortunate that the operator-functors
> are ever anything but alternative ways to perform their underlying
> operators. It's pragmatically important that putting types into
> sets and maps is easy, but making less and op< different is, from a
> pedantic standpoint, a gross hack. It would be much cleaner to not
> use std::less by default in maps and sets, but use some AssocComp
> that invokes std::less by default, and allow specialization of
> that AssocComp for funny types. I'm not sure whether that cleaner
> solution is attainable, that particular cat may well be so far
> out of the bag that wooing it back isn't practical.
The naming is unfortunate, but the distinction between value ordering
and representation ordering is fundamental and deserves explicit
recognition in the language. Right now, we have the convention that
value ordering is spelled operator< and representation ordering is
spelled std::less.
The confusion arises because the when the value ordering is total,
you can use it to implement std::less without appealing to the
representation.
BTW, the distinction between value and representation ordering is
appears in the atomic compare exchange functions, which are defined
in terms of memcmp, i.e. the representation ordering. One must be
careful when operating on types that have multiple representations
for each value.
--
Lawrence Crowl
--
---
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: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 7 May 2013 19:29:13 -0300
Raw View
--001a11c2a88435fafe04dc285b4a
Content-Type: text/plain; charset=ISO-8859-1
On Tue, May 7, 2013 at 7:14 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>
> The naming is unfortunate, but the distinction between value ordering
> and representation ordering is fundamental and deserves explicit
> recognition in the language. Right now, we have the convention that
> value ordering is spelled operator< and representation ordering is
> spelled std::less.
>
> Well, I was not aware that this was, or is, the intention, but I do agree
with the distinction between the two types of orderings, specially in the
case where there is no value ordering at all, but there (always) is some
valid representation ordering for the sake of lookups. I often resort to
constructing a (large enough) integer out of the bits of all fields just
for that.
I also very much like the idea of using < and std::less for one and the
other.
I also agree that, for the sake of associative lookup, defininng
std::greater in terms of std::less is exactly right, regardless of how
operator > would be defined (so I'm saying I've got it wrong all along
thinking that > in terms of < is a good idea because that's how the std
functors work)
Having said all that, I now feel that the appropriate resolution for
std::optional<> is to implement all operators in terms of the underlying
type. The rest of the library should IMO do the same, but if it can't be
changed, let's at least avoid perpetuating the mistake.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--001a11c2a88435fafe04dc285b4a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 7, 2013 at 7:14 PM, Lawrence Crowl <span dir=3D"ltr"><<a href=3D=
"mailto:crowl@googlers.com" target=3D"_blank">crowl@googlers.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>The naming is unfortunate, but the disti=
nction between value ordering<br>
and representation ordering is fundamental and deserves explicit<br>
recognition in the language. =A0Right now, we have the convention that<br>
value ordering is spelled operator< and representation ordering is<br>
spelled std::less.<br>
<br></blockquote><div>Well, I was not aware that this was, or is, the inten=
tion, but I do agree with the distinction between the two types of ordering=
s, specially in the case where there is no value ordering at all, but there=
(always) is some valid representation ordering for the sake of lookups. I =
often resort to constructing a (large enough) integer out of the bits of al=
l fields just for that.<br>
<br></div><div>I also very much like the idea of using < and std::less f=
or one and the other.<br><br></div><div>I also agree that, for the sake of =
associative lookup, defininng std::greater in terms of std::less is exactly=
right, regardless of how operator > would be defined (so I'm saying=
I've got it wrong all along thinking that > in terms of < is a g=
ood idea because that's how the std functors work)<br>
</div><div><br></div><div>Having said all that, I now feel that the appropr=
iate resolution for std::optional<> is to implement all operators in =
terms of the underlying type. The rest of the library should IMO do the sam=
e, but if it can't be changed, let's at least avoid perpetuating th=
e mistake.<br>
</div><div><br><br></div><div>Best</div></div><br><br clear=3D"all"><br>-- =
<br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://w=
ww.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 />
--001a11c2a88435fafe04dc285b4a--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 15 May 2013 11:48:32 +0300
Raw View
--089e01229c308d9e6904dcbdd018
Content-Type: text/plain; charset=ISO-8859-1
On 8 May 2013 01:29, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Tue, May 7, 2013 at 7:14 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>
>>
>> The naming is unfortunate, but the distinction between value ordering
>> and representation ordering is fundamental and deserves explicit
>> recognition in the language. Right now, we have the convention that
>> value ordering is spelled operator< and representation ordering is
>> spelled std::less.
>>
>> Well, I was not aware that this was, or is, the intention, but I do agree
> with the distinction between the two types of orderings, specially in the
> case where there is no value ordering at all, but there (always) is some
> valid representation ordering for the sake of lookups. I often resort to
> constructing a (large enough) integer out of the bits of all fields just
> for that.
>
> I also very much like the idea of using < and std::less for one and the
> other.
>
> I also agree that, for the sake of associative lookup, defininng
> std::greater in terms of std::less is exactly right, regardless of how
> operator > would be defined (so I'm saying I've got it wrong all along
> thinking that > in terms of < is a good idea because that's how the std
> functors work)
>
> Having said all that, I now feel that the appropriate resolution for
> std::optional<> is to implement all operators in terms of the underlying
> type. The rest of the library should IMO do the same, but if it can't be
> changed, let's at least avoid perpetuating the mistake.
>
>
>
I did a little bit of further homework on the matter. boost::tuple does NOT
synthesize the comparison operators,
but rather calls the operator of the underlying type. The existing practice
isn't consistent. ;)
This needs at least an overview paper. I'd be willing to entertain the idea
to propose making all relational
operators, including tuple and containers, to not synthesize. I suppose the
fallback plans are synthesize-for-all
and deliberately-inconsistent, not necessarily in any preference order.
In addition to that, tuples and containers would seemingly need std::less
specializations. That's actually somewhat separate.
Fernando, Tony, would you be interested in coauthoring?
--
---
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.
--089e01229c308d9e6904dcbdd018
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 8 May 2013 01:29, 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 Tue, May 7, 2013 at 7:14 PM=
, Lawrence Crowl <span dir=3D"ltr"><<a href=3D"mailto:crowl@googlers.com=
" target=3D"_blank">crowl@googlers.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>The naming is unfortunate, but the disti=
nction between value ordering<br>
and representation ordering is fundamental and deserves explicit<br>
recognition in the language. =A0Right now, we have the convention that<br>
value ordering is spelled operator< and representation ordering is<br>
spelled std::less.<br>
<br></blockquote></div><div>Well, I was not aware that this was, or is, the=
intention, but I do agree with the distinction between the two types of or=
derings, specially in the case where there is no value ordering at all, but=
there (always) is some valid representation ordering for the sake of looku=
ps. I often resort to constructing a (large enough) integer out of the bits=
of all fields just for that.<br>
<br></div><div>I also very much like the idea of using < and std::less f=
or one and the other.<br><br></div><div>I also agree that, for the sake of =
associative lookup, defininng std::greater in terms of std::less is exactly=
right, regardless of how operator > would be defined (so I'm saying=
I've got it wrong all along thinking that > in terms of < is a g=
ood idea because that's how the std functors work)<br>
</div><div><br></div><div>Having said all that, I now feel that the appropr=
iate resolution for std::optional<> is to implement all operators in =
terms of the underlying type. The rest of the library should IMO do the sam=
e, but if it can't be changed, let's at least avoid perpetuating th=
e mistake.<br>
</div><div><br><br></div></div></div></div></blockquote><div><br></div><div=
>I did a little bit of further homework on the matter. boost::tuple does NO=
T synthesize the comparison operators,<br>but rather calls the operator of =
the underlying type. The existing practice isn't consistent. ;)<br>
<br></div><div>This needs at least an overview paper. I'd be willing to=
entertain the idea to propose making all relational<br>operators, includin=
g tuple and containers, to not synthesize. I suppose the fallback plans are=
synthesize-for-all<br>
and deliberately-inconsistent, not necessarily in any preference order.<br>=
<br></div></div>In addition to that, tuples and containers would seemingly =
need std::less specializations. That's actually somewhat separate.<br>
<br></div><div class=3D"gmail_extra">Fernando, Tony, would you be intereste=
d in coauthoring?<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 />
--089e01229c308d9e6904dcbdd018--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Wed, 15 May 2013 09:20:32 -0300
Raw View
--047d7b3441681edd2004dcc0c93b
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 15, 2013 at 5:48 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 8 May 2013 01:29, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> On Tue, May 7, 2013 at 7:14 PM, Lawrence Crowl <crowl@googlers.com>wrote:
>>
>>>
>>> The naming is unfortunate, but the distinction between value ordering
>>> and representation ordering is fundamental and deserves explicit
>>> recognition in the language. Right now, we have the convention that
>>> value ordering is spelled operator< and representation ordering is
>>> spelled std::less.
>>>
>>> Well, I was not aware that this was, or is, the intention, but I do
>> agree with the distinction between the two types of orderings, specially in
>> the case where there is no value ordering at all, but there (always) is
>> some valid representation ordering for the sake of lookups. I often resort
>> to constructing a (large enough) integer out of the bits of all fields just
>> for that.
>>
>> I also very much like the idea of using < and std::less for one and the
>> other.
>>
>> I also agree that, for the sake of associative lookup, defininng
>> std::greater in terms of std::less is exactly right, regardless of how
>> operator > would be defined (so I'm saying I've got it wrong all along
>> thinking that > in terms of < is a good idea because that's how the std
>> functors work)
>>
>> Having said all that, I now feel that the appropriate resolution for
>> std::optional<> is to implement all operators in terms of the underlying
>> type. The rest of the library should IMO do the same, but if it can't be
>> changed, let's at least avoid perpetuating the mistake.
>>
>>
>>
> I did a little bit of further homework on the matter. boost::tuple does
> NOT synthesize the comparison operators,
> but rather calls the operator of the underlying type. The existing
> practice isn't consistent. ;)
>
> This needs at least an overview paper. I'd be willing to entertain the
> idea to propose making all relational
> operators, including tuple and containers, to not synthesize. I suppose
> the fallback plans are synthesize-for-all
> and deliberately-inconsistent, not necessarily in any preference order.
>
> In addition to that, tuples and containers would seemingly need std::less
> specializations. That's actually somewhat separate.
>
> Fernando, Tony, would you be interested in coauthoring?
>
Now that I am much more convinced that the right approach is to not
synthesize (consistently across the whole library), I would definitely like
to coauthor such a paper!
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7b3441681edd2004dcc0c93b
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 W=
ed, May 15, 2013 at 5:48 AM, 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><div class=3D"h5">On 8 May 2013=
01:29, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.=
cacciola@gmail.com" target=3D"_blank">fernando.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>On Tue, May 7, 2013 at 7:14 PM, Lawrence Cr=
owl <span dir=3D"ltr"><<a href=3D"mailto:crowl@googlers.com" target=3D"_=
blank">crowl@googlers.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>The naming is unfortunate, but the disti=
nction between value ordering<br>
and representation ordering is fundamental and deserves explicit<br>
recognition in the language. =A0Right now, we have the convention that<br>
value ordering is spelled operator< and representation ordering is<br>
spelled std::less.<br>
<br></blockquote></div><div>Well, I was not aware that this was, or is, the=
intention, but I do agree with the distinction between the two types of or=
derings, specially in the case where there is no value ordering at all, but=
there (always) is some valid representation ordering for the sake of looku=
ps. I often resort to constructing a (large enough) integer out of the bits=
of all fields just for that.<br>
<br></div><div>I also very much like the idea of using < and std::less f=
or one and the other.<br><br></div><div>I also agree that, for the sake of =
associative lookup, defininng std::greater in terms of std::less is exactly=
right, regardless of how operator > would be defined (so I'm saying=
I've got it wrong all along thinking that > in terms of < is a g=
ood idea because that's how the std functors work)<br>
</div><div><br></div><div>Having said all that, I now feel that the appropr=
iate resolution for std::optional<> is to implement all operators in =
terms of the underlying type. The rest of the library should IMO do the sam=
e, but if it can't be changed, let's at least avoid perpetuating th=
e mistake.<br>
</div><div><br><br></div></div></div></div></blockquote><div><br></div></di=
v></div><div>I did a little bit of further homework on the matter. boost::t=
uple does NOT synthesize the comparison operators,<br>but rather calls the =
operator of the underlying type. The existing practice isn't consistent=
.. ;)<br>
<br></div><div>This needs at least an overview paper. I'd be willing to=
entertain the idea to propose making all relational<br>operators, includin=
g tuple and containers, to not synthesize. I suppose the fallback plans are=
synthesize-for-all<br>
and deliberately-inconsistent, not necessarily in any preference order.<br>=
<br></div></div>In addition to that, tuples and containers would seemingly =
need std::less specializations. That's actually somewhat separate.<br>
<br></div><div class=3D"gmail_extra">Fernando, Tony, would you be intereste=
d in coauthoring?<br></div></div></blockquote><div><br></div><div>Now that =
I am much more convinced that the right approach is to not synthesize (cons=
istently across the whole library), I would definitely like to coauthor suc=
h a paper!<br>
<br><br></div><div>Best</div></div><br clear=3D"all"><br>-- <br>Fernando Ca=
cciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-cons=
ulting.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 />
--047d7b3441681edd2004dcc0c93b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 15 May 2013 15:25:19 +0300
Raw View
--089e0129526acee28404dcc0d743
Content-Type: text/plain; charset=ISO-8859-1
On 15 May 2013 15:20, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> I did a little bit of further homework on the matter. boost::tuple does
> NOT synthesize the comparison operators,
>
>> but rather calls the operator of the underlying type. The existing
>> practice isn't consistent. ;)
>>
>> This needs at least an overview paper. I'd be willing to entertain the
>> idea to propose making all relational
>> operators, including tuple and containers, to not synthesize. I suppose
>> the fallback plans are synthesize-for-all
>> and deliberately-inconsistent, not necessarily in any preference order.
>>
>> In addition to that, tuples and containers would seemingly need std::less
>> specializations. That's actually somewhat separate.
>>
>> Fernando, Tony, would you be interested in coauthoring?
>>
>
> Now that I am much more convinced that the right approach is to not
> synthesize (consistently across the whole library), I would definitely like
> to coauthor such a paper!
>
>
>
For you, and Tony too, I want to include the "fallback" options in the
paper. According to what Nevin said,
people may already rely on the existing synthesizing, so the outcome is not
easy to predict. At a minimum,
I'll live with whatever the decision will be, at least we have voiced the
concerns with the paper.
--
---
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.
--089e0129526acee28404dcc0d743
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 15 May 2013 15:20, Fernando Cacciola <span dir=3D"ltr"><<a hr=
ef=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.caccio=
la@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">I did a little bit of fur=
ther homework on the matter. boost::tuple does NOT synthesize the compariso=
n operators,<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>but rather calls the operator of the underl=
ying type. The existing practice isn't consistent. ;)<br>
<br></div><div>This needs at least an overview paper. I'd be willing to=
entertain the idea to propose making all relational<br>operators, includin=
g tuple and containers, to not synthesize. I suppose the fallback plans are=
synthesize-for-all<br>
and deliberately-inconsistent, not necessarily in any preference order.<br>=
<br></div></div>In addition to that, tuples and containers would seemingly =
need std::less specializations. That's actually somewhat separate.<br>
<br></div><div class=3D"gmail_extra">Fernando, Tony, would you be intereste=
d in coauthoring?<br></div></div></blockquote><div><br></div></div></div><d=
iv>Now that I am much more convinced that the right approach is to not synt=
hesize (consistently across the whole library), I would definitely like to =
coauthor such a paper!<br>
<br><br></div></div></div></div></blockquote><div><br></div><div>For you, a=
nd Tony too, I want to include the "fallback" options in the pape=
r. According to what Nevin said,<br></div><div>people may already rely on t=
he existing synthesizing, so the outcome is not easy to predict. At a minim=
um,<br>
</div><div>I'll live with whatever the decision will be, at least we ha=
ve voiced the concerns with the paper.<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 />
--089e0129526acee28404dcc0d743--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Wed, 15 May 2013 09:30:37 -0300
Raw View
--089e012281b4270de104dcc0eddb
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 15, 2013 at 9:25 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 15 May 2013 15:20, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> I did a little bit of further homework on the matter. boost::tuple does
>> NOT synthesize the comparison operators,
>>
>>> but rather calls the operator of the underlying type. The existing
>>> practice isn't consistent. ;)
>>>
>>> This needs at least an overview paper. I'd be willing to entertain the
>>> idea to propose making all relational
>>> operators, including tuple and containers, to not synthesize. I suppose
>>> the fallback plans are synthesize-for-all
>>> and deliberately-inconsistent, not necessarily in any preference order.
>>>
>>> In addition to that, tuples and containers would seemingly need
>>> std::less specializations. That's actually somewhat separate.
>>>
>>> Fernando, Tony, would you be interested in coauthoring?
>>>
>>
>> Now that I am much more convinced that the right approach is to not
>> synthesize (consistently across the whole library), I would definitely like
>> to coauthor such a paper!
>>
>>
>>
> For you, and Tony too, I want to include the "fallback" options in the
> paper. According to what Nevin said,
> people may already rely on the existing synthesizing, so the outcome is
> not easy to predict. At a minimum,
> I'll live with whatever the decision will be, at least we have voiced the
> concerns with the paper.
>
> Agreed.
>
>
--
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.
--089e012281b4270de104dcc0eddb
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 W=
ed, May 15, 2013 at 9:25 AM, 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 15 May 2013 15:=
20, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacc=
iola@gmail.com" target=3D"_blank">fernando.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><div>I did a little bit of further homework=
on the matter. boost::tuple does NOT synthesize the comparison operators,<=
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>but rather calls the operator of the underl=
ying type. The existing practice isn't consistent. ;)<br>
<br></div><div>This needs at least an overview paper. I'd be willing to=
entertain the idea to propose making all relational<br>operators, includin=
g tuple and containers, to not synthesize. I suppose the fallback plans are=
synthesize-for-all<br>
and deliberately-inconsistent, not necessarily in any preference order.<br>=
<br></div></div>In addition to that, tuples and containers would seemingly =
need std::less specializations. That's actually somewhat separate.<br>
<br></div><div class=3D"gmail_extra">Fernando, Tony, would you be intereste=
d in coauthoring?<br></div></div></blockquote><div><br></div></div></div><d=
iv>Now that I am much more convinced that the right approach is to not synt=
hesize (consistently across the whole library), I would definitely like to =
coauthor such a paper!<br>
<br><br></div></div></div></div></blockquote><div><br></div></div><div>For =
you, and Tony too, I want to include the "fallback" options in th=
e paper. According to what Nevin said,<br></div><div>people may already rel=
y on the existing synthesizing, so the outcome is not easy to predict. At a=
minimum,<br>
</div><div>I'll live with whatever the decision will be, at least we ha=
ve voiced the concerns with the paper.<br></div></div><br></div></div></blo=
ckquote><div>Agreed. <br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"></div></div><div class=3D"HOEnZ=
b"><div class=3D"h5">
<p></p><br clear=3D"all"></div></div></blockquote></div><br>-- <br>Fernando=
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-c=
onsulting.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 />
--089e012281b4270de104dcc0eddb--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 15 May 2013 09:58:39 -0400
Raw View
--047d7b3432b89ea7e904dcc22553
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 15, 2013 at 8:30 AM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:
> On Wed, May 15, 2013 at 9:25 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>>
>>
>> On 15 May 2013 15:20, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>>
>>> I did a little bit of further homework on the matter. boost::tuple does
>>> NOT synthesize the comparison operators,
>>>
>>>> but rather calls the operator of the underlying type. The existing
>>>> practice isn't consistent. ;)
>>>>
>>>> This needs at least an overview paper. I'd be willing to entertain the
>>>> idea to propose making all relational
>>>> operators, including tuple and containers, to not synthesize. I suppose
>>>> the fallback plans are synthesize-for-all
>>>> and deliberately-inconsistent, not necessarily in any preference order.
>>>>
>>>> In addition to that, tuples and containers would seemingly need
>>>> std::less specializations. That's actually somewhat separate.
>>>>
>>>> Fernando, Tony, would you be interested in coauthoring?
>>>>
>>>
>>> Now that I am much more convinced that the right approach is to not
>>> synthesize (consistently across the whole library), I would definitely like
>>> to coauthor such a paper!
>>>
>>>
>>>
>> For you, and Tony too, I want to include the "fallback" options in the
>> paper. According to what Nevin said,
>> people may already rely on the existing synthesizing, so the outcome is
>> not easy to predict. At a minimum,
>> I'll live with whatever the decision will be, at least we have voiced the
>> concerns with the paper.
>>
>> Agreed.
>
>>
Since I was planning on writing a paper or two about this anyhow, I will
definitely help.
I think the best fallback plan is that in the case where T *does not have*
an operator>, the tuple will still generate one, (if T *does* have > that
it is used). So any existing code that wouldn't compile without
synthesizing will still work. (If T had inconsistent operators, they get a
behaviour change due to no longer synthesizing.)
But I'd like to consider that a (partial) backwards compatibility hack, and
not have optional support that behaviour. ie I'd rather have optional >
fail to compile if you don't have the underlying operator.
I'd prefer if as much as possible each issue was a separate paper.
Optional operator> separate from optional std::less. tuple/pair separate
from 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.
--047d7b3432b89ea7e904dcc22553
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 15, 2013 at 8:30 AM, Fernando Cacciola <span dir=3D"ltr=
"><<a href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fern=
ando.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">On Wed, May 15, 2013 at 9:25 A=
M, 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 class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div>On 15 May 2013 15:20, Fernando =
Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmail.co=
m" target=3D"_blank">fernando.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><div>I did a little bit of further homework=
on the matter. boost::tuple does NOT synthesize the comparison operators,<=
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>but rather calls the operator of the underl=
ying type. The existing practice isn't consistent. ;)<br>
<br></div><div>This needs at least an overview paper. I'd be willing to=
entertain the idea to propose making all relational<br>operators, includin=
g tuple and containers, to not synthesize. I suppose the fallback plans are=
synthesize-for-all<br>
and deliberately-inconsistent, not necessarily in any preference order.<br>=
<br></div></div>In addition to that, tuples and containers would seemingly =
need std::less specializations. That's actually somewhat separate.<br>
<br></div><div class=3D"gmail_extra">Fernando, Tony, would you be intereste=
d in coauthoring?<br></div></div></blockquote><div><br></div></div></div><d=
iv>Now that I am much more convinced that the right approach is to not synt=
hesize (consistently across the whole library), I would definitely like to =
coauthor such a paper!<br>
<br><br></div></div></div></div></blockquote><div><br></div></div><div>For =
you, and Tony too, I want to include the "fallback" options in th=
e paper. According to what Nevin said,<br></div><div>people may already rel=
y on the existing synthesizing, so the outcome is not easy to predict. At a=
minimum,<br>
</div><div>I'll live with whatever the decision will be, at least we ha=
ve voiced the concerns with the paper.<br></div></div><br></div></div></blo=
ckquote></div><div>Agreed. <br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
</div></div></blockquote></div></div></div></blockquote></div><br></div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Since I was pl=
anning on writing a paper or two about this anyhow, I will definitely help.=
</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I think the=
best fallback plan is that in the case where T *does not have* an operator=
>, the tuple will still generate one, (if T *does* have > that it is =
used). So any existing code that wouldn't compile without synthesizing =
will still work. (If T had inconsistent operators, they get a behaviour cha=
nge due to no longer synthesizing.)</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">But I'd=
like to consider that a (partial) backwards compatibility hack, and not ha=
ve optional support that behaviour. ie I'd rather have optional > fa=
il to compile if you don't have the underlying operator.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I'd pre=
fer if as much as possible each issue was a separate paper. =A0Optional ope=
rator> separate from optional std::less. =A0tuple/pair separate from opt=
ional.<br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Tony<=
/div><div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<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 />
--047d7b3432b89ea7e904dcc22553--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Wed, 15 May 2013 11:04:36 -0300
Raw View
--047d7b343baa44fbdb04dcc23d5f
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 15, 2013 at 10:58 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>
>
> On Wed, May 15, 2013 at 8:30 AM, Fernando Cacciola <
> fernando.cacciola@gmail.com> wrote:
>
>> On Wed, May 15, 2013 at 9:25 AM, Ville Voutilainen <
>> ville.voutilainen@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On 15 May 2013 15:20, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>>>
>>>> I did a little bit of further homework on the matter. boost::tuple does
>>>> NOT synthesize the comparison operators,
>>>>
>>>>> but rather calls the operator of the underlying type. The existing
>>>>> practice isn't consistent. ;)
>>>>>
>>>>> This needs at least an overview paper. I'd be willing to entertain the
>>>>> idea to propose making all relational
>>>>> operators, including tuple and containers, to not synthesize. I
>>>>> suppose the fallback plans are synthesize-for-all
>>>>> and deliberately-inconsistent, not necessarily in any preference order.
>>>>>
>>>>> In addition to that, tuples and containers would seemingly need
>>>>> std::less specializations. That's actually somewhat separate.
>>>>>
>>>>> Fernando, Tony, would you be interested in coauthoring?
>>>>>
>>>>
>>>> Now that I am much more convinced that the right approach is to not
>>>> synthesize (consistently across the whole library), I would definitely like
>>>> to coauthor such a paper!
>>>>
>>>>
>>>>
>>> For you, and Tony too, I want to include the "fallback" options in the
>>> paper. According to what Nevin said,
>>> people may already rely on the existing synthesizing, so the outcome is
>>> not easy to predict. At a minimum,
>>> I'll live with whatever the decision will be, at least we have voiced
>>> the concerns with the paper.
>>>
>>> Agreed.
>>
>>>
>
> Since I was planning on writing a paper or two about this anyhow, I will
> definitely help.
>
> I think the best fallback plan is that in the case where T *does not have*
> an operator>, the tuple will still generate one, (if T *does* have > that
> it is used). So any existing code that wouldn't compile without
> synthesizing will still work. (If T had inconsistent operators, they get a
> behaviour change due to no longer synthesizing.)
>
> Makes sense.
> But I'd like to consider that a (partial) backwards compatibility hack,
> and not have optional support that behaviour. ie I'd rather have optional >
> fail to compile if you don't have the underlying operator.
>
OK. I think this is a good idea in the specific case of optional. I do
share the view of others that optional is something of a T more than the
other wrappers and containers.
>
> I'd prefer if as much as possible each issue was a separate paper.
> Optional operator> separate from optional std::less. tuple/pair separate
> from optional.
>
Agreed.
--
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.
--047d7b343baa44fbdb04dcc23d5f
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 W=
ed, May 15, 2013 at 10:58 AM, Tony V E <span dir=3D"ltr"><<a href=3D"mai=
lto: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><div class=3D"h5"><br>=
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, May 1=
5, 2013 at 8:30 AM, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mail=
to:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.c=
om</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>On Wed, May 15, 2013 at 9:25 AM, Ville Vout=
ilainen <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>On 15 May 2013 15:20, Fernando =
Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmail.co=
m" target=3D"_blank">fernando.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><div>I did a little bit of further homework=
on the matter. boost::tuple does NOT synthesize the comparison operators,<=
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>but rather calls the operator of the underl=
ying type. The existing practice isn't consistent. ;)<br>
<br></div><div>This needs at least an overview paper. I'd be willing to=
entertain the idea to propose making all relational<br>operators, includin=
g tuple and containers, to not synthesize. I suppose the fallback plans are=
synthesize-for-all<br>
and deliberately-inconsistent, not necessarily in any preference order.<br>=
<br></div></div>In addition to that, tuples and containers would seemingly =
need std::less specializations. That's actually somewhat separate.<br>
<br></div><div class=3D"gmail_extra">Fernando, Tony, would you be intereste=
d in coauthoring?<br></div></div></blockquote><div><br></div></div></div><d=
iv>Now that I am much more convinced that the right approach is to not synt=
hesize (consistently across the whole library), I would definitely like to =
coauthor such a paper!<br>
<br><br></div></div></div></div></blockquote><div><br></div></div><div>For =
you, and Tony too, I want to include the "fallback" options in th=
e paper. According to what Nevin said,<br></div><div>people may already rel=
y on the existing synthesizing, so the outcome is not easy to predict. At a=
minimum,<br>
</div><div>I'll live with whatever the decision will be, at least we ha=
ve voiced the concerns with the paper.<br></div></div><br></div></div></blo=
ckquote></div><div>Agreed. <br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
</div></div></blockquote></div></div></div></blockquote></div><br></div><di=
v class=3D"gmail_extra"><br></div></div></div><div class=3D"gmail_extra">Si=
nce I was planning on writing a paper or two about this anyhow, I will defi=
nitely help.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I think the=
best fallback plan is that in the case where T *does not have* an operator=
>, the tuple will still generate one, (if T *does* have > that it is =
used). So any existing code that wouldn't compile without synthesizing =
will still work. (If T had inconsistent operators, they get a behaviour cha=
nge due to no longer synthesizing.)</div>
<div class=3D"gmail_extra"><br></div></div></blockquote><div>Makes sense.<b=
r>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra">
</div><div class=3D"gmail_extra">But I'd like to consider that a (parti=
al) backwards compatibility hack, and not have optional support that behavi=
our. ie I'd rather have optional > fail to compile if you don't =
have the underlying operator.</div>
</div></blockquote><div><br></div><div>OK. I think this is a good idea in t=
he specific case of optional. I do share the view of others that optional i=
s something of a T more than the other wrappers and containers. <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"><br></div><div class=3D"gmail_extra">I'd pre=
fer if as much as possible each issue was a separate paper. =A0Optional ope=
rator> separate from optional std::less. =A0tuple/pair separate from opt=
ional.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></div></div></blockquote><div><br></div><div>Agreed. <br><br>=
</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>
<p></p>
-- <br />
<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 />
--047d7b343baa44fbdb04dcc23d5f--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 15 May 2013 17:20:11 +0300
Raw View
--047d7b3a831c9cb54404dcc272d9
Content-Type: text/plain; charset=ISO-8859-1
On 15 May 2013 17:04, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>
> I'd prefer if as much as possible each issue was a separate paper.
>> Optional operator> separate from optional std::less. tuple/pair separate
>> from optional.
>>
>
> Agreed.
>
>
My preference would be to separate out std::less specializations (tuple<T*>
doesn't work as a key for
an ordered associative container), but keep the other part, the discussion
about relational operators
themselves, in a single paper. The pros/cons of what we do with optional's
operator> are strongly
related to tuple/boost::tuple/containers, so I don't think we should split
these into separate tuple
and optional papers.
--
---
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.
--047d7b3a831c9cb54404dcc272d9
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 15 May 2013 17:04, Fernando Cacciola <span dir=3D"ltr"><<a hr=
ef=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.caccio=
la@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"><br><div class=3D"im"><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">I'd prefer if as much as po=
ssible each issue was a separate paper. =A0Optional operator> separate f=
rom optional std::less. =A0tuple/pair separate from optional.<span><font co=
lor=3D"#888888"><br>
</font></span></div></div></blockquote><div><br></div></div><div>Agreed. <b=
r><br></div></div></div></div></blockquote><div><br></div><div>My preferenc=
e would be to separate out std::less specializations (tuple<T*> doesn=
't work as a key for<br>
an ordered associative container), but keep the other part, the discussion =
about relational operators<br>themselves, in a single paper. The pros/cons =
of what we do with optional's operator> are strongly<br>related to t=
uple/boost::tuple/containers, so I don't think we should split these in=
to separate tuple<br>
</div><div>and optional papers.<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 />
--047d7b3a831c9cb54404dcc272d9--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 15 May 2013 17:40:11 +0300
Raw View
--001a11c3311226fdc804dcc2baaa
Content-Type: text/plain; charset=ISO-8859-1
On 15 May 2013 17:20, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>
>
> On 15 May 2013 17:04, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>>
>> I'd prefer if as much as possible each issue was a separate paper.
>>> Optional operator> separate from optional std::less. tuple/pair separate
>>> from optional.
>>>
>>
>> Agreed.
>>
>>
> My preference would be to separate out std::less specializations
> (tuple<T*> doesn't work as a key for
> an ordered associative container), but keep the other part, the discussion
> about relational operators
> themselves, in a single paper. The pros/cons of what we do with optional's
> operator> are strongly
> related to tuple/boost::tuple/containers, so I don't think we should split
> these into separate tuple
> and optional papers.
>
>
I think it's clearest if, as mentioned, the std::less paper is completely
separate, then we have a collective
analysis paper, and separate wording papers for the options. The last bit
is actually quite good to
have, so that people don't accidentally scroll to the wrong wording. We had
that issue with
optional<T&> wording being present in the optional paper.
Good enough compromise?
--
---
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.
--001a11c3311226fdc804dcc2baaa
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 15 May 2013 17:20, Ville Voutilainen <span dir=3D"ltr"><<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@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 15 May 2013 17:=
04, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacc=
iola@gmail.com" target=3D"_blank">fernando.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"><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">I'd prefer if as much as po=
ssible each issue was a separate paper. =A0Optional operator> separate f=
rom optional std::less. =A0tuple/pair separate from optional.<span><font co=
lor=3D"#888888"><br>
</font></span></div></div></blockquote><div><br></div></div><div>Agreed. <b=
r><br></div></div></div></div></blockquote><div><br></div></div><div>My pre=
ference would be to separate out std::less specializations (tuple<T*>=
doesn't work as a key for<br>
an ordered associative container), but keep the other part, the discussion =
about relational operators<br>themselves, in a single paper. The pros/cons =
of what we do with optional's operator> are strongly<br>related to t=
uple/boost::tuple/containers, so I don't think we should split these in=
to separate tuple<br>
</div><div>and optional papers.<br></div></div><br></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">I think it's cl=
earest if, as mentioned, the std::less paper is completely separate, then w=
e have a collective<br></div><div class=3D"gmail_extra">analysis paper, and=
separate wording papers for the options. The last bit is actually quite go=
od to<br>
have, so that people don't accidentally scroll to the wrong wording. We=
had that issue with<br></div><div class=3D"gmail_extra">optional<T&=
> wording being present in the optional paper.<br><br></div><div class=
=3D"gmail_extra">
Good enough compromise?<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 />
--001a11c3311226fdc804dcc2baaa--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Wed, 15 May 2013 11:42:22 -0300
Raw View
--089e0158c5264fa47104dcc2c4b6
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 15, 2013 at 11:40 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 15 May 2013 17:20, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>>
>>
>>
>> On 15 May 2013 17:04, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>>
>>>
>>> I'd prefer if as much as possible each issue was a separate paper.
>>>> Optional operator> separate from optional std::less. tuple/pair separate
>>>> from optional.
>>>>
>>>
>>> Agreed.
>>>
>>>
>> My preference would be to separate out std::less specializations
>> (tuple<T*> doesn't work as a key for
>> an ordered associative container), but keep the other part, the
>> discussion about relational operators
>> themselves, in a single paper. The pros/cons of what we do with
>> optional's operator> are strongly
>> related to tuple/boost::tuple/containers, so I don't think we should
>> split these into separate tuple
>> and optional papers.
>>
>>
> I think it's clearest if, as mentioned, the std::less paper is completely
> separate, then we have a collective
> analysis paper, and separate wording papers for the options. The last bit
> is actually quite good to
> have, so that people don't accidentally scroll to the wrong wording. We
> had that issue with
> optional<T&> wording being present in the optional paper.
>
> Good enough compromise?
>
OK, as long as the collective paper does provide separate proposals, that
works for me.
--
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.
--089e0158c5264fa47104dcc2c4b6
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 W=
ed, May 15, 2013 at 11:40 AM, Ville Voutilainen <span dir=3D"ltr"><<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@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 15 May 2013 17:=
20, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutila=
inen@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>On 15 May 2013 17:04, Fernando =
Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmail.co=
m" target=3D"_blank">fernando.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"><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">I'd prefer if as much as po=
ssible each issue was a separate paper. =A0Optional operator> separate f=
rom optional std::less. =A0tuple/pair separate from optional.<span><font co=
lor=3D"#888888"><br>
</font></span></div></div></blockquote><div><br></div></div><div>Agreed. <b=
r><br></div></div></div></div></blockquote><div><br></div></div><div>My pre=
ference would be to separate out std::less specializations (tuple<T*>=
doesn't work as a key for<br>
an ordered associative container), but keep the other part, the discussion =
about relational operators<br>themselves, in a single paper. The pros/cons =
of what we do with optional's operator> are strongly<br>related to t=
uple/boost::tuple/containers, so I don't think we should split these in=
to separate tuple<br>
</div><div>and optional papers.<br></div></div><br></div></div>
</blockquote></div><br></div></div><div class=3D"gmail_extra">I think it=
9;s clearest if, as mentioned, the std::less paper is completely separate, =
then we have a collective<br></div><div class=3D"gmail_extra">analysis pape=
r, and separate wording papers for the options. The last bit is actually qu=
ite good to<br>
have, so that people don't accidentally scroll to the wrong wording. We=
had that issue with<br></div><div class=3D"gmail_extra">optional<T&=
> wording being present in the optional paper.<br><br></div><div class=
=3D"gmail_extra">
Good enough compromise?<br></div></div></blockquote><div><br></div><div>OK,=
as long as the collective paper does provide separate proposals, that work=
s for me.<br>=A0<br></div></div><br clear=3D"all"><br>-- <br>Fernando Cacci=
ola<br>
SciSoft 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 />
--089e0158c5264fa47104dcc2c4b6--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 15 May 2013 17:50:17 +0300
Raw View
--089e0129526a41a0d604dcc2de53
Content-Type: text/plain; charset=ISO-8859-1
On 15 May 2013 17:42, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>
> I think it's clearest if, as mentioned, the std::less paper is completely
>> separate, then we have a collective
>> analysis paper, and separate wording papers for the options. The last bit
>> is actually quite good to
>> have, so that people don't accidentally scroll to the wrong wording. We
>> had that issue with
>> optional<T&> wording being present in the optional paper.
>>
>> Good enough compromise?
>>
>
> OK, as long as the collective paper does provide separate proposals, that
> works for me.
>
>
I expect it to outline three(*) optional (oh my, this no-pun-intended stuff
is HARD :D) ways to go
forward, and I don't expect it to recommend any of them as unanimously
preferred. I expect
the paper to say that even the authors don't have a strong consensus. ;)
(*) The alternatives are
1) be inconsistent, do not synthesize for optional, do not change other
wrappers
2) synthesize, consistently
3) do not synthesize, consistently
--
---
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.
--089e0129526a41a0d604dcc2de53
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 15 May 2013 17:42, Fernando Cacciola <span dir=3D"ltr"><<a hr=
ef=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.caccio=
la@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"gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5"><br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">I think it's clearest if, a=
s mentioned, the std::less paper is completely separate, then we have a col=
lective<br></div><div class=3D"gmail_extra">analysis paper, and separate wo=
rding papers for the options. The last bit is actually quite good to<br>
have, so that people don't accidentally scroll to the wrong wording. We=
had that issue with<br></div><div class=3D"gmail_extra">optional<T&=
> wording being present in the optional paper.<br><br></div><div class=
=3D"gmail_extra">
Good enough compromise?<br></div></div></blockquote><div><br></div></div></=
div><div>OK, as long as the collective paper does provide separate proposal=
s, that works for me.<br><br></div></div></div></div></blockquote><div>
<br></div><div>I expect it to outline three(*) optional (oh my, this no-pun=
-intended stuff is HARD :D) ways to go<br>forward, and I don't expect i=
t to recommend any of them as unanimously preferred. I expect<br>the paper =
to say that even the authors don't have a strong consensus. ;) <br>
</div></div><br></div><div class=3D"gmail_extra">(*) The alternatives are<b=
r>1) be inconsistent, do not synthesize for optional, do not change other w=
rappers<br></div><div class=3D"gmail_extra">2) synthesize, consistently<br>
3) do not synthesize, consistently<br></div><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 />
--089e0129526a41a0d604dcc2de53--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 15 May 2013 07:56:19 -0700 (PDT)
Raw View
------=_Part_372_28765666.1368629779642
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu sobota, 4 maja 2013 16:46:19 UTC+2 u=BFytkownik Ville Voutilainen=20
napisa=B3:
>
>
> Indeed. And failing to achieve consensus means we'll get the current=20
> lovely situation, where
> we can't even do opt1 !=3D opt2 because people are so concerned about dou=
ble=20
> NaNs, apparently.=20
> Not for optional<int>, not for optional<string>, not for the gazillion=20
> types for which it would be useful,
> because of the holy NaN. Pardon me for the sardonic overtone, but the=20
> current situation has been
> designed by people who have completely lost their marbles.
>
More: you cannot even write: if (op !=3D nullopt)=20
--=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_372_28765666.1368629779642
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu sobota, 4 maja 2013 16:46:19 UTC+2 u=BFytkownik Ville Voutil=
ainen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br><div><div class=3D"gmail_quote"><div>Indeed. And failing to achieve =
consensus means we'll get the current lovely situation, where<br>we can't e=
ven do opt1 !=3D opt2 because people are so concerned about double NaNs, ap=
parently. <br>
</div></div>Not for optional<int>, not for optional<string>, no=
t for the gazillion types for which it would be useful,<br>because of the h=
oly NaN. Pardon me for the sardonic overtone, but the current situation has=
been<br>
</div><div>designed by people who have completely lost their marbles.<br></=
div></div></blockquote><div><br>More: you cannot even write: if (op !=3D nu=
llopt) <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_372_28765666.1368629779642--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 15 May 2013 18:03:22 +0300
Raw View
--001a11c329320adb1104dcc30d54
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 15 May 2013 17:56, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wrote:
>
> Indeed. And failing to achieve consensus means we'll get the current
>> lovely situation, where
>> we can't even do opt1 !=3D opt2 because people are so concerned about
>> double NaNs, apparently.
>> Not for optional<int>, not for optional<string>, not for the gazillion
>> types for which it would be useful,
>> because of the holy NaN. Pardon me for the sardonic overtone, but the
>> current situation has been
>> designed by people who have completely lost their marbles.
>>
>
> More: you cannot even write: if (op !=3D nullopt)
>
>
>
>
I consider that a much smaller problem than not being able to not-equal
compare two optionals.
--=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.
--001a11c329320adb1104dcc30d54
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 15 May 2013 17:56, Andrzej Krzemie=F1ski <span dir=3D"ltr"><<=
a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@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><div class=3D"im"><blockquote class=3D"g=
mail_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"><div>Indeed. And failing t=
o achieve consensus means we'll get the current lovely situation, where=
<br>we can't even do opt1 !=3D opt2 because people are so concerned abo=
ut double NaNs, apparently. <br>
</div></div>Not for optional<int>, not for optional<string>, no=
t for the gazillion types for which it would be useful,<br>because of the h=
oly NaN. Pardon me for the sardonic overtone, but the current situation has=
been<br>
</div><div>designed by people who have completely lost their marbles.<br></=
div></div></blockquote></div><div><br>More: you cannot even write: if (op !=
=3D nullopt) <br></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I consider that a much=
smaller problem than not being able to not-equal compare two optionals. <b=
r></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 />
--001a11c329320adb1104dcc30d54--
.