--001a1139587836455205319cf680
Content-Type: text/plain; charset=UTF-8

There has been some discussion about adding compiler generated comparison
operators to C++.

One area of contention seems to be whether they should be opt-in or opt-out.

A concern of the opt-out-ers is the impact that compiler generated
comparisons would have on existing code. There may be classes in place
where a compiler generated comparison would not behave appropriately.

In most code bases I have worked on 'struct' is used for simple objects
that are little more than data with no complicated logic.
Compiler-generated comparison operators would work well for such cases.

I wonder how people would feel if the compiler generated default comparison
operators for structs only, not for classes? This gives an opt-in/opt-out
without adding extra syntax or verbosity.

Regards,

Jonathan

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD9K%3DqWbK2kA%2B8f3oMi%3Dyz6HFCO_CJAuDOvzCML0o%3DtJqA%40mail.gmail.com.

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

<div dir=3D"ltr">There has been some discussion about adding compiler gener=
ated comparison operators to C++.<div><br></div><div>One area of contention=
 seems to be whether they should be opt-in or opt-out.</div><div><br></div>=
<div>A concern of the opt-out-ers is the impact that compiler generated com=
parisons would have on existing code. There may be classes in place where a=
 compiler generated comparison would not behave appropriately.</div><div><b=
r></div><div>In most code bases I have worked on &#39;struct&#39; is used f=
or simple objects that are little more than data with no complicated logic.=
 Compiler-generated comparison operators would work well for such cases.</d=
iv><div><br></div><div>I wonder how people would feel if the compiler gener=
ated default comparison operators for structs only, not for classes? This g=
ives an opt-in/opt-out without adding extra syntax or verbosity.</div><div>=
<br></div><div>Regards,</div><div><br></div><div>Jonathan</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD9K%3DqWbK2kA%2B8f3oMi%3Dyz6HFC=
O_CJAuDOvzCML0o%3DtJqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD9K=
%3DqWbK2kA%2B8f3oMi%3Dyz6HFCO_CJAuDOvzCML0o%3DtJqA%40mail.gmail.com</a>.<br=
 />

--001a1139587836455205319cf680--

.

On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
> There has been some discussion about adding compiler generated comparison
> operators to C++.
>
> One area of contention seems to be whether they should be opt-in or opt-out.
>
> A concern of the opt-out-ers is the impact that compiler generated
> comparisons would have on existing code. There may be classes in place where
> a compiler generated comparison would not behave appropriately.
>
> In most code bases I have worked on 'struct' is used for simple objects that
> are little more than data with no complicated logic. Compiler-generated
> comparison operators would work well for such cases.
>
> I wonder how people would feel if the compiler generated default comparison
> operators for structs only, not for classes? This gives an opt-in/opt-out
> without adding extra syntax or verbosity.


It would be most unfortunate to go into a direction that makes structs
and classes different. In addition, that
doesn't help, because e.g. struct tm would still have generated
operators that are horribly incorrect. I have no
doubt there are many many structs like that in the wild.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa-eb3oj0D4b7djP-Bc1r%3D4FDkk%2BZk1WLRfUZJrm1q0TQ%40mail.gmail.com.

.

> On 29 Apr 2016, at 11:53, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
>> There has been some discussion about adding compiler generated comparison
>> operators to C++.
>>
>> One area of contention seems to be whether they should be opt-in or opt-out.
>>
>> A concern of the opt-out-ers is the impact that compiler generated
>> comparisons would have on existing code. There may be classes in place where
>> a compiler generated comparison would not behave appropriately.
>>
>> In most code bases I have worked on 'struct' is used for simple objects that
>> are little more than data with no complicated logic. Compiler-generated
>> comparison operators would work well for such cases.
>>
>> I wonder how people would feel if the compiler generated default comparison
>> operators for structs only, not for classes? This gives an opt-in/opt-out
>> without adding extra syntax or verbosity.
>
>
> It would be most unfortunate to go into a direction that makes structs
> and classes different. In addition, that
> doesn't help, because e.g. struct tm would still have generated
> operators that are horribly incorrect. I have no
> doubt there are many many structs like that in the wild.
>

No doubt the struct/class distinction would leave some damage in its wake but less damage than uniformly applying compiler generated comparators might do.

Is preserving the non-distinction between structs and classes a useful aim? The distinction I propose would not change the meaning of existing code.

> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa-eb3oj0D4b7djP-Bc1r%3D4FDkk%2BZk1WLRfUZJrm1q0TQ%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/A08C91D8-72EE-4B27-946A-FDB5B348C507%40gmail.com.

.

On 30 April 2016 at 02:20, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>
>
>> On 29 Apr 2016, at 11:53, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>
>>> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
>>> There has been some discussion about adding compiler generated comparison
>>> operators to C++.
>>>
>>> One area of contention seems to be whether they should be opt-in or opt-out.
>>>
>>> A concern of the opt-out-ers is the impact that compiler generated
>>> comparisons would have on existing code. There may be classes in place where
>>> a compiler generated comparison would not behave appropriately.
>>>
>>> In most code bases I have worked on 'struct' is used for simple objects that
>>> are little more than data with no complicated logic. Compiler-generated
>>> comparison operators would work well for such cases.
>>>
>>> I wonder how people would feel if the compiler generated default comparison
>>> operators for structs only, not for classes? This gives an opt-in/opt-out
>>> without adding extra syntax or verbosity.
>>
>>
>> It would be most unfortunate to go into a direction that makes structs
>> and classes different. In addition, that
>> doesn't help, because e.g. struct tm would still have generated
>> operators that are horribly incorrect. I have no
>> doubt there are many many structs like that in the wild.
>>
>
> No doubt the struct/class distinction would leave some damage in its wake but less damage than uniformly applying compiler generated comparators might do.
>
> Is preserving the non-distinction between structs and classes a useful aim? The distinction I propose would not change the meaning of existing code.


If that's your claim, then please clarify what your suggestion would
do for struct tm and its ilk.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZMDUOFtO1325cZHaXPHmFnACu%3DH4v4SZYu6g_qQrxEZQ%40mail.gmail.com.

.

> On 30 Apr 2016, at 00:26, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> On 30 April 2016 at 02:20, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>>
>>
>>>> On 29 Apr 2016, at 11:53, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>>>
>>>> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
>>>> There has been some discussion about adding compiler generated comparison
>>>> operators to C++.
>>>>
>>>> One area of contention seems to be whether they should be opt-in or opt-out.
>>>>
>>>> A concern of the opt-out-ers is the impact that compiler generated
>>>> comparisons would have on existing code. There may be classes in place where
>>>> a compiler generated comparison would not behave appropriately.
>>>>
>>>> In most code bases I have worked on 'struct' is used for simple objects that
>>>> are little more than data with no complicated logic. Compiler-generated
>>>> comparison operators would work well for such cases.
>>>>
>>>> I wonder how people would feel if the compiler generated default comparison
>>>> operators for structs only, not for classes? This gives an opt-in/opt-out
>>>> without adding extra syntax or verbosity.
>>>
>>>
>>> It would be most unfortunate to go into a direction that makes structs
>>> and classes different. In addition, that
>>> doesn't help, because e.g. struct tm would still have generated
>>> operators that are horribly incorrect. I have no
>>> doubt there are many many structs like that in the wild.
>>
>> No doubt the struct/class distinction would leave some damage in its wake but less damage than uniformly applying compiler generated comparators might do.
>>
>> Is preserving the non-distinction between structs and classes a useful aim? The distinction I propose would not change the meaning of existing code.
>
>
> If that's your claim, then please clarify what your suggestion would
> do for struct tm and its ilk.

It would do the wrong thing and generate comparison operators. They would not be used in any existing code but their generation would render code fragile to future changes.
This is far from perfect. Fixes would be needed but, as I understand it, that's the case with the current proposals for compiler-generated comparison operators too. Attaching meaning to struct/class does not make anything worse.

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZMDUOFtO1325cZHaXPHmFnACu%3DH4v4SZYu6g_qQrxEZQ%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0769A370-3512-410A-89AE-202BD3E48787%40gmail.com.

.

--001a1134cff24b8ef70531ae6577
Content-Type: text/plain; charset=UTF-8

On 29 April 2016 at 05:18, Jonathan Coe <jbcoe@me.com> wrote:

> In most code bases I have worked on 'struct' is used for simple objects
> that are little more than data with no complicated logic.
>

And that is a tiny, tiny part of the world.

We don't need subtle ways to opt in / opt out of this; that is strictly
worse than all proposals to date.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMuiVb044PQ3x%3DrBYBJvme-EKKTPd4cp%3DrJiJ369BXDAA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 29 April 2016 at 05:18, Jona=
than Coe <span dir=3D"ltr">&lt;<a href=3D"mailto:jbcoe@me.com" target=3D"_b=
lank">jbcoe@me.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>In most code bases I have worked on &#39;st=
ruct&#39; is used for simple objects that are little more than data with no=
 complicated logic.</div><div></div></blockquote></div><br>And that is a ti=
ny, tiny part of the world.</div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">We don&#39;t need subtle ways to opt in / opt out of =
this; that is strictly worse than all proposals to date.<br>-- <br><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Ne=
vin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilover=
lord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691=
-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMuiVb044PQ3x%3DrBYBJvme-EKKT=
Pd4cp%3DrJiJ369BXDAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMu=
iVb044PQ3x%3DrBYBJvme-EKKTPd4cp%3DrJiJ369BXDAA%40mail.gmail.com</a>.<br />

--001a1134cff24b8ef70531ae6577--

.

--001a113cddecab8c820531ae6cf7
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 29, 2016 at 3:53 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
> > There has been some discussion about adding compiler generated comparison
> > operators to C++.
> >
> > One area of contention seems to be whether they should be opt-in or
> opt-out.
> >
> > A concern of the opt-out-ers is the impact that compiler generated
> > comparisons would have on existing code. There may be classes in place
> where
> > a compiler generated comparison would not behave appropriately.
> >
> > In most code bases I have worked on 'struct' is used for simple objects
> that
> > are little more than data with no complicated logic. Compiler-generated
> > comparison operators would work well for such cases.
> >
> > I wonder how people would feel if the compiler generated default
> comparison
> > operators for structs only, not for classes? This gives an opt-in/opt-out
> > without adding extra syntax or verbosity.
>
>
> It would be most unfortunate to go into a direction that makes structs
> and classes different. In addition, that
> doesn't help, because e.g. struct tm would still have generated
> operators that are horribly incorrect. I have no
> doubt there are many many structs like that in the wild.
>

+1 Let's not make different rules for structs and classes.

Regarding the topic of whether they should be opt-in or opt-out, I have a
feeling that we may be worrying too much one way or the other. I've always
personally been of the opinion that basically all auto-generated functions
should be opt-in instead of opt-out (I don't even think opt-in makes things
more verbose in general because the opposite is frequently the case --
programmers often start a new type by deleting copy/move until they need
it, which requires being explicit), however, if we have opt-out, people
will just learn to delete them as they already do with the
automatically-generated special member functions and that's probably fine.
I would rather either have always opt-in or always opt-out than have some
kind of different behavior for struct and class.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEm93G4weYTATBPWJBfF%3D3Qr2TtEYqjCuM%3D%2BbTj7LDWtzA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 29, 2016 at 3:53 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 29 April 2016 at 13:18, Jonathan Coe &lt;<a href=3D"mailto:jbc=
oe@me.com">jbcoe@me.com</a>&gt; wrote:<br>
&gt; There has been some discussion about adding compiler generated compari=
son<br>
&gt; operators to C++.<br>
&gt;<br>
&gt; One area of contention seems to be whether they should be opt-in or op=
t-out.<br>
&gt;<br>
&gt; A concern of the opt-out-ers is the impact that compiler generated<br>
&gt; comparisons would have on existing code. There may be classes in place=
 where<br>
&gt; a compiler generated comparison would not behave appropriately.<br>
&gt;<br>
&gt; In most code bases I have worked on &#39;struct&#39; is used for simpl=
e objects that<br>
&gt; are little more than data with no complicated logic. Compiler-generate=
d<br>
&gt; comparison operators would work well for such cases.<br>
&gt;<br>
&gt; I wonder how people would feel if the compiler generated default compa=
rison<br>
&gt; operators for structs only, not for classes? This gives an opt-in/opt-=
out<br>
&gt; without adding extra syntax or verbosity.<br>
<br>
<br>
</span>It would be most unfortunate to go into a direction that makes struc=
ts<br>
and classes different. In addition, that<br>
doesn&#39;t help, because e.g. struct tm would still have generated<br>
operators that are horribly incorrect. I have no<br>
doubt there are many many structs like that in the wild.<br></blockquote><d=
iv><br></div><div>+1 Let&#39;s not make different rules for structs and cla=
sses.</div><div><br></div><div>Regarding the topic of whether they should b=
e opt-in or opt-out, I have a feeling that we may be worrying too much one =
way or the other. I&#39;ve always personally been of the opinion that basic=
ally all auto-generated functions should be opt-in instead of opt-out (I do=
n&#39;t even think opt-in makes things more verbose in general because the =
opposite is frequently the case -- programmers often start a new type by de=
leting copy/move until they need it, which requires being explicit), howeve=
r, if we have opt-out, people will just learn to delete them as they alread=
y do with the automatically-generated special member functions and that&#39=
;s probably fine. I would rather either have always opt-in or always opt-ou=
t than have some kind of different behavior for struct and class.</div></di=
v></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEm93G4weYTATBPWJBfF%3D3Qr2TtEYq=
jCuM%3D%2BbTj7LDWtzA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEm93G=
4weYTATBPWJBfF%3D3Qr2TtEYqjCuM%3D%2BbTj7LDWtzA%40mail.gmail.com</a>.<br />

--001a113cddecab8c820531ae6cf7--

.

--Apple-Mail-4E48CCEA-E32D-4597-B8EF-C3DEAD21FF5D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



> On 30 Apr 2016, at 08:08, 'Matt Calabrese' via ISO C++ Standard - Future =
Proposals <std-proposals@isocpp.org> wrote:
>=20
>> On Fri, Apr 29, 2016 at 3:53 AM, Ville Voutilainen <ville.voutilainen@gm=
ail.com> wrote:
>> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
>> > There has been some discussion about adding compiler generated compari=
son
>> > operators to C++.
>> >
>> > One area of contention seems to be whether they should be opt-in or op=
t-out.
>> >
>> > A concern of the opt-out-ers is the impact that compiler generated
>> > comparisons would have on existing code. There may be classes in place=
 where
>> > a compiler generated comparison would not behave appropriately.
>> >
>> > In most code bases I have worked on 'struct' is used for simple object=
s that
>> > are little more than data with no complicated logic. Compiler-generate=
d
>> > comparison operators would work well for such cases.
>> >
>> > I wonder how people would feel if the compiler generated default compa=
rison
>> > operators for structs only, not for classes? This gives an opt-in/opt-=
out
>> > without adding extra syntax or verbosity.
>>=20
>>=20
>> It would be most unfortunate to go into a direction that makes structs
>> and classes different. In addition, that
>> doesn't help, because e.g. struct tm would still have generated
>> operators that are horribly incorrect. I have no
>> doubt there are many many structs like that in the wild.
>=20
> +1 Let's not make different rules for structs and classes.
>=20

Why not? This feels like a free keyword to me.

> Regarding the topic of whether they should be opt-in or opt-out, I have a=
 feeling that we may be worrying too much one way or the other. I've always=
 personally been of the opinion that basically all auto-generated functions=
 should be opt-in instead of opt-out (I don't even think opt-in makes thing=
s more verbose in general because the opposite is frequently the case -- pr=
ogrammers often start a new type by deleting copy/move until they need it, =
which requires being explicit), however, if we have opt-out, people will ju=
st learn to delete them as they already do with the automatically-generated=
 special member functions and that's probably fine. I would rather either h=
ave always opt-in or always opt-out than have some kind of different behavi=
or for struct and class.
> --=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=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CANh8DEm93G4weYTATBPWJBfF%3D3Qr2TtEYqjCuM%3D%2=
BbTj7LDWtzA%40mail.gmail.com.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0CFA0B75-7D5C-42B0-9510-4EB588427B26%40gmail.com=
..

--Apple-Mail-4E48CCEA-E32D-4597-B8EF-C3DEAD21FF5D
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div><br>On 3=
0 Apr 2016, at 08:08, 'Matt Calabrese' via ISO C++ Standard - Future Propos=
als &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.or=
g</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, Apr 29, 20=
16 at 3:53 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:vi=
lle.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2=
9 April 2016 at 13:18, Jonathan Coe &lt;<a href=3D"mailto:jbcoe@me.com">jbc=
oe@me.com</a>&gt; wrote:<br>
&gt; There has been some discussion about adding compiler generated compari=
son<br>
&gt; operators to C++.<br>
&gt;<br>
&gt; One area of contention seems to be whether they should be opt-in or op=
t-out.<br>
&gt;<br>
&gt; A concern of the opt-out-ers is the impact that compiler generated<br>
&gt; comparisons would have on existing code. There may be classes in place=
 where<br>
&gt; a compiler generated comparison would not behave appropriately.<br>
&gt;<br>
&gt; In most code bases I have worked on 'struct' is used for simple object=
s that<br>
&gt; are little more than data with no complicated logic. Compiler-generate=
d<br>
&gt; comparison operators would work well for such cases.<br>
&gt;<br>
&gt; I wonder how people would feel if the compiler generated default compa=
rison<br>
&gt; operators for structs only, not for classes? This gives an opt-in/opt-=
out<br>
&gt; without adding extra syntax or verbosity.<br>
<br>
<br>
</span>It would be most unfortunate to go into a direction that makes struc=
ts<br>
and classes different. In addition, that<br>
doesn't help, because e.g. struct tm would still have generated<br>
operators that are horribly incorrect. I have no<br>
doubt there are many many structs like that in the wild.<br></blockquote><d=
iv><br></div><div>+1 Let's not make different rules for structs and classes=
..</div><div><br></div></div></div></div></div></blockquote><div><br></div><=
div>Why not? This feels like a free keyword to me.</div><br><blockquote typ=
e=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>Regarding the topic of whether they should be opt-in or op=
t-out, I have a feeling that we may be worrying too much one way or the oth=
er. I've always personally been of the opinion that basically all auto-gene=
rated functions should be opt-in instead of opt-out (I don't even think opt=
-in makes things more verbose in general because the opposite is frequently=
 the case -- programmers often start a new type by deleting copy/move until=
 they need it, which requires being explicit), however, if we have opt-out,=
 people will just learn to delete them as they already do with the automati=
cally-generated special member functions and that's probably fine. I would =
rather either have always opt-in or always opt-out than have some kind of d=
ifferent behavior for struct and class.</div></div></div></div>

<p></p>

-- <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 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEm93G4weYTATBPWJBfF%3D3Qr2TtEYq=
jCuM%3D%2BbTj7LDWtzA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE=
m93G4weYTATBPWJBfF%3D3Qr2TtEYqjCuM%3D%2BbTj7LDWtzA%40mail.gmail.com</a>.<br=
>
</div></blockquote></body></html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0CFA0B75-7D5C-42B0-9510-4EB588427B26%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0CFA0B75-7D5C-42B0-9510-4EB588427B26%=
40gmail.com</a>.<br />

--Apple-Mail-4E48CCEA-E32D-4597-B8EF-C3DEAD21FF5D--

.

--001a113603be95ac680531b00698
Content-Type: text/plain; charset=UTF-8

On 30 April 2016 at 03:11, Jonathan Coe <jonathanbcoe@gmail.com> wrote:

>
> +1 Let's not make different rules for structs and classes.
>
>
> Why not? This feels like a free keyword to me.
>

How to spell "opt-in" or "opt-out" has not been the issue.  We really don't
need to make C++ more expert-only than it already is.

Default comparison operators is a feature I want.  So far, the only thing
that would have gotten me to vote strongly against it (as opposed to voting
for it) was back when mutable members would have been skipped, and that
concern has since been addressed.  If class and struct had different
behavior in this regard, I'd have to again move from wanting this feature
to being strongly against it.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMSG7U5cZM_pbPWEf0eYzyVDSs%3DHt%2BcO6HBdZXU46HuRw%40mail.gmail.com.

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

<div dir=3D"ltr">On 30 April 2016 at 03:11, Jonathan Coe <span dir=3D"ltr">=
&lt;<a href=3D"mailto:jonathanbcoe@gmail.com" target=3D"_blank">jonathanbco=
e@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span cla=
ss=3D""><div></div><div><br></div><blockquote type=3D"cite"><div><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>+1 Let&=
#39;s not make different rules for structs and classes.</div><div><br></div=
></div></div></div></div></blockquote><div><br></div></span><div>Why not? T=
his feels like a free keyword to me.</div></div></blockquote><div><br></div=
><div>How to spell &quot;opt-in&quot; or &quot;opt-out&quot; has not been t=
he issue.=C2=A0 We really don&#39;t need to make C++ more expert-only than =
it already is.</div><div><br></div><div>Default comparison operators is a f=
eature I want.=C2=A0 So far, the only thing that would have gotten me to vo=
te strongly against it (as opposed to voting for it) was back when mutable =
members would have been skipped, and that concern has since been addressed.=
=C2=A0 If class and struct had different behavior in this regard, I&#39;d h=
ave to again move from wanting this feature to being strongly against it.</=
div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div =
dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMSG7U5cZM_pbPWEf0eYzyVDSs%3D=
Ht%2BcO6HBdZXU46HuRw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMS=
G7U5cZM_pbPWEf0eYzyVDSs%3DHt%2BcO6HBdZXU46HuRw%40mail.gmail.com</a>.<br />

--001a113603be95ac680531b00698--

.

On 30 April 2016 at 09:25, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>
>
>> On 30 Apr 2016, at 00:26, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>
>>> On 30 April 2016 at 02:20, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>>>
>>>
>>>>> On 29 Apr 2016, at 11:53, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>>>>
>>>>> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
>>>>> There has been some discussion about adding compiler generated comparison
>>>>> operators to C++.
>>>>>
>>>>> One area of contention seems to be whether they should be opt-in or opt-out.
>>>>>
>>>>> A concern of the opt-out-ers is the impact that compiler generated
>>>>> comparisons would have on existing code. There may be classes in place where
>>>>> a compiler generated comparison would not behave appropriately.
>>>>>
>>>>> In most code bases I have worked on 'struct' is used for simple objects that
>>>>> are little more than data with no complicated logic. Compiler-generated
>>>>> comparison operators would work well for such cases.
>>>>>
>>>>> I wonder how people would feel if the compiler generated default comparison
>>>>> operators for structs only, not for classes? This gives an opt-in/opt-out
>>>>> without adding extra syntax or verbosity.
>>>>
>>>>
>>>> It would be most unfortunate to go into a direction that makes structs
>>>> and classes different. In addition, that
>>>> doesn't help, because e.g. struct tm would still have generated
>>>> operators that are horribly incorrect. I have no
>>>> doubt there are many many structs like that in the wild.
>>>
>>> No doubt the struct/class distinction would leave some damage in its wake but less damage than uniformly applying compiler generated comparators might do.
>>>
>>> Is preserving the non-distinction between structs and classes a useful aim? The distinction I propose would not change the meaning of existing code.
>>
>>
>> If that's your claim, then please clarify what your suggestion would
>> do for struct tm and its ilk.
>
> It would do the wrong thing and generate comparison operators. They would not be used in any existing code but their generation would render code fragile to future changes.
> This is far from perfect. Fixes would be needed but, as I understand it, that's the case with the current proposals for compiler-generated comparison operators too. Attaching meaning to struct/class does not make anything worse.


I fail to see how it makes anything better, if the aim was that for
some classes the generated operators behave inappropriately,
since they still would behave inappropriately for some structs.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYbG9TxOFKZhXzeBz2LMVFJRReQD-bb7zB23dntZ_va-g%40mail.gmail.com.

.

> On 30 Apr 2016, at 13:40, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> On 30 April 2016 at 09:25, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>>
>>
>>>> On 30 Apr 2016, at 00:26, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>>>
>>>> On 30 April 2016 at 02:20, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>>>>
>>>>
>>>>>> On 29 Apr 2016, at 11:53, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>>>>>
>>>>>> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
>>>>>> There has been some discussion about adding compiler generated comparison
>>>>>> operators to C++.
>>>>>>
>>>>>> One area of contention seems to be whether they should be opt-in or opt-out.
>>>>>>
>>>>>> A concern of the opt-out-ers is the impact that compiler generated
>>>>>> comparisons would have on existing code. There may be classes in place where
>>>>>> a compiler generated comparison would not behave appropriately.
>>>>>>
>>>>>> In most code bases I have worked on 'struct' is used for simple objects that
>>>>>> are little more than data with no complicated logic. Compiler-generated
>>>>>> comparison operators would work well for such cases.
>>>>>>
>>>>>> I wonder how people would feel if the compiler generated default comparison
>>>>>> operators for structs only, not for classes? This gives an opt-in/opt-out
>>>>>> without adding extra syntax or verbosity.
>>>>>
>>>>>
>>>>> It would be most unfortunate to go into a direction that makes structs
>>>>> and classes different. In addition, that
>>>>> doesn't help, because e.g. struct tm would still have generated
>>>>> operators that are horribly incorrect. I have no
>>>>> doubt there are many many structs like that in the wild.
>>>>
>>>> No doubt the struct/class distinction would leave some damage in its wake but less damage than uniformly applying compiler generated comparators might do.
>>>>
>>>> Is preserving the non-distinction between structs and classes a useful aim? The distinction I propose would not change the meaning of existing code.
>>>
>>>
>>> If that's your claim, then please clarify what your suggestion would
>>> do for struct tm and its ilk.
>>
>> It would do the wrong thing and generate comparison operators. They would not be used in any existing code but their generation would render code fragile to future changes.
>> This is far from perfect. Fixes would be needed but, as I understand it, that's the case with the current proposals for compiler-generated comparison operators too. Attaching meaning to struct/class does not make anything worse.
>
>
> I fail to see how it makes anything better, if the aim was that for
> some classes the generated operators behave inappropriately,
> since they still would behave inappropriately for some structs.
>

It would give opt in and opt out without introducing new key

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYbG9TxOFKZhXzeBz2LMVFJRReQD-bb7zB23dntZ_va-g%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/504AE43B-5CB3-497B-947F-D71E71519E55%40gmail.com.

.

> On 30 Apr 2016, at 14:11, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>
>
>
>>> On 30 Apr 2016, at 13:40, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>>
>>> On 30 April 2016 at 09:25, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>>>
>>>
>>>>> On 30 Apr 2016, at 00:26, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>>>>
>>>>> On 30 April 2016 at 02:20, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>> On 29 Apr 2016, at 11:53, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>>>>>>
>>>>>>> On 29 April 2016 at 13:18, Jonathan Coe <jbcoe@me.com> wrote:
>>>>>>> There has been some discussion about adding compiler generated comparison
>>>>>>> operators to C++.
>>>>>>>
>>>>>>> One area of contention seems to be whether they should be opt-in or opt-out.
>>>>>>>
>>>>>>> A concern of the opt-out-ers is the impact that compiler generated
>>>>>>> comparisons would have on existing code. There may be classes in place where
>>>>>>> a compiler generated comparison would not behave appropriately.
>>>>>>>
>>>>>>> In most code bases I have worked on 'struct' is used for simple objects that
>>>>>>> are little more than data with no complicated logic. Compiler-generated
>>>>>>> comparison operators would work well for such cases.
>>>>>>>
>>>>>>> I wonder how people would feel if the compiler generated default comparison
>>>>>>> operators for structs only, not for classes? This gives an opt-in/opt-out
>>>>>>> without adding extra syntax or verbosity.
>>>>>>
>>>>>>
>>>>>> It would be most unfortunate to go into a direction that makes structs
>>>>>> and classes different. In addition, that
>>>>>> doesn't help, because e.g. struct tm would still have generated
>>>>>> operators that are horribly incorrect. I have no
>>>>>> doubt there are many many structs like that in the wild.
>>>>>
>>>>> No doubt the struct/class distinction would leave some damage in its wake but less damage than uniformly applying compiler generated comparators might do.
>>>>>
>>>>> Is preserving the non-distinction between structs and classes a useful aim? The distinction I propose would not change the meaning of existing code.
>>>>
>>>>
>>>> If that's your claim, then please clarify what your suggestion would
>>>> do for struct tm and its ilk.
>>>
>>> It would do the wrong thing and generate comparison operators. They would not be used in any existing code but their generation would render code fragile to future changes.
>>> This is far from perfect. Fixes would be needed but, as I understand it, that's the case with the current proposals for compiler-generated comparison operators too. Attaching meaning to struct/class does not make anything worse.
>>
>>
>> I fail to see how it makes anything better, if the aim was that for
>> some classes the generated operators behave inappropriately,
>> since they still would behave inappropriately for some structs.
>>
>
> It would give opt in and opt out without introducing new key

Pressed send early.

It would give opt in and opt out without introducing new keywords. No one seems keen though. I won't suggest this for discussion at Oulu.
>
>> --
>> 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.
>> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYbG9TxOFKZhXzeBz2LMVFJRReQD-bb7zB23dntZ_va-g%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2785ECB5-1C7A-42F2-9F0B-40B35F3361F2%40gmail.com.

.

On 30 April 2016 at 16:12, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>>> I fail to see how it makes anything better, if the aim was that for
>>> some classes the generated operators behave inappropriately,
>>> since they still would behave inappropriately for some structs.
>>>
>>
>> It would give opt in and opt out without introducing new key
>
> Pressed send early.
>
> It would give opt in and opt out without introducing new keywords. No one seems keen though. I won't suggest this for discussion at Oulu.


Right, I still don't see how that would make anything better. Opting
in for a class by turning a class into a struct seems like
a rather heavy-weight opt-in mechanism. If we really end up wanting
opt-in, we probably have better ways to get it. :)

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbHt2nc5fdQmwUvn2Edbi%2BZnuOGcwit%3D51JPTH%3DvMereQ%40mail.gmail.com.

.

------=_Part_253_875596478.1462028386416
Content-Type: multipart/alternative;
 boundary="----=_Part_254_1848329342.1462028386416"

------=_Part_254_1848329342.1462028386416
Content-Type: text/plain; charset=UTF-8

On Saturday, April 30, 2016 at 4:11:51 AM UTC-4, Jonathan Coe wrote:
>
> On 30 Apr 2016, at 08:08, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
> On Fri, Apr 29, 2016 at 3:53 AM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On 29 April 2016 at 13:18, Jonathan Coe <jb...@me.com <javascript:>>
>> wrote:
>> > There has been some discussion about adding compiler generated
>> comparison
>> > operators to C++.
>> >
>> > One area of contention seems to be whether they should be opt-in or
>> opt-out.
>> >
>> > A concern of the opt-out-ers is the impact that compiler generated
>> > comparisons would have on existing code. There may be classes in place
>> where
>> > a compiler generated comparison would not behave appropriately.
>> >
>> > In most code bases I have worked on 'struct' is used for simple objects
>> that
>> > are little more than data with no complicated logic. Compiler-generated
>> > comparison operators would work well for such cases.
>> >
>> > I wonder how people would feel if the compiler generated default
>> comparison
>> > operators for structs only, not for classes? This gives an
>> opt-in/opt-out
>> > without adding extra syntax or verbosity.
>>
>>
>> It would be most unfortunate to go into a direction that makes structs
>> and classes different. In addition, that
>> doesn't help, because e.g. struct tm would still have generated
>> operators that are horribly incorrect. I have no
>> doubt there are many many structs like that in the wild.
>>
>
> +1 Let's not make different rules for structs and classes.
>
>
> Why not? This feels like a free keyword to me.
>

Default comparison as a feature is important and useful enough to *deserve*
the expense of adding a keyword for. If we decide that we need opt-in or
opt-out functionality (beyond the obvious, such as explicitly deleting the
operators), then we should add a keyword specifically for that.

The question is not how to spell it; it's whether we should have one at
all. *Especially* not if it creates a subtle distinction where none existed
before.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f283f562-e8a5-495f-a14e-f33b2fb0e19b%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, April 30, 2016 at 4:11:51 AM UTC-4, Jonathan =
Coe wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><d=
iv></div><div>On 30 Apr 2016, at 08:08, &#39;Matt Calabrese&#39; via ISO C+=
+ Standard - Future Proposals &lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"TPafZNjSBAAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">std-pr...@isocpp.org</a>&gt; wrote:<br></div><=
blockquote type=3D"cite"><div><div dir=3D"ltr"><div><div class=3D"gmail_quo=
te">On Fri, Apr 29, 2016 at 3:53 AM, Ville Voutilainen <span dir=3D"ltr">&l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"TPafZN=
jSBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">vil=
le.vo...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span>On 29 April 2016 at 13:18, Jonathan Coe &lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"TPafZNjSBAAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">jb...@me.com</a>&gt; wrote:<br=
>
&gt; There has been some discussion about adding compiler generated compari=
son<br>
&gt; operators to C++.<br>
&gt;<br>
&gt; One area of contention seems to be whether they should be opt-in or op=
t-out.<br>
&gt;<br>
&gt; A concern of the opt-out-ers is the impact that compiler generated<br>
&gt; comparisons would have on existing code. There may be classes in place=
 where<br>
&gt; a compiler generated comparison would not behave appropriately.<br>
&gt;<br>
&gt; In most code bases I have worked on &#39;struct&#39; is used for simpl=
e objects that<br>
&gt; are little more than data with no complicated logic. Compiler-generate=
d<br>
&gt; comparison operators would work well for such cases.<br>
&gt;<br>
&gt; I wonder how people would feel if the compiler generated default compa=
rison<br>
&gt; operators for structs only, not for classes? This gives an opt-in/opt-=
out<br>
&gt; without adding extra syntax or verbosity.<br>
<br>
<br>
</span>It would be most unfortunate to go into a direction that makes struc=
ts<br>
and classes different. In addition, that<br>
doesn&#39;t help, because e.g. struct tm would still have generated<br>
operators that are horribly incorrect. I have no<br>
doubt there are many many structs like that in the wild.<br></blockquote><d=
iv><br></div><div>+1 Let&#39;s not make different rules for structs and cla=
sses.</div></div></div></div></div></blockquote><div><br></div><div>Why not=
? This feels like a free keyword to me.</div></div></blockquote><div><br>De=
fault comparison as a feature is important and useful enough to <i>deserve<=
/i> the expense of adding a keyword for. If we decide that we need opt-in o=
r opt-out functionality (beyond the obvious, such as explicitly deleting th=
e operators), then we should add a keyword specifically for that.<br><br>Th=
e question is not how to spell it; it&#39;s whether we should have one at a=
ll. <i>Especially</i> not if it creates a subtle distinction where none exi=
sted before.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f283f562-e8a5-495f-a14e-f33b2fb0e19b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f283f562-e8a5-495f-a14e-f33b2fb0e19b=
%40isocpp.org</a>.<br />

------=_Part_254_1848329342.1462028386416--
------=_Part_253_875596478.1462028386416--

.

--001a11c33e6ca02e1c0531baaa80
Content-Type: text/plain; charset=UTF-8

Well, since we are on the subject,

Default == and != should be opt-out.  The generated == is almost always
correct.

Default < (et al) should be opt-in.  The generated < is usually nonsensical.

I will probably write a paper on this, and possibly make it an NB comment.


On Sat, Apr 30, 2016 at 10:59 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Saturday, April 30, 2016 at 4:11:51 AM UTC-4, Jonathan Coe wrote:
>>
>> On 30 Apr 2016, at 08:08, 'Matt Calabrese' via ISO C++ Standard - Future
>> Proposals <std-pr...@isocpp.org> wrote:
>>
>> On Fri, Apr 29, 2016 at 3:53 AM, Ville Voutilainen <ville.vo...@gmail.com
>> > wrote:
>>
>>> On 29 April 2016 at 13:18, Jonathan Coe <jb...@me.com> wrote:
>>> > There has been some discussion about adding compiler generated
>>> comparison
>>> > operators to C++.
>>> >
>>> > One area of contention seems to be whether they should be opt-in or
>>> opt-out.
>>> >
>>> > A concern of the opt-out-ers is the impact that compiler generated
>>> > comparisons would have on existing code. There may be classes in place
>>> where
>>> > a compiler generated comparison would not behave appropriately.
>>> >
>>> > In most code bases I have worked on 'struct' is used for simple
>>> objects that
>>> > are little more than data with no complicated logic. Compiler-generated
>>> > comparison operators would work well for such cases.
>>> >
>>> > I wonder how people would feel if the compiler generated default
>>> comparison
>>> > operators for structs only, not for classes? This gives an
>>> opt-in/opt-out
>>> > without adding extra syntax or verbosity.
>>>
>>>
>>> It would be most unfortunate to go into a direction that makes structs
>>> and classes different. In addition, that
>>> doesn't help, because e.g. struct tm would still have generated
>>> operators that are horribly incorrect. I have no
>>> doubt there are many many structs like that in the wild.
>>>
>>
>> +1 Let's not make different rules for structs and classes.
>>
>>
>> Why not? This feels like a free keyword to me.
>>
>
> Default comparison as a feature is important and useful enough to
> *deserve* the expense of adding a keyword for. If we decide that we need
> opt-in or opt-out functionality (beyond the obvious, such as explicitly
> deleting the operators), then we should add a keyword specifically for that.
>
> The question is not how to spell it; it's whether we should have one at
> all. *Especially* not if it creates a subtle distinction where none
> existed before.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f283f562-e8a5-495f-a14e-f33b2fb0e19b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f283f562-e8a5-495f-a14e-f33b2fb0e19b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitx9nysz6w%3D2bCgX89Ss422N%2BNAyb7QCi-TkKpeA5RWMg%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div>Well, since we are on the subject,<br><br><=
/div>Default =3D=3D and !=3D should be opt-out.=C2=A0 The generated =3D=3D =
is almost always correct.<br><br></div>Default &lt; (et al) should be opt-i=
n.=C2=A0 The generated &lt; is usually nonsensical.<br><br></div>I will pro=
bably write a paper on this, and possibly make it an NB comment.<br><br></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Apr 30=
, 2016 at 10:59 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmc=
kesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, April 30=
, 2016 at 4:11:51 AM UTC-4, Jonathan Coe wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"auto"><div></div><div>On 30 Apr 2016, at 08:08, &#3=
9;Matt Calabrese&#39; via ISO C++ Standard - Future Proposals &lt;<a rel=3D=
"nofollow">std-pr...@isocpp.org</a>&gt; wrote:<br></div><blockquote type=3D=
"cite"><div><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Apr 29=
, 2016 at 3:53 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a rel=3D"nofoll=
ow">ville.vo...@gmail.com</a>&gt;</span> wrote:<span class=3D""><br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span>On 29 April 2016 at 13:18, Jonathan Coe &lt;<=
a rel=3D"nofollow">jb...@me.com</a>&gt; wrote:<br>
&gt; There has been some discussion about adding compiler generated compari=
son<br>
&gt; operators to C++.<br>
&gt;<br>
&gt; One area of contention seems to be whether they should be opt-in or op=
t-out.<br>
&gt;<br>
&gt; A concern of the opt-out-ers is the impact that compiler generated<br>
&gt; comparisons would have on existing code. There may be classes in place=
 where<br>
&gt; a compiler generated comparison would not behave appropriately.<br>
&gt;<br>
&gt; In most code bases I have worked on &#39;struct&#39; is used for simpl=
e objects that<br>
&gt; are little more than data with no complicated logic. Compiler-generate=
d<br>
&gt; comparison operators would work well for such cases.<br>
&gt;<br>
&gt; I wonder how people would feel if the compiler generated default compa=
rison<br>
&gt; operators for structs only, not for classes? This gives an opt-in/opt-=
out<br>
&gt; without adding extra syntax or verbosity.<br>
<br>
<br>
</span>It would be most unfortunate to go into a direction that makes struc=
ts<br>
and classes different. In addition, that<br>
doesn&#39;t help, because e.g. struct tm would still have generated<br>
operators that are horribly incorrect. I have no<br>
doubt there are many many structs like that in the wild.<br></blockquote><d=
iv><br></div><div>+1 Let&#39;s not make different rules for structs and cla=
sses.</div></span></div></div></div></div></blockquote><span class=3D""><di=
v><br></div><div>Why not? This feels like a free keyword to me.</div></span=
></div></blockquote><div><br>Default comparison as a feature is important a=
nd useful enough to <i>deserve</i> the expense of adding a keyword for. If =
we decide that we need opt-in or opt-out functionality (beyond the obvious,=
 such as explicitly deleting the operators), then we should add a keyword s=
pecifically for that.<br><br>The question is not how to spell it; it&#39;s =
whether we should have one at all. <i>Especially</i> not if it creates a su=
btle distinction where none existed before.<br></div></div><span class=3D""=
>

<p></p>

-- <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" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f283f562-e8a5-495f-a14e-f33b2fb0e19b%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f283f562-e8a5-=
495f-a14e-f33b2fb0e19b%40isocpp.org</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitx9nysz6w%3D2bCgX89Ss422N%2BNA=
yb7QCi-TkKpeA5RWMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitx9nys=
z6w%3D2bCgX89Ss422N%2BNAyb7QCi-TkKpeA5RWMg%40mail.gmail.com</a>.<br />

--001a11c33e6ca02e1c0531baaa80--

.

------=_Part_708_303242690.1462067161524
Content-Type: multipart/alternative;
 boundary="----=_Part_709_963689371.1462067161524"

------=_Part_709_963689371.1462067161524
Content-Type: text/plain; charset=UTF-8

On Saturday, April 30, 2016 at 5:44:42 PM UTC-4, Tony V E wrote:
>
> Well, since we are on the subject,
>
> Default == and != should be opt-out.  The generated == is almost always
> correct.
>
> Default < (et al) should be opt-in.  The generated < is usually
> nonsensical.
>

There is a case where I think it's unquestionably justified to enforce the
generation of the other operators. Namely, if the user writes one of them.
If I give a type an `operator<`, then it's perfectly reasonable for the
compiler to fill in the blanks based on that.

There's no reason to make that case opt-in; I've expressed the intent to
make my type directionally comparable. I was just being lazy about it.

So the question is this. If your type is not directionally comparable
currently, is it *reasonable* to make it so? Is an element-wise less-than
comparison "nonsensical"?

Well, that rather depends on what you're using it for. There are quite a
few cases where the specific ordering for a type is essentially irrelevant.
What matters is that there is *some ordering*. And the subobject-wise
`operator<` will give you that. And this is not usually something you
design a type to be able to do; it often pops up as something you suddenly
need it to do.

Also, it's not like we don't have experience with this already. For example
`tuple` opts you into comparisons whether you want them or not. It doesn't
really hurt `tuple` for the type to provide this feature. `array` provides
it too. Does `operator<` for `array<float, 3>` mean anything? Does it cause
a problem by being there?

I guess the question is what the actual problem will be by generating such
operators?

I will probably write a paper on this, and possibly make it an NB comment.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/391eaec7-d320-4ce7-8982-08a69bbe91ac%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, April 30, 2016 at 5:44:42 PM UTC-4, Tony V E =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv><div>Well, since we are on the subject,<br><br></div>Default =3D=3D and =
!=3D should be opt-out.=C2=A0 The generated =3D=3D is almost always correct=
..<br><br></div>Default &lt; (et al) should be opt-in.=C2=A0 The generated &=
lt; is usually nonsensical.<br></div></div></blockquote><div><br>There is a=
 case where I think it&#39;s unquestionably justified to enforce the genera=
tion of the other operators. Namely, if the user writes one of them. If I g=
ive a type an `operator&lt;`, then it&#39;s perfectly reasonable for the co=
mpiler to fill in the blanks based on that.<br><br>There&#39;s no reason to=
 make that case opt-in; I&#39;ve expressed the intent to make my type direc=
tionally comparable. I was just being lazy about it.<br><br>So the question=
 is this. If your type is not directionally comparable currently, is it <i>=
reasonable</i> to make it so? Is an element-wise less-than comparison &quot=
;nonsensical&quot;?<br><br>Well, that rather depends on what you&#39;re usi=
ng it for. There are quite a few cases where the specific ordering for a ty=
pe is essentially irrelevant. What matters is that there is <i>some orderin=
g</i>. And the subobject-wise `operator&lt;` will give you that. And this i=
s not usually something you design a type to be able to do; it often pops u=
p as something you suddenly need it to do.<br><br>Also, it&#39;s not like w=
e don&#39;t have experience with this already. For example `tuple` opts you=
 into comparisons whether you want them or not. It doesn&#39;t really hurt =
`tuple` for the type to provide this feature. `array` provides it too. Does=
 `operator&lt;` for `array&lt;float, 3&gt;` mean anything? Does it cause a =
problem by being there?<br><br>I guess the question is what the actual prob=
lem will be by generating such operators?<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div></div>I will probably write =
a paper on this, and possibly make it an NB comment.</div></blockquote></di=
v>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/391eaec7-d320-4ce7-8982-08a69bbe91ac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/391eaec7-d320-4ce7-8982-08a69bbe91ac=
%40isocpp.org</a>.<br />

------=_Part_709_963689371.1462067161524--
------=_Part_708_303242690.1462067161524--

.

------=_Part_5409_1072705906.1462348418759
Content-Type: multipart/alternative;
 boundary="----=_Part_5410_586568425.1462348418760"

------=_Part_5410_586568425.1462348418760
Content-Type: text/plain; charset=UTF-8

I'm against at to differentiate class and struct. This makes the language
even more complex and confusing. And I think "[-Wmismatched-tags]" is
particularly annoying.
Further, I'm not a fan of the whole feature even if I know it solves an
important problem. But library can work in a more flexible and portable way
for most common cases of the problem here. I doubt anyone can easily
benefit from such disputable core language changes, for any reasons that a
library resolution would not suffer like core changes for such tasks, which
is often crucial in practice. So I tend to wait a systemic design of
reflection rather than to be a white mouse of the half-baked solution for
this particular problem.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0396586c-25ec-47b6-8a7d-19db82f0f6ae%40isocpp.org.

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

<div dir=3D"ltr">I&#39;m against at to differentiate class and struct. This=
 makes the language even more complex and confusing. And I think &quot;[-Wm=
ismatched-tags]&quot; is particularly annoying.<br>Further, I&#39;m not a f=
an of the whole feature even if I know it solves an important problem. But =
library can work in a more flexible and portable way for most common cases =
of the problem here. I doubt anyone can easily benefit from such disputable=
 core language changes, for any reasons that a library resolution would not=
 suffer like core changes for such tasks, which is often crucial in practic=
e. So I tend to wait a systemic design of reflection rather than to be a wh=
ite mouse of the half-baked solution for this particular problem.<br><br></=
div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0396586c-25ec-47b6-8a7d-19db82f0f6ae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0396586c-25ec-47b6-8a7d-19db82f0f6ae=
%40isocpp.org</a>.<br />

------=_Part_5410_586568425.1462348418760--
------=_Part_5409_1072705906.1462348418759--

.