Topic: std::order -- what do you think?
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 30 Jul 2014 06:25:44 -0700 (PDT)
Raw View
------=_Part_1847_160802583.1406726744327
Content-Type: text/plain; charset=UTF-8
Hi Everyone,
TL;DR: A new functor std::order that would be used in ordered containers by
default, and would work for std::complex.
There are two reasons for adding a default order to a user-defined type:
1. To represent the intuitive mathematical notion of two real numbers
being greater or smaller. This can be used to check if a value is lower
than some defined threshold.
2. To add a criterion for sorting in ordered containers and algorithms
that rely on some order.
Types like std::string can be ordered by a lexicographical order, but it
makes no sense for them to check if they have exceeded a "string
threshold". You can define operator< for a string, but it is somewhat
artificial and confusing. It is even more confusing for std::optional<T>:
you can define operator< for it with some meaning (e.g., that uninitialized
optional is some special value less than any T), but it has no intuitive
meaning that would help with interpreting when an optional<T> exceeds a
threshold.
While std::string is a lost case as it already defines operator<, it is
possible to avoid adding it to optional<T>, while still making it usable in
ordered containers. More, we could make std::complex useful in ordered
containers.
The solution was proposed here a couple of times. Define function template
order<> that would either fall back to std::less or use user-provided
specializations.
So for types like std::complex and std::optional we would only specialize
std::order, but no std::less and give no operator<.
For types like std::integer, we would only define operator< (and std::order
will pick it implicitly).
For types std::string and std::tuple operator< -- according to the
reasoning in this proposal -- should have never been defined, but we keep
it for compatibility reasons. They could be deprecated and std::order
specializations still provided.
What do you think about such addition? Or is something like this already
considered in LEWG?
Regards,
&rzej
--
---
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_1847_160802583.1406726744327
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Everyone,<br><br>TL;DR: A new functor std::order that w=
ould be used in ordered containers by default, and would work for std::comp=
lex.<br><br>There are two reasons for adding a default order to a user-defi=
ned type:<br><ol><li>To represent the intuitive mathematical notion of two =
real numbers being greater or smaller. This can be used to check if a value=
is lower than some defined threshold.</li><li>To add a criterion for sorti=
ng in ordered containers and algorithms that rely on some order.</li></ol><=
p>Types like std::string can be ordered by a lexicographical order, but it =
makes no sense for them to check if they have exceeded a "string threshold"=
.. You can define operator< for a string, but it is somewhat artificial a=
nd confusing. It is even more confusing for std::optional<T>: you can=
define operator< for it with some meaning (e.g., that uninitialized opt=
ional is some special value less than any T), but it has no intuitive meani=
ng that would help with interpreting when an optional<T> exceeds a th=
reshold.</p><p>While std::string is a lost case as it already defines opera=
tor<, it is possible to avoid adding it to optional<T>, while stil=
l making it usable in ordered containers. More, we could make std::complex =
useful in ordered containers.</p><p>The solution was proposed here a couple=
of times. Define function template order<> that would either fall ba=
ck to std::less or use user-provided specializations.</p><p>So for types li=
ke std::complex and std::optional we would only specialize std::order, but =
no std::less and give no operator<.</p><p>For types like std::integer, w=
e would only define operator< (and std::order will pick it implicitly).<=
/p><p>For types std::string and std::tuple operator< -- according to the=
reasoning in this proposal -- should have never been defined, but we keep =
it for compatibility reasons. They could be deprecated and std::order speci=
alizations still provided.</p><p>What do you think about such addition? Or =
is something like this already considered in LEWG?</p><p>Regards,<br>&r=
zej<br></p></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 <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_1847_160802583.1406726744327--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 30 Jul 2014 12:15:46 -0400
Raw View
--001a11c33d70f6e74904ff6b77b7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 30, 2014 at 9:25 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:
> Hi Everyone,
>
> TL;DR: A new functor std::order that would be used in ordered containers
> by default, and would work for std::complex.
>
....
> What do you think about such addition? Or is something like this already
> considered in LEWG?
>
>
"Considered"? Yes. Formally Proposed? Not that I know of.
Alisdair and I promised each other to work together on it in order to
prevent either of us from procrastinating on it. Guess what, we are both
too good at procrastination.
One thing to keep in mind - we can't just do std::order and then say "map
now uses std::order by default", as this has backwards compatibility issues=
..
ie every map<X> that was map<X, std::less<X>> can't change to map<X,
std::order<X>>, because that will break ABI somewhere, and who knows what
else.
Instead, we need another level of indirection (which solves everything,
right?):
map<> needs to become
template<typename T, typename Ordering =3D std::lookup_order<T>::order>
class map ....;
and std::lookup_order is
template <typename T>
struct lookup_order
{
typedef std::less<T> less;
};
And then you overload lookup_order.
Or maybe lookup_order can somehow test whether std::order has been
specialized or not:
template <typename T>
struct lookup_order
{
typedef if_c<std_order_specialized_magic<T>::value, std::order<T>,
std::less<T>> less;
};
Otherwise, we wait for the "Concept-ified" STL, at which point we will
probably break lots of things, so we could break map<> et al then.
Regards,
> &rzej
>
>
>
I am supportive of anything that will "fix" map's use of less, and return
less to meaning *exactly* the same as "call < for me".
Tony
P.S. optional (and expected) should maybe still have <, as one of the
stated design goals is "to be as similar to T as possible".
If we don't want optional to have <, then let's just overload
std::less<optional<T>>. and not implement <, and be done with it. I'd be
OK with that.
Basically, we need to decide if "like T" is an attainable design goal (and
without overloaded operator . it isn't), and whether getting half-way there
is a benefit or a hindrance.
--=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/.
--001a11c33d70f6e74904ff6b77b7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jul 30, 2014 at 9:25 AM, Andrzej Krzemie=C5=84ski <span dir=
=3D"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzem=
i1@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">Hi Every=
one,<br><br>TL;DR: A new functor std::order that would be used in ordered c=
ontainers by default, and would work for std::complex.</div>
</blockquote><div>... <br></div><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">What do you think about such addition? Or is someth=
ing like this already considered in LEWG?<p>
</p></div></blockquote><div><br></div><div>"Considered"? Yes.=C2=
=A0 Formally Proposed? Not that I know of.<br><br></div><div>Alisdair and I=
promised each other to work together on it in order to prevent either of u=
s from procrastinating on it.=C2=A0 Guess what, we are both too good at pro=
crastination.<br>
<br></div><div>One thing to keep in mind - we can't just do std::order =
and then say "map now uses std::order by default", as this has ba=
ckwards compatibility issues.<br><br>ie every map<X> that was map<=
X, std::less<X>> can't change to map<X, std::order<X>=
>, because that will break ABI somewhere, and who knows what else.<br>
<br>Instead, we need another level of indirection (which solves everything,=
right?):<br><br></div><div>map<> needs to become<br><br></div><div>t=
emplate<typename T, typename Ordering =3D std::lookup_order<T>::or=
der><br>
</div><div>class map ....;<br><br></div><div>and std::lookup_order is<br><b=
r></div><div>template <typename T><br></div><div>struct lookup_order<=
br>{<br></div><div>=C2=A0=C2=A0=C2=A0 typedef std::less<T> less;<br><=
/div><div>};<br>
<br></div><div>And then you overload lookup_order.<br></div><div>Or maybe l=
ookup_order can somehow test whether std::order has been specialized or not=
:<br><br><div>template <typename T><br></div><div>struct lookup_order=
<br>
{<br></div><div>=C2=A0=C2=A0=C2=A0 typedef if_c<std_order_specialized_ma=
gic<T>::value, std::order<T>, std::less<T>> less;<br><=
/div>};<br><br><br></div><div>Otherwise, we wait for the "Concept-ifie=
d" STL, at which point we will probably break lots of things, so we co=
uld break map<> et al then.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><p>Regards,<br>&rzej<span class=3D""><font color=3D"#888888"><br></fo=
nt></span></p>
</div><span class=3D""><font color=3D"#888888">
<p></p></font></span><br></blockquote></div><br></div><div class=3D"gmail_e=
xtra">I am supportive of anything that will "fix" map's use o=
f less, and return less to meaning *exactly* the same as=C2=A0 "call &=
lt; for me".<br>
</div><div class=3D"gmail_extra">Tony<br><br>P.S. optional (and expected) s=
hould maybe still have <, as one of the stated design goals is "to =
be as similar to T as possible".<br></div><div class=3D"gmail_extra">I=
f we don't want optional to have <, then let's just overload std=
::less<optional<T>>. and not implement <, and be done with i=
t.=C2=A0 I'd be OK with that.<br>
</div><div class=3D"gmail_extra">Basically, we need to decide if "like=
T" is an attainable design goal (and without overloaded operator . it=
isn't), and whether getting half-way there is a benefit or a hindrance=
..<br>
<br></div><br><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 <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 />
--001a11c33d70f6e74904ff6b77b7--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 30 Jul 2014 19:20:55 +0300
Raw View
On 30 July 2014 19:15, Tony V E <tvaneerd@gmail.com> wrote:
> P.S. optional (and expected) should maybe still have <, as one of the stated
> design goals is "to be as similar to T as possible".
> If we don't want optional to have <, then let's just overload
> std::less<optional<T>>. and not implement <, and be done with it. I'd be OK
And after you're done with that, remember to do equal_to<optional<T>> as well.
> Basically, we need to decide if "like T" is an attainable design goal (and
> without overloaded operator . it isn't), and whether getting half-way there
> is a benefit or a hindrance.
Funny, it seems to me that LEWG has decided that a couple of times already.
--
---
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/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 30 Jul 2014 12:40:45 -0400
Raw View
--001a113474cc53f61c04ff6bd1b8
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 30, 2014 at 12:20 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 30 July 2014 19:15, Tony V E <tvaneerd@gmail.com> wrote:
> > P.S. optional (and expected) should maybe still have <, as one of the
> stated
> > design goals is "to be as similar to T as possible".
> > If we don't want optional to have <, then let's just overload
> > std::less<optional<T>>. and not implement <, and be done with it. I'd
> be OK
>
> And after you're done with that, remember to do equal_to<optional<T>> as
> well.
>
> > Basically, we need to decide if "like T" is an attainable design goal
> (and
> > without overloaded operator . it isn't), and whether getting half-way
> there
> > is a benefit or a hindrance.
>
>
> Funny, it seems to me that LEWG has decided that a couple of times already.
>
>
What did it decide? benefit or hindrance? both?
Seems to have decided half-way there.
Yes, I agree they have decided a number of times.
--
---
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/.
--001a113474cc53f61c04ff6bd1b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jul 30, 2014 at 12:20 PM, Ville Voutilainen <span dir=3D"lt=
r"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vil=
le.voutilainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 30 July 2014 19:15, Tony =
V E <<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wr=
ote:<br>
> P.S. optional (and expected) should maybe still have <, as one of t=
he stated<br>
> design goals is "to be as similar to T as possible".<br>
> If we don't want optional to have <, then let's just overlo=
ad<br>
> std::less<optional<T>>. and not implement <, and be don=
e with it. =C2=A0I'd be OK<br>
<br>
</div>And after you're done with that, remember to do equal_to<optio=
nal<T>> as well.<br>
<div class=3D""><br>
> Basically, we need to decide if "like T" is an attainable de=
sign goal (and<br>
> without overloaded operator . it isn't), and whether getting half-=
way there<br>
> is a benefit or a hindrance.<br>
<br>
<br>
</div>Funny, it seems to me that LEWG has decided that a couple of times al=
ready.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>What did it decide? benefit or hindrance? both?<br>Seems to h=
ave decided half-way there.<br></div></div><br></div><div class=3D"gmail_ex=
tra">
Yes, I agree they have decided a number of times.<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 <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 />
--001a113474cc53f61c04ff6bd1b8--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 30 Jul 2014 19:43:11 +0300
Raw View
On 30 July 2014 19:40, Tony V E <tvaneerd@gmail.com> wrote:
>> > Basically, we need to decide if "like T" is an attainable design goal
>> > (and
>> > without overloaded operator . it isn't), and whether getting half-way
>> > there
>> > is a benefit or a hindrance.
>> Funny, it seems to me that LEWG has decided that a couple of times
>> already.
> What did it decide? benefit or hindrance? both?
> Seems to have decided half-way there.
Thus far it seems to me that LEWG has decided to include the relational
operators. So I don't know who's this "we" who need to decide it yet
again.
> Yes, I agree they have decided a number of times.
I expect they will decide a couple more times. :) Unless, of course, people
stop rehashing every single part of the design, but perhaps that's too high
a hope.
--
---
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/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 30 Jul 2014 13:02:26 -0400
Raw View
--089e0117744bdc824c04ff6c1e06
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 30, 2014 at 12:43 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 30 July 2014 19:40, Tony V E <tvaneerd@gmail.com> wrote:
> >> > Basically, we need to decide if "like T" is an attainable design goal
> >> > (and
> >> > without overloaded operator . it isn't), and whether getting half-way
> >> > there
> >> > is a benefit or a hindrance.
> >> Funny, it seems to me that LEWG has decided that a couple of times
> >> already.
> > What did it decide? benefit or hindrance? both?
> > Seems to have decided half-way there.
>
> Thus far it seems to me that LEWG has decided to include the relational
> operators.
Well LEWG decided to do it one way, then LWG decided to do it the other
way. But I'm not bitter. :-)
> So I don't know who's this "we" who need to decide it yet
> again.
>
> > Yes, I agree they have decided a number of times.
>
> I expect they will decide a couple more times. :) Unless, of course, people
> stop rehashing every single part of the design, but perhaps that's too high
> a hope.
>
>
Well, once it moves from TS to standard, we can _maybe_ stop.
--
---
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/.
--089e0117744bdc824c04ff6c1e06
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jul 30, 2014 at 12:43 PM, Ville Voutilainen <span dir=3D"lt=
r"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vil=
le.voutilainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 30 July 2014 19:40, Tony =
V E <<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wr=
ote:<br>
>> > Basically, we need to decide if "like T" is an atta=
inable design goal<br>
>> > (and<br>
>> > without overloaded operator . it isn't), and whether gett=
ing half-way<br>
>> > there<br>
>> > is a benefit or a hindrance.<br>
>> Funny, it seems to me that LEWG has decided that a couple of times=
<br>
>> already.<br>
> What did it decide? benefit or hindrance? both?<br>
> Seems to have decided half-way there.<br>
<br>
</div>Thus far it seems to me that LEWG has decided to include the relation=
al<br>
operators.</blockquote><div><br></div><div>Well LEWG decided to do it one w=
ay, then LWG decided to do it the other way.=C2=A0 But I'm not bitter. =
:-)<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I don't know who's this "we" who need to decide it ye=
t<br>
again.<br>
<div class=3D""><br>
> Yes, I agree they have decided a number of times.<br>
<br>
</div>I expect they will decide a couple more times. :) Unless, of course, =
people<br>
stop rehashing every single part of the design, but perhaps that's too =
high<br>
a hope.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>Well, once it moves from TS to standard, we can _maybe_ stop.=
<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 <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 />
--089e0117744bdc824c04ff6c1e06--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Thu, 31 Jul 2014 10:00:56 -0700
Raw View
Ville Voutilainen <ville.voutilainen@gmail.com> writes:
| > Basically, we need to decide if "like T" is an attainable design goal (and
| > without overloaded operator . it isn't), and whether getting half-way there
| > is a benefit or a hindrance.
|
|
| Funny, it seems to me that LEWG has decided that a couple of times already.
Jamais deux sans trois.
-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 31 Jul 2014 20:05:11 +0300
Raw View
On 31 July 2014 20:00, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> Ville Voutilainen <ville.voutilainen@gmail.com> writes:
>
> | > Basically, we need to decide if "like T" is an attainable design goal (and
> | > without overloaded operator . it isn't), and whether getting half-way there
> | > is a benefit or a hindrance.
> |
> |
> | Funny, it seems to me that LEWG has decided that a couple of times already.
>
> Jamais deux sans trois.
Oui, mon ami. And now the mandatory piece: excusez moi, je ne parle
pas francais.
--
---
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/.
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Thu, 31 Jul 2014 12:26:43 -0700
Raw View
Ville Voutilainen <ville.voutilainen@gmail.com> writes:
| On 31 July 2014 20:00, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
| > Ville Voutilainen <ville.voutilainen@gmail.com> writes:
| >
| > | > Basically, we need to decide if "like T" is an attainable design goal (and
| > | > without overloaded operator . it isn't), and whether getting
| > | > half-way there
| > | > is a benefit or a hindrance.
| > |
| > |
| > | Funny, it seems to me that LEWG has decided that a couple of times already.
| >
| > Jamais deux sans trois.
|
| Oui, mon ami. And now the mandatory piece: excusez moi, je ne parle
| pas francais.
:-) :-)
-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.