> I propose to add the specialization std::less<optional<T>> if
> std::less<T> is specialized.
>
> What do you think?

Can you provide a use-case where for having an optional value as a key in an
ordered container? Mind that I'm not against the idea, just wondering about
specific use-cases.

The space defined by optional does not really have a natural ordering, but if
Haskell people didn't mind that when defining the ordering for Maybe, I don't
think we should be hindered to do the same.


Ivan

KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76, keyserver.pgp.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/.

.

On 11/29/2014 12:13 PM, Ivan =C4=8Cuki=C4=87 wrote:

> Can you provide a use-case where for having an optional value as a key in=
 an
> ordered container? Mind that I'm not against the idea, just wondering abo=
ut
> specific use-cases.

Collecting histograms with don't-case values:

http://www.boost.org/libs/optional/doc/html/boost_optional/quick_start/stor=
age_in_containers.html

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

.

Le 29/11/14 12:13, Ivan =C4=8Cuki=C4=87 a =C3=A9crit :
>> I propose to add the specialization std::less<optional<T>> if
>> std::less<T> is specialized.
>>
>> What do you think?
> Can you provide a use-case where for having an optional value as a key in=
 an
> ordered container? Mind that I'm not against the idea, just wondering abo=
ut
> specific use-cases.
You could had a map from T to U and your program required a parameter of=20
type T. Now you change your program so that this T is optional. It seems=20
natural that now your map would be from optional<T> to U if you have a=20
default value to map for nullopt, or from optional<T> to optional<U> if=20
you have no such a default. You could always built on top of the initial=20
map T to U this new map.

Why would the standard library force the user to do it, if a simple and=20
coherent map<optional<T>,U> would be enough for the user?
>
> The space defined by optional does not really have a natural ordering, bu=
t if
> Haskell people didn't mind that when defining the ordering for Maybe, I d=
on't
> think we should be hindered to do the same.
>
>
There is a natural (total) ordering for the sum type when the types are=20
natural (total) ordered independent of what Haskell people did [1]. For=20
me optional<T> is  (nullopt_t + T). So, for me optional<T> has a natural=20
order if T has one.

Vicente

[1] http://en.wikipedia.org/wiki/Total_order#Sums_of_orders

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

.

Bjorn Reese:
> Collecting histograms with don't-case values:
>
> http://www.boost.org/libs/optional/doc/html/boost_optional/quick_start/stora
> ge_in_containers.html

Cool, thanks for the link!


Vicente J. Botet Escriba:
> There is a natural (total) ordering for the sum type when the types are
> natural (total) ordered independent of what Haskell people did [1]. For

When I said 'natural' I was thinking more of intuitive - whether a bunch of
people would answer the same thing when asked how to order them.

Mathematically, yes, it is easy to define a total ordering in this case. It is
also easy for the set of complex numbers, but we don't generally have the
practice of ordering them.

Ivan

KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76, keyserver.pgp.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/.

.

This is a multi-part message in MIME format.
--------------090204090809090802020409
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 29/11/14 14:10, Ivan =C4=8Cuki=C4=87 a =C3=A9crit :
> Vicente J. Botet Escriba:
>> There is a natural (total) ordering for the sum type when the types are
>> natural (total) ordered independent of what Haskell people did [1]. For
> When I said 'natural' I was thinking more of intuitive - whether a bunch =
of
> people would answer the same thing when asked how to order them.
Sorry, the words have their importance. Definitions are there so that=20
all people understand the same thing.
If we define another_optional<T> as T+nullopt_t the natural order would=20
make nullopt greater than any T. We need to take decisions when there=20
are alternative designs. Think about how tuple<> is ordered. As tuple is=20
a product type we just use the natural order for products types, that is=20
lexicographical order.
> Mathematically, yes, it is easy to define a total ordering in this case. =
It is
> also easy for the set of complex numbers, but we don't generally have the
> practice of ordering them.
>
>
The reason is that there is no total order on the complex numbers that=20
is compatible with addition and multiplication, and (complex, +, *)=20
together with =E2=89=A4 on complex is ordered field [1].

* if /a/ =E2=89=A4 /b/ then /a/ + /c/ =E2=89=A4 /b/ + /c/
* if 0 =E2=89=A4 /a/ and 0 =E2=89=A4 /b/ then 0 =E2=89=A4 /a/ */b/

optional<T> hasn't this problem, + and * are not defined for optional<T>=20
- note that their natural definition (pun intended) would respect these=20
laws.

Programming languages and libraries should follow Math concepts when=20
possible. Maths has more than 2000 years.

Vicente

[1] http://en.wikipedia.org/wiki/Ordered_field

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 29/11/14 14:10, Ivan =C4=8Cuki=C4=87 =
a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote cite=3D"mid:2273098.PDo5rqENPD@drako" type=3D"cite">
      Vicente J. Botet Escriba:
      <blockquote type=3D"cite">
        <pre wrap=3D"">There is a natural (total) ordering for the sum type=
 when the types are
natural (total) ordered independent of what Haskell people did [1]. For
</pre>
      </blockquote>
      <pre wrap=3D"">
When I said 'natural' I was thinking more of intuitive - whether a bunch of=
=20
people would answer the same thing when asked how to order them.
</pre>
    </blockquote>
    Sorry, the words have their importance. Definitions are there so
    that all people understand the same thing.<br>
    If we define another_optional&lt;T&gt; as T+nullopt_t the natural
    order would make nullopt greater than any T. We need to take
    decisions when there are alternative designs. Think about how
    tuple&lt;&gt; is ordered. As tuple is a product type we just use the
    natural order for products types, that is lexicographical order.=C2=A0 =
<br>
    <blockquote cite=3D"mid:2273098.PDo5rqENPD@drako" type=3D"cite">
      <pre wrap=3D"">
Mathematically, yes, it is easy to define a total ordering in this case. It=
 is=20
also easy for the set of complex numbers, but we don't generally have the=
=20
practice of ordering them.


</pre>
    </blockquote>
    The reason is that there is no total order on the complex numbers
    that is compatible with addition and multiplication, and (complex,
    +, *) together with =E2=89=A4 on complex is ordered field [1].<br>
    <br>
    * if <i>a</i> =E2=89=A4 <i>b</i> then <i>a</i> + <i>c</i> =E2=89=A4 <i>=
b</i> +
    <i>c</i><br>
    * if 0 =E2=89=A4 <i>a</i> and 0 =E2=89=A4 <i>b</i> then 0 =E2=89=A4 <i>=
a</i> *<i>b</i>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
    <br>
    <br>
    optional&lt;T&gt; hasn't this problem, + and * are not defined for
    optional&lt;T&gt; - note that their natural definition (pun
    intended) would respect these laws.<br>
    <br>
    Programming languages and libraries should follow Math concepts when
    possible. Maths has more than 2000 years.<br>
    <br>
    Vicente<br>
    <br>
    [1] <a class=3D"moz-txt-link-freetext" href=3D"http://en.wikipedia.org/=
wiki/Ordered_field">http://en.wikipedia.org/wiki/Ordered_field</a><br>
    <br>
  </body>
</html>

<p></p>

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

--------------090204090809090802020409--

.

> > When I said 'natural' I was thinking more of intuitive - whether a bunch
> > of
> > people would answer the same thing when asked how to order them.
>
> Sorry, the words have their importance. Definitions are there so that
> all people understand the same thing.

> Programming languages and libraries should follow Math concepts when
> possible. Maths has more than 2000 years.

As a matematician, I agree. (that is why I'm not against the proposal, as
mentioned earlier)

I just wanted to state that not everybody will find this intuitive, nothing
more.

--
Cheerio,
Ivan


KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76, keyserver.pgp.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/.

.

--089e0160b7ce205b6c050905f451
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 29, 2014 at 5:03 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

>  Hi,
>
> With the current specification, optional<T> can not be stored on an
> ordered container when T doesn't define the operator<(T,T), but specializes
> std::less<T>.
>
> I propose to add the specialization std::less<optional<T>> if std::less<T>
> is specialized.
>
> What do you think?
>
> Vicente
>


Totally agree. It was there when I argued for it the first time.  Not sure
when/how it disappeared.  Need to check meeting notes.  Maybe it was the
meeting I missed. :-(  Or I just wasn't paying attention. :-( :-(

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Nov 29, 2014 at 5:03 AM, Vicente J. Botet Escriba <span dir=3D"=
ltr">&lt;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
 =20

   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <font size=3D"+1">Hi,<br>
      <br>
      With the current specification, optional&lt;T&gt; can not be
      stored on an ordered container when T doesn&#39;t define the
      operator&lt;(T,T), but specializes std::less&lt;T&gt;.<br>
      <br>
    </font><font size=3D"+1">I propose to add the specialization
      std::less&lt;optional&lt;T&gt;&gt; if std::less&lt;T&gt; is
      specialized.<br>
      <br>
      What do you think?<span class=3D"HOEnZb"><font color=3D"#888888"><br>
      <br>
    </font></span></font><span class=3D"HOEnZb"><font color=3D"#888888">Vic=
ente<br></font></span></div></blockquote><div><br><br></div><div>Totally ag=
ree. It was there when I argued for it the first time.=C2=A0 Not sure when/=
how it disappeared.=C2=A0 Need to check meeting notes.=C2=A0 Maybe it was t=
he meeting I missed. :-(=C2=A0 Or I just wasn&#39;t paying attention. :-( :=
-(<br><br>Tony<br><br><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160b7ce205b6c050905f451--

.

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

On Sat, Nov 29, 2014 at 8:10 AM, Ivan =C4=8Cuki=C4=87 <ivan.cukic@gmail.com=
> wrote:

> Bjorn Reese:
> > Collecting histograms with don't-case values:
> >
> >
> http://www.boost.org/libs/optional/doc/html/boost_optional/quick_start/st=
ora
> > ge_in_containers.html
>
> Cool, thanks for the link!
>
>
> Vicente J. Botet Escriba:
> > There is a natural (total) ordering for the sum type when the types are
> > natural (total) ordered independent of what Haskell people did [1]. For
>
> When I said 'natural' I was thinking more of intuitive - whether a bunch =
of
> people would answer the same thing when asked how to order them.
>
> Mathematically, yes, it is easy to define a total ordering in this case.
> It is
> also easy for the set of complex numbers, but we don't generally have the
> practice of ordering them.
>

There are a number of people on or near the committee that think complex
should specialize std::less, but not have operator<.


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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Nov 29, 2014 at 8:10 AM, Ivan =C4=8Cuki=C4=87 <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:ivan.cukic@gmail.com" target=3D"_blank">ivan.cukic@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bjorn Re=
ese:<br>
<span class=3D"">&gt; Collecting histograms with don&#39;t-case values:<br>
&gt;<br>
&gt; <a href=3D"http://www.boost.org/libs/optional/doc/html/boost_optional/=
quick_start/stora" target=3D"_blank">http://www.boost.org/libs/optional/doc=
/html/boost_optional/quick_start/stora</a><br>
&gt; ge_in_containers.html<br>
<br>
</span>Cool, thanks for the link!<br>
<br>
<br>
Vicente J. Botet Escriba:<br>
<span class=3D"">&gt; There is a natural (total) ordering for the sum type =
when the types are<br>
&gt; natural (total) ordered independent of what Haskell people did [1]. Fo=
r<br>
<br>
</span>When I said &#39;natural&#39; I was thinking more of intuitive - whe=
ther a bunch of<br>
people would answer the same thing when asked how to order them.<br>
<br>
Mathematically, yes, it is easy to define a total ordering in this case. It=
 is<br>
also easy for the set of complex numbers, but we don&#39;t generally have t=
he<br>
practice of ordering them.<br></blockquote><div><br></div><div>There are a =
number of people on or near the committee that think complex should special=
ize std::less, but not have operator&lt;.<br>=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<span class=3D"im HOEnZb"><br>
Ivan<br>
<br><br></span></blockquote><div><br></div><div>Tony<br>=C2=A0<br></div></d=
iv><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c29bca732cde050905faa4--

.

------=_Part_8104_868832008.1417296729970
Content-Type: multipart/alternative;
 boundary="----=_Part_8105_1718242503.1417296729970"

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



W dniu sobota, 29 listopada 2014 22:21:02 UTC+1 u=C5=BCytkownik Tony V E na=
pisa=C5=82:
>
>
>
> On Sat, Nov 29, 2014 at 5:03 AM, Vicente J. Botet Escriba <
> vicent...@wanadoo.fr <javascript:>> wrote:
>
>>  Hi,
>>
>> With the current specification, optional<T> can not be stored on an=20
>> ordered container when T doesn't define the operator<(T,T), but speciali=
zes=20
>> std::less<T>.
>>
>> I propose to add the specialization std::less<optional<T>> if=20
>> std::less<T> is specialized.
>>
>> What do you think?
>>
>> Vicente
>>
>
>
> Totally agree. It was there when I argued for it the first time.  Not sur=
e=20
> when/how it disappeared.  Need to check meeting notes.  Maybe it was the=
=20
> meeting I missed. :-(  Or I just wasn't paying attention. :-( :-(
>

See:=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html#revision
"Implentation of op::operator< does not use std::less (agreed in *Chicago=
=20
meeting*)."=20

At some point we were using std::less<T> to implement=20
optional<T>::operator<. We never proposed specializing std::less for=20
optional<T>.

Regards,
&rzej

--=20

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

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

<div dir=3D"ltr"><br><br>W dniu sobota, 29 listopada 2014 22:21:02 UTC+1 u=
=C5=BCytkownik Tony V E napisa=C5=82:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Sat, Nov=
 29, 2014 at 5:03 AM, Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Omx6xIjTlFoJ" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">vicent...@wanadoo.fr</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
 =20

   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <font size=3D"+1">Hi,<br>
      <br>
      With the current specification, optional&lt;T&gt; can not be
      stored on an ordered container when T doesn't define the
      operator&lt;(T,T), but specializes std::less&lt;T&gt;.<br>
      <br>
    </font><font size=3D"+1">I propose to add the specialization
      std::less&lt;optional&lt;T&gt;&gt; if std::less&lt;T&gt; is
      specialized.<br>
      <br>
      What do you think?<span><font color=3D"#888888"><br>
      <br>
    </font></span></font><span><font color=3D"#888888">Vicente<br></font></=
span></div></blockquote><div><br><br></div><div>Totally agree. It was there=
 when I argued for it the first time.&nbsp; Not sure when/how it disappeare=
d.&nbsp; Need to check meeting notes.&nbsp; Maybe it was the meeting I miss=
ed. :-(&nbsp; Or I just wasn't paying attention. :-( :-(<br></div></div></d=
iv></div></blockquote><div><br>See: http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2013/n3793.html#revision<br>"Implentation of op::operator&lt; d=
oes not use std::less (agreed in <b>Chicago meeting</b>)." <br><br>At some =
point we were using std::less&lt;T&gt; to implement optional&lt;T&gt;::oper=
ator&lt;. We never proposed specializing std::less for optional&lt;T&gt;.<b=
r><br>Regards,<br>&amp;rzej<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8105_1718242503.1417296729970--
------=_Part_8104_868832008.1417296729970--

.

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

On Sat, Nov 29, 2014 at 4:32 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:

>
>
> W dniu sobota, 29 listopada 2014 22:21:02 UTC+1 u=C5=BCytkownik Tony V E
> napisa=C5=82:
>>
>>
>>
>> On Sat, Nov 29, 2014 at 5:03 AM, Vicente J. Botet Escriba <
>> vicent...@wanadoo.fr> wrote:
>>
>>>  Hi,
>>>
>>> With the current specification, optional<T> can not be stored on an
>>> ordered container when T doesn't define the operator<(T,T), but special=
izes
>>> std::less<T>.
>>>
>>> I propose to add the specialization std::less<optional<T>> if
>>> std::less<T> is specialized.
>>>
>>> What do you think?
>>>
>>> Vicente
>>>
>>
>>
>> Totally agree. It was there when I argued for it the first time.  Not
>> sure when/how it disappeared.  Need to check meeting notes.  Maybe it wa=
s
>> the meeting I missed. :-(  Or I just wasn't paying attention. :-( :-(
>>
>
> See:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html#revisi=
on
> "Implentation of op::operator< does not use std::less (agreed in *Chicago
> meeting*)."
>
> At some point we were using std::less<T> to implement
> optional<T>::operator<. We never proposed specializing std::less for
> optional<T>.
>
> Regards,
> &rzej
>
> --
>
>

I think it was in Chicago (if not Bristol) where I suggested specializing
std::less INSTEAD OF using std::less for op<.
Using std::less for op< made some sense - it enables optional pointers to
work well.  But then we realized that specializing std::less was the right
way to do it.

But I don't even remember when/how optional re-grew the other operators -
for a while it only had op< and =3D=3D.  Did the others get reintroduced wh=
en
we moved it to Library TS? (I think that was it, but hard to recall)

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Nov 29, 2014 at 4:32 PM, Andrzej Krzemie=C5=84ski <span dir=3D"=
ltr">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><br><br>W dniu sobota, 29 listopada 2014 22:21:02 UTC+1 u=C5=BCytk=
ownik Tony V E napisa=C5=82:<span class=3D""><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Sat, =
Nov 29, 2014 at 5:03 AM, Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a>=
vicent...@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
 =20

   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <font size=3D"+1">Hi,<br>
      <br>
      With the current specification, optional&lt;T&gt; can not be
      stored on an ordered container when T doesn&#39;t define the
      operator&lt;(T,T), but specializes std::less&lt;T&gt;.<br>
      <br>
    </font><font size=3D"+1">I propose to add the specialization
      std::less&lt;optional&lt;T&gt;&gt; if std::less&lt;T&gt; is
      specialized.<br>
      <br>
      What do you think?<span><font color=3D"#888888"><br>
      <br>
    </font></span></font><span><font color=3D"#888888">Vicente<br></font></=
span></div></blockquote><div><br><br></div><div>Totally agree. It was there=
 when I argued for it the first time.=C2=A0 Not sure when/how it disappeare=
d.=C2=A0 Need to check meeting notes.=C2=A0 Maybe it was the meeting I miss=
ed. :-(=C2=A0 Or I just wasn&#39;t paying attention. :-( :-(<br></div></div=
></div></div></blockquote></span><div><br>See: <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html#revision" target=3D"_blan=
k">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html#revis=
ion</a><br>&quot;Implentation of op::operator&lt; does not use std::less (a=
greed in <b>Chicago meeting</b>).&quot; <br><br>At some point we were using=
 std::less&lt;T&gt; to implement optional&lt;T&gt;::operator&lt;. We never =
proposed specializing std::less for optional&lt;T&gt;.<br><br>Regards,<br>&=
amp;rzej<br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br></div></div></blockquote><div><br><br></div><div>I think it was in Chic=
ago (if not Bristol) where I suggested specializing std::less INSTEAD OF us=
ing std::less for op&lt;.=C2=A0 <br></div><div>Using std::less for op&lt; m=
ade some sense - it enables optional pointers to work well.=C2=A0 But then =
we realized that specializing std::less was the right way to do it.<br><br>=
</div><div>But I don&#39;t even remember when/how optional re-grew the othe=
r operators - for a while it only had op&lt; and =3D=3D.=C2=A0 Did the othe=
rs get reintroduced when we moved it to Library TS? (I think that was it, b=
ut hard to recall)<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c30f84916d6b050906487c--

.

There's reluctance to specializing less<optional<T>> unless we also do
something to fix less<tuple<T...>>, less<vector<T>>, etc. And there's
reluctance to add an entirely parallel tree of less<> definitions next
to the operator< definitions. Someone should write a paper showing how
all of this would work, and that it wouldn't be so bad to specify.

On Sat, Nov 29, 2014 at 2:03 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> With the current specification, optional<T> can not be stored on an ordered
> container when T doesn't define the operator<(T,T), but specializes
> std::less<T>.
>
> I propose to add the specialization std::less<optional<T>> if std::less<T>
> is specialized.
>
> What do you think?
>
> Vicente
>
> --
>
> ---
> 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/.

--

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

.

------=_Part_7956_50218949.1417298374950
Content-Type: multipart/alternative;
 boundary="----=_Part_7957_68802572.1417298374950"

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



W dniu sobota, 29 listopada 2014 22:44:37 UTC+1 u=C5=BCytkownik Tony V E na=
pisa=C5=82:
>
>
>
> On Sat, Nov 29, 2014 at 4:32 PM, Andrzej Krzemie=C5=84ski <akrz...@gmail.=
com=20
> <javascript:>> wrote:
>
>>
>>
>> W dniu sobota, 29 listopada 2014 22:21:02 UTC+1 u=C5=BCytkownik Tony V E=
=20
>> napisa=C5=82:
>>>
>>>
>>>
>>> On Sat, Nov 29, 2014 at 5:03 AM, Vicente J. Botet Escriba <
>>> vicent...@wanadoo.fr> wrote:
>>>
>>>>  Hi,
>>>>
>>>> With the current specification, optional<T> can not be stored on an=20
>>>> ordered container when T doesn't define the operator<(T,T), but specia=
lizes=20
>>>> std::less<T>.
>>>>
>>>> I propose to add the specialization std::less<optional<T>> if=20
>>>> std::less<T> is specialized.
>>>>
>>>> What do you think?
>>>>
>>>> Vicente
>>>>
>>>
>>>
>>> Totally agree. It was there when I argued for it the first time.  Not=
=20
>>> sure when/how it disappeared.  Need to check meeting notes.  Maybe it w=
as=20
>>> the meeting I missed. :-(  Or I just wasn't paying attention. :-( :-(
>>>
>>
>> See:=20
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html#revis=
ion
>> "Implentation of op::operator< does not use std::less (agreed in *Chicag=
o=20
>> meeting*)."=20
>>
>> At some point we were using std::less<T> to implement=20
>> optional<T>::operator<. We never proposed specializing std::less for=20
>> optional<T>.
>>
>> Regards,
>> &rzej
>>
>> --=20
>>
>>
>
> I think it was in Chicago (if not Bristol) where I suggested specializing=
=20
> std::less INSTEAD OF using std::less for op<. =20
> Using std::less for op< made some sense - it enables optional pointers to=
=20
> work well.  But then we realized that specializing std::less was the righ=
t=20
> way to do it.
>

I got the following feedback around 01.10.2013, I guess it was Chicago=20
meeting:

1) optional's relational operators should not invoke std::less,
operator< should use the underlying type's operator<
2) the remaining relational operators should be synthesized
in terms of operator<
3) optional's operator!=3D should do !op=3D=3D
4) LEWG wishes to have comparison operators that support
types from which the underlying type is constructible, meaning
optional<string> !=3D "foo" should work
5) LEWG also wishes to have mixed-mode assignments, meaning
optional<string> =3D "foo" should work, and optional<double> =3D 2.0
should work. The latter assigns a float to a double.
=20

>
> But I don't even remember when/how optional re-grew the other operators -=
=20
> for a while it only had op< and =3D=3D.  Did the others get reintroduced =
when=20
> we moved it to Library TS? (I think that was it, but hard to recall)
>
>
>

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

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

<div dir=3D"ltr"><br><br>W dniu sobota, 29 listopada 2014 22:44:37 UTC+1 u=
=C5=BCytkownik Tony V E napisa=C5=82:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Sat, Nov=
 29, 2014 at 4:32 PM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8OfGETU17usJ" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">akrz...@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>W dniu sobota, 29 li=
stopada 2014 22:21:02 UTC+1 u=C5=BCytkownik Tony V E napisa=C5=82:<span><bl=
ockquote 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"><br><div><br><div cla=
ss=3D"gmail_quote">On Sat, Nov 29, 2014 at 5:03 AM, Vicente J. Botet Escrib=
a <span dir=3D"ltr">&lt;<a>vicent...@wanadoo.fr</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
 =20

   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <font size=3D"+1">Hi,<br>
      <br>
      With the current specification, optional&lt;T&gt; can not be
      stored on an ordered container when T doesn't define the
      operator&lt;(T,T), but specializes std::less&lt;T&gt;.<br>
      <br>
    </font><font size=3D"+1">I propose to add the specialization
      std::less&lt;optional&lt;T&gt;&gt; if std::less&lt;T&gt; is
      specialized.<br>
      <br>
      What do you think?<span><font color=3D"#888888"><br>
      <br>
    </font></span></font><span><font color=3D"#888888">Vicente<br></font></=
span></div></blockquote><div><br><br></div><div>Totally agree. It was there=
 when I argued for it the first time.&nbsp; Not sure when/how it disappeare=
d.&nbsp; Need to check meeting notes.&nbsp; Maybe it was the meeting I miss=
ed. :-(&nbsp; Or I just wasn't paying attention. :-( :-(<br></div></div></d=
iv></div></blockquote></span><div><br>See: <a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2013/n3793.html#revision" target=3D"_blank" o=
nmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3793.html%23revi=
sion\46sa\75D\46sntz\0751\46usg\75AFQjCNGXR_qkSVY9bAr5XNKTQm97K4GLIw';retur=
n true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2=
Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3793.html%=
23revision\46sa\75D\46sntz\0751\46usg\75AFQjCNGXR_qkSVY9bAr5XNKTQm97K4GLIw'=
;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2013=
/<wbr>n3793.html#revision</a><br>"Implentation of op::operator&lt; does not=
 use std::less (agreed in <b>Chicago meeting</b>)." <br><br>At some point w=
e were using std::less&lt;T&gt; to implement optional&lt;T&gt;::operator&lt=
;. We never proposed specializing std::less for optional&lt;T&gt;.<br><br>R=
egards,<br>&amp;rzej<br></div></div><div><div>

<p></p>

-- <br>
<br></div></div></blockquote><div><br><br></div><div>I think it was in Chic=
ago (if not Bristol) where I suggested specializing std::less INSTEAD OF us=
ing std::less for op&lt;.&nbsp; <br></div><div>Using std::less for op&lt; m=
ade some sense - it enables optional pointers to work well.&nbsp; But then =
we realized that specializing std::less was the right way to do it.<br></di=
v></div></div></div></blockquote><div><br>I got the following feedback arou=
nd 01.10.2013, I guess it was Chicago meeting:<br><br>1) optional's relatio=
nal operators should not invoke std::less,<br>operator&lt; should use the u=
nderlying type's operator&lt;<br>2) the remaining relational operators shou=
ld be synthesized<br>
in terms of operator&lt;<br>3) optional's operator!=3D should do !op=3D=3D<=
br>4) LEWG wishes to have comparison operators that support<br>types from w=
hich the underlying type is constructible, meaning<br>
optional&lt;string&gt; !=3D "foo" should work<br>5) LEWG also wishes to hav=
e mixed-mode assignments, meaning<br>optional&lt;string&gt; =3D "foo" shoul=
d work, and optional&lt;double&gt; =3D 2.0<br>
should work. The latter assigns a float to a double.<br>&nbsp;<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div><br></div><div>But I don't even remember when/how opt=
ional re-grew the other operators - for a while it only had op&lt; and =3D=
=3D.&nbsp; Did the others get reintroduced when we moved it to Library TS? =
(I think that was it, but hard to recall)<br><br></div></div><br></div></di=
v>
</blockquote></div>

<p></p>

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

------=_Part_7957_68802572.1417298374950--
------=_Part_7956_50218949.1417298374950--

.

Le 29/11/14 22:58, 'Jeffrey Yasskin' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> There's reluctance to specializing less<optional<T>> unless we also do
> something to fix less<tuple<T...>>, less<vector<T>>, etc.
Right. Every wrapping type should specialize std::less ;-)
> And there's
> reluctance to add an entirely parallel tree of less<> definitions next
> to the operator< definitions.
Do you mean that the LEWG was not for? what was the reason? It was=20
because it is not worth handling the case of classes that specialize=20
std::less<T> that don't define operator<?
> Someone should write a paper showing how
> all of this would work, and that it wouldn't be so bad to specify.
Anyone is volunteering, Tony, Andrzej ;-)

Vicente
> On Sat, Nov 29, 2014 at 2:03 AM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Hi,
>>
>> With the current specification, optional<T> can not be stored on an orde=
red
>> container when T doesn't define the operator<(T,T), but specializes
>> std::less<T>.
>>
>> I propose to add the specialization std::less<optional<T>> if std::less<=
T>
>> is specialized.
>>
>> What do you think?
>>
>> Vicente
>>
>>

--=20

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

.

------=_Part_941_1276528189.1417424725546
Content-Type: multipart/alternative;
 boundary="----=_Part_942_1247638993.1417424725546"

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



W dniu niedziela, 30 listopada 2014 01:14:32 UTC+1 u=C5=BCytkownik Vicente =
J.=20
Botet Escriba napisa=C5=82:
>
> Le 29/11/14 22:58, 'Jeffrey Yasskin' via ISO C++ Standard - Future=20
> Proposals a =C3=A9crit :=20
> > There's reluctance to specializing less<optional<T>> unless we also do=
=20
> > something to fix less<tuple<T...>>, less<vector<T>>, etc.=20
> Right. Every wrapping type should specialize std::less ;-)=20
> > And there's=20
> > reluctance to add an entirely parallel tree of less<> definitions next=
=20
> > to the operator< definitions.=20
> Do you mean that the LEWG was not for? what was the reason? It was=20
> because it is not worth handling the case of classes that specialize=20
> std::less<T> that don't define operator<?=20
> > Someone should write a paper showing how=20
> > all of this would work, and that it wouldn't be so bad to specify.=20
> Anyone is volunteering, Tony, Andrzej ;-)=20
>

I am not volunteering at this time, as I am not at all convinced that this=
=20
is the best approach to be taken. I think it is incompatible with the=20
recent "diamond less" addition:=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm

When I have some time to prepare myself, I will come back with my analysis=
=20
and suggestions in a separate thread.

Regards,
&rzej

--=20

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

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

<div dir=3D"ltr"><br><br>W dniu niedziela, 30 listopada 2014 01:14:32 UTC+1=
 u=C5=BCytkownik Vicente J. Botet Escriba napisa=C5=82:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">Le 29/11/14 22:58, 'Jeffrey Yasskin' via ISO C++ S=
tandard - Future=20
<br>Proposals a =C3=A9crit :
<br>&gt; There's reluctance to specializing less&lt;optional&lt;T&gt;&gt; u=
nless we also do
<br>&gt; something to fix less&lt;tuple&lt;T...&gt;&gt;, less&lt;vector&lt;=
T&gt;&gt;, etc.
<br>Right. Every wrapping type should specialize std::less ;-)
<br>&gt; And there's
<br>&gt; reluctance to add an entirely parallel tree of less&lt;&gt; defini=
tions next
<br>&gt; to the operator&lt; definitions.
<br>Do you mean that the LEWG was not for? what was the reason? It was=20
<br>because it is not worth handling the case of classes that specialize=20
<br>std::less&lt;T&gt; that don't define operator&lt;?
<br>&gt; Someone should write a paper showing how
<br>&gt; all of this would work, and that it wouldn't be so bad to specify.
<br>Anyone is volunteering, Tony, Andrzej ;-)
<br></blockquote><div><br>I am not volunteering at this time, as I am not a=
t all convinced that this is the best approach to be taken. I think it is i=
ncompatible with the recent "diamond less" addition: http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2013/n3657.htm<br><br>When I have some time to=
 prepare myself, I will come back with my analysis and suggestions in a sep=
arate thread.<br><br>Regards,<br>&amp;rzej<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_942_1247638993.1417424725546--
------=_Part_941_1276528189.1417424725546--

.

This is a multi-part message in MIME format.
--------------020605040201030605060209
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 01/12/14 10:05, Andrzej Krzemie=C5=84ski a =C3=A9crit :
>
>
> W dniu niedziela, 30 listopada 2014 01:14:32 UTC+1 u=C5=BCytkownik Vicent=
e=20
> J. Botet Escriba napisa=C5=82:
>
>     Le 29/11/14 22:58, 'Jeffrey Yasskin' via ISO C++ Standard - Future
>     Proposals a =C3=A9crit :
>     > There's reluctance to specializing less<optional<T>> unless we
>     also do
>     > something to fix less<tuple<T...>>, less<vector<T>>, etc.
>     Right. Every wrapping type should specialize std::less ;-)
>     > And there's
>     > reluctance to add an entirely parallel tree of less<>
>     definitions next
>     > to the operator< definitions.
>     Do you mean that the LEWG was not for? what was the reason? It was
>     because it is not worth handling the case of classes that specialize
>     std::less<T> that don't define operator<?
>     > Someone should write a paper showing how
>     > all of this would work, and that it wouldn't be so bad to specify.
>     Anyone is volunteering, Tony, Andrzej ;-)
>
>
> I am not volunteering at this time, as I am not at all convinced that=20
> this is the best approach to be taken. I think it is incompatible with=20
> the recent "diamond less" addition:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm
>
Thanks for pointing out this paper. I skipped it.
> When I have some time to prepare myself, I will come back with my=20
> analysis and suggestions in a separate thread.
>
I will need some time also to analyze the consequences of this=20
heterogeneous comparison lookup.

Vicente

--=20

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 01/12/14 10:05, Andrzej Krzemie=C5=84=
ski
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:e9de056c-d237-4993-b07b-565c4e0f5136@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        W dniu niedziela, 30 listopada 2014 01:14:32 UTC+1 u=C5=BCytkownik
        Vicente J. Botet Escriba napisa=C5=82:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le
          29/11/14 22:58, 'Jeffrey Yasskin' via ISO C++ Standard -
          Future <br>
          Proposals a =C3=A9crit :
          <br>
          &gt; There's reluctance to specializing
          less&lt;optional&lt;T&gt;&gt; unless we also do
          <br>
          &gt; something to fix less&lt;tuple&lt;T...&gt;&gt;,
          less&lt;vector&lt;T&gt;&gt;, etc.
          <br>
          Right. Every wrapping type should specialize std::less ;-)
          <br>
          &gt; And there's
          <br>
          &gt; reluctance to add an entirely parallel tree of
          less&lt;&gt; definitions next
          <br>
          &gt; to the operator&lt; definitions.
          <br>
          Do you mean that the LEWG was not for? what was the reason? It
          was <br>
          because it is not worth handling the case of classes that
          specialize <br>
          std::less&lt;T&gt; that don't define operator&lt;?
          <br>
          &gt; Someone should write a paper showing how
          <br>
          &gt; all of this would work, and that it wouldn't be so bad to
          specify.
          <br>
          Anyone is volunteering, Tony, Andrzej ;-)
          <br>
        </blockquote>
        <div><br>
          I am not volunteering at this time, as I am not at all
          convinced that this is the best approach to be taken. I think
          it is incompatible with the recent "diamond less" addition:
          <a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2013/n3657.htm">http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2013/n3657.htm</a><br>
          <br>
        </div>
      </div>
    </blockquote>
    Thanks for pointing out this paper. I skipped it.<br>
    <blockquote
      cite=3D"mid:e9de056c-d237-4993-b07b-565c4e0f5136@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>When I have some time to prepare myself, I will come back
          with my analysis and suggestions in a separate thread.<br>
          <br>
        </div>
      </div>
    </blockquote>
    I will need some time also to analyze the consequences of this
    heterogeneous comparison lookup.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

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

--------------020605040201030605060209--

.