--000000000000b68473056aafeb25
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018 at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com> wrote:
>
>> Also, it will only get into that state because some move-operation threw.
>>
>
> *cough*
>
> libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz
> libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST
>
>
>

Why doesn't variant revert back to the int when the copy throws?  We don't
want to pay for the moves?

--
Be seeing you,
Tony

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitzWkx%3D5N%3D-VOgfTL99UfismV2k2_P%2BKDHPf6zgdWarNw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Apr 25, 2018 at 10:40 AM, &#39;Matt Calabrese&#39; via ISO C++ =
Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-pro=
posals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><span class=3D""><div dir=3D"ltr">On Tue, Apr 24, 2018 at 1:32 =
PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tva=
neerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Also, it will on=
ly get into that state because some move-operation threw.</div></div></bloc=
kquote><div><br></div></span><div>*cough*=C2=A0</div><div><br></div><div>li=
bc++: <a href=3D"https://wandbox.org/permlink/0ag3V2oVa3MBcWmz" target=3D"_=
blank">https://wandbox.org/permlink/<wbr>0ag3V2oVa3MBcWmz</a></div><div>lib=
stdc++:=C2=A0<a href=3D"https://wandbox.org/permlink/LEUsrj9ir5vyVcST" targ=
et=3D"_blank">https://wandbox.<wbr>org/permlink/LEUsrj9ir5vyVcST</a></div><=
/div></div><span class=3D"">

<p></p></span><br clear=3D"all"></blockquote></div><br><br></div><div class=
=3D"gmail_extra">Why doesn&#39;t variant revert back to the int when the co=
py throws?=C2=A0 We don&#39;t want to pay for the moves?<br><br></div><div =
class=3D"gmail_extra">-- <br><div class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br>=
</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/CAOHCbitzWkx%3D5N%3D-VOgfTL99UfismV2k=
2_P%2BKDHPf6zgdWarNw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitzWk=
x%3D5N%3D-VOgfTL99UfismV2k2_P%2BKDHPf6zgdWarNw%40mail.gmail.com</a>.<br />

--000000000000b68473056aafeb25--

.

--0000000000006b1251056ab23064
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018 at 1:51 PM Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Wed, Apr 25, 2018 at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com> wrote:
>>
>>> Also, it will only get into that state because some move-operation threw.
>>>
>>
>> *cough*
>>
>> libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz
>> libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST
>>
>>
>>
>
> Why doesn't variant revert back to the int when the copy throws?  We don't
> want to pay for the moves?
>

Not taking any specific stance here -- if we want to at least allow
implementations to have valueless_by_exception in fewer cases without being
non-compliant, I think the easiest catch-all might be to only specify the
basic guarantee in places where we currently specify, very explicitly, that
we end up in the "valueless_by_exception" state. It's technically breaking,
but people actually relying on something necessarily being in the
valueless_by_exception state, outside of standard library tests, seems
dubious, and we already have implementation divergence anyway. This for
emplace as well as for assignments.

Anyway, it's already a little bit out of the ordinary that we would dictate
a specific state rather than just one of the normal guarantees when you
look elsewhere in the standard library and in other libraries.
Alternatively, we can come up with even more rigid rules for what
specifically happens in each case, but I suspect we are already
over-specifying here. Implementations also might actually choose to go into
the valueless_by_exception state when given other options because it's
possibly more efficient to do so, and I'm not sure that's too horrible of
an idea given that the valueless_by_exception state is already a reality
anyway. As someone who is not particularly fond of valueless_by_exception,
my overall opinion is *shrugs*.

--
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/CANh8DEkGVR5_vqErg634Eh%2BzXrGfn%3D5eetnGYcEf%3DR422vkvtA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Apr 25=
, 2018 at 1:51 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=
=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Apr 25, 2018 at 10:40 AM, &#39;Matt Calabrese&#39;=
 via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><span><div dir=3D"ltr">On Tue, Apr 24, 2018 at 1:3=
2 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">t=
vaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Also, it will =
only get into that state because some move-operation threw.</div></div></bl=
ockquote><div><br></div></span><div>*cough*=C2=A0</div><div><br></div><div>=
libc++: <a href=3D"https://wandbox.org/permlink/0ag3V2oVa3MBcWmz" target=3D=
"_blank">https://wandbox.org/permlink/0ag3V2oVa3MBcWmz</a></div><div>libstd=
c++:=C2=A0<a href=3D"https://wandbox.org/permlink/LEUsrj9ir5vyVcST" target=
=3D"_blank">https://wandbox.org/permlink/LEUsrj9ir5vyVcST</a></div></div></=
div><span>

<p></p></span><br clear=3D"all"></blockquote></div><br><br></div><div class=
=3D"gmail_extra">Why doesn&#39;t variant revert back to the int when the co=
py throws?=C2=A0 We don&#39;t want to pay for the moves?</div></div></block=
quote><div><br></div><div>Not taking any specific stance here -- if we want=
 to at least allow implementations to have valueless_by_exception in fewer =
cases without being non-compliant, I think the easiest catch-all might be t=
o only specify the basic guarantee in places where we currently specify, ve=
ry explicitly, that we end up in the &quot;valueless_by_exception&quot; sta=
te. It&#39;s technically breaking, but people actually relying on something=
 necessarily being in the valueless_by_exception state, outside of standard=
 library tests, seems dubious, and we already have implementation divergenc=
e anyway. This for emplace as well as for assignments.</div><div><br></div>=
<div>Anyway, it&#39;s already a little bit out of the ordinary that we woul=
d dictate a specific state rather than just one of the normal guarantees wh=
en you look elsewhere in the standard library and in other libraries. Alter=
natively, we can come up with even more rigid rules for what specifically h=
appens in each case, but I suspect we=C2=A0are already over-specifying here=
.. Implementations also might actually choose to go into the valueless_by_ex=
ception state when given other options because it&#39;s possibly more effic=
ient to do so, and I&#39;m not sure that&#39;s too horrible of an idea give=
n that the valueless_by_exception state is already a reality anyway. As som=
eone who is not particularly fond of valueless_by_exception, my overall opi=
nion is *shrugs*.</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/CANh8DEkGVR5_vqErg634Eh%2BzXrGfn%3D5e=
etnGYcEf%3DR422vkvtA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEkGVR=
5_vqErg634Eh%2BzXrGfn%3D5eetnGYcEf%3DR422vkvtA%40mail.gmail.com</a>.<br />

--0000000000006b1251056ab23064--

.

--f403043c6b50f644ff056ab28e4b
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018 at 3:33 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Wed, Apr 25, 2018 at 1:51 PM Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>> On Wed, Apr 25, 2018 at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com> wrote:
>>>
>>>> Also, it will only get into that state because some move-operation
>>>> threw.
>>>>
>>>
>>> *cough*
>>>
>>> libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz
>>> libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST
>>>
>>>
>>>
>>
>> Why doesn't variant revert back to the int when the copy throws?  We
>> don't want to pay for the moves?
>>
>
> Not taking any specific stance here -- if we want to at least allow
> implementations to have valueless_by_exception in fewer cases without being
> non-compliant, I think the easiest catch-all might be to only specify the
> basic guarantee in places where we currently specify, very explicitly, that
> we end up in the "valueless_by_exception" state. It's technically breaking,
> but people actually relying on something necessarily being in the
> valueless_by_exception state, outside of standard library tests, seems
> dubious, and we already have implementation divergence anyway. This for
> emplace as well as for assignments.
>

Do you and Tony really wish to re-argue variant???


> Anyway, it's already a little bit out of the ordinary that we would
> dictate a specific state rather than just one of the normal guarantees when
> you look elsewhere in the standard library and in other libraries.
>

The normal guarantees (valid but unspecified state) don't cover it in
general; you have to have a state when you cannot guarantee construction of
any of the types in the type list.  That forces variant to model at-most-1
instead of exactly-1, and no other states cover variant holding none of the
types in the type list.

Double buffering was a non-starter.  The endless discussions about
non-throwing move constructors went nowhere.

Given those constraints, valueless_by_exception is (a) the easiest to
reason about and (b) the most annoying to deal with.


And all that was already discussed ad nauseam.  I see no new information
being presented here.  I would be strongly against spending any committee
time on this w/o new information.
--
 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%2BMhymTGPCiDRgkTvV0QuXzNJ_BC%2Bhm2mEGuErJ6K3YFtw%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, Apr 25, 2018 at 3:33 PM, &#39;Matt Calabrese&#39; =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quot=
e"><span class=3D""><div dir=3D"ltr">On Wed, Apr 25, 2018 at 1:51 PM Tony V=
 E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, A=
pr 25, 2018 at 10:40 AM, &#39;Matt Calabrese&#39; via ISO C++ Standard - Fu=
ture Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><=
span><div dir=3D"ltr">On Tue, Apr 24, 2018 at 1:32 PM Tony V E &lt;<a href=
=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra">Also, it will only get into that state =
because some move-operation threw.</div></div></blockquote><div><br></div><=
/span><div>*cough*=C2=A0</div><div><br></div><div>libc++: <a href=3D"https:=
//wandbox.org/permlink/0ag3V2oVa3MBcWmz" target=3D"_blank">https://wandbox.=
org/permlink/<wbr>0ag3V2oVa3MBcWmz</a></div><div>libstdc++:=C2=A0<a href=3D=
"https://wandbox.org/permlink/LEUsrj9ir5vyVcST" target=3D"_blank">https://w=
andbox.<wbr>org/permlink/LEUsrj9ir5vyVcST</a></div></div></div><span>

<p></p></span><br clear=3D"all"></blockquote></div><br><br></div><div class=
=3D"gmail_extra">Why doesn&#39;t variant revert back to the int when the co=
py throws?=C2=A0 We don&#39;t want to pay for the moves?</div></div></block=
quote><div><br></div></span><div>Not taking any specific stance here -- if =
we want to at least allow implementations to have valueless_by_exception in=
 fewer cases without being non-compliant, I think the easiest catch-all mig=
ht be to only specify the basic guarantee in places where we currently spec=
ify, very explicitly, that we end up in the &quot;valueless_by_exception&qu=
ot; state. It&#39;s technically breaking, but people actually relying on so=
mething necessarily being in the valueless_by_exception state, outside of s=
tandard library tests, seems dubious, and we already have implementation di=
vergence anyway. This for emplace as well as for assignments.</div></div></=
div></blockquote><div><br></div><div>Do you and Tony really wish to re-argu=
e variant???</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div>Anyway, it&#39;s already a little =
bit out of the ordinary that we would dictate a specific state rather than =
just one of the normal guarantees when you look elsewhere in the standard l=
ibrary and in other libraries.</div></div></div></blockquote><div><br></div=
><div>The normal guarantees (valid but unspecified state) don&#39;t cover i=
t in general; you have to have a state when you cannot guarantee constructi=
on of any of the types in the type list.=C2=A0 That forces variant to model=
 at-most-1 instead of exactly-1, and no other states cover variant holding =
none of the types in the type list.</div><div><br></div><div>Double bufferi=
ng was a non-starter.=C2=A0 The endless discussions about non-throwing move=
 constructors went nowhere.</div><div><br></div><div>Given those constraint=
s, valueless_by_exception is (a) the easiest to reason about and (b) the mo=
st annoying to deal with.</div><div><br></div><div><br></div><div>And all t=
hat was already discussed ad nauseam.=C2=A0 I see no new information being =
presented here.=C2=A0 I would be strongly against spending any committee ti=
me on this w/o new information.</div></div>-- <br><div class=3D"gmail_signa=
ture" data-smartmail=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"mai=
lto: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%2BMhymTGPCiDRgkTvV0QuXzNJ_BC%2=
Bhm2mEGuErJ6K3YFtw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMhym=
TGPCiDRgkTvV0QuXzNJ_BC%2Bhm2mEGuErJ6K3YFtw%40mail.gmail.com</a>.<br />

--f403043c6b50f644ff056ab28e4b--

.

--0000000000009fe4ae056ab319a6
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018, 17:00 Nevin Liber <nevin@eviloverlord.com> wrote:

> On Wed, Apr 25, 2018 at 3:33 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Wed, Apr 25, 2018 at 1:51 PM Tony V E <tvaneerd@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 25, 2018 at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard
>>> - Future Proposals <std-proposals@isocpp.org> wrote:
>>>
>>>> On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com> wrote:
>>>>
>>>>> Also, it will only get into that state because some move-operation
>>>>> threw.
>>>>>
>>>>
>>>> *cough*
>>>>
>>>> libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz
>>>> libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST
>>>>
>>>>
>>>>
>>>
>>> Why doesn't variant revert back to the int when the copy throws?  We
>>> don't want to pay for the moves?
>>>
>>
>> Not taking any specific stance here -- if we want to at least allow
>> implementations to have valueless_by_exception in fewer cases without being
>> non-compliant, I think the easiest catch-all might be to only specify the
>> basic guarantee in places where we currently specify, very explicitly, that
>> we end up in the "valueless_by_exception" state. It's technically breaking,
>> but people actually relying on something necessarily being in the
>> valueless_by_exception state, outside of standard library tests, seems
>> dubious, and we already have implementation divergence anyway. This for
>> emplace as well as for assignments.
>>
>
> Do you and Tony really wish to re-argue variant???
>

It's too late for that. C++17 set most things in stone. I explicitly don't
care which direction we go for the details now that we are in this state.
My "shrugs" is truly sincere. What was identified is a bug that maybe
shouldn't be considered a bug. We can enumerate options, but specifically
which we take isn't all that important to me.


On Wed, Apr 25, 2018, 17:00 Nevin Liber <nevin@eviloverlord.com> wrote:

>
>
>> Anyway, it's already a little bit out of the ordinary that we would
>> dictate a specific state rather than just one of the normal guarantees when
>> you look elsewhere in the standard library and in other libraries.
>>
>
> The normal guarantees (valid but unspecified state) don't cover it in
> general; you have to have a state when you cannot guarantee construction of
> any of the types in the type list.
>

Perhaps there is miscommunication somewhere -- valueless_by_exception is a
valid state (it's just a weird one). If, in each place we explicitly
require valueless by exception, we instead specify any valid but
unspecified state, and instead of giving very explicit implementation
instructions, we instead specify the overall semantics and guarantees when
the appropriate requirements are met, then the (imo) reasonable stdlib
implementation becomes compliant. I think that's one option and is fine. It
also gives more implementation freedom and can become more specific in the
future based on actual implementation experience, if we wanted.

--
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/CANh8DEnJ4R4TKuMFXRrpsJyC%3DrFZ2zj3V_mwOattW_CAjuwHug%40mail.gmail.com.

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, =
Apr 25, 2018, 17:00 Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.co=
m">nevin@eviloverlord.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Wed, Apr 25, 2018 at 3:33 PM, &#39;Matt Calabrese=
&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank" rel=3D"noreferrer">s=
td-proposals@isocpp.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_quote"><span><div dir=3D"ltr">On Wed, Apr 25, 2018 at =
1:51 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank=
" rel=3D"noreferrer">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Wed, Apr 25, 2018 at 10:40 AM, &#39;Matt Calabre=
se&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:std-proposals@isocpp.org" target=3D"_blank" rel=3D"noreferrer"=
>std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><span><div dir=3D"ltr">O=
n Tue, Apr 24, 2018 at 1:32 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmai=
l.com" target=3D"_blank" rel=3D"noreferrer">tvaneerd@gmail.com</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra">Also, it will only get into that state becau=
se some move-operation threw.</div></div></blockquote><div><br></div></span=
><div>*cough*=C2=A0</div><div><br></div><div>libc++: <a href=3D"https://wan=
dbox.org/permlink/0ag3V2oVa3MBcWmz" target=3D"_blank" rel=3D"noreferrer">ht=
tps://wandbox.org/permlink/0ag3V2oVa3MBcWmz</a></div><div>libstdc++:=C2=A0<=
a href=3D"https://wandbox.org/permlink/LEUsrj9ir5vyVcST" target=3D"_blank" =
rel=3D"noreferrer">https://wandbox.org/permlink/LEUsrj9ir5vyVcST</a></div><=
/div></div><span>

<p></p></span><br clear=3D"all"></blockquote></div><br><br></div><div class=
=3D"gmail_extra">Why doesn&#39;t variant revert back to the int when the co=
py throws?=C2=A0 We don&#39;t want to pay for the moves?</div></div></block=
quote><div><br></div></span><div>Not taking any specific stance here -- if =
we want to at least allow implementations to have valueless_by_exception in=
 fewer cases without being non-compliant, I think the easiest catch-all mig=
ht be to only specify the basic guarantee in places where we currently spec=
ify, very explicitly, that we end up in the &quot;valueless_by_exception&qu=
ot; state. It&#39;s technically breaking, but people actually relying on so=
mething necessarily being in the valueless_by_exception state, outside of s=
tandard library tests, seems dubious, and we already have implementation di=
vergence anyway. This for emplace as well as for assignments.</div></div></=
div></blockquote><div><br></div><div>Do you and Tony really wish to re-argu=
e variant???</div></div></div></div></blockquote></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">It&#39;s too late for that. C++17 set most =
things in stone. I explicitly don&#39;t care which direction we go for the =
details now that we are in this state. My &quot;shrugs&quot; is truly since=
re. What was identified is a bug that maybe shouldn&#39;t be considered a b=
ug. We can enumerate options, but specifically which we take isn&#39;t all =
that important to me.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">On Wed, Ap=
r 25, 2018, 17:00 Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com"=
>nevin@eviloverlord.com</a>&gt; wrote:</span><br></div><div dir=3D"auto"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>A=
nyway, it&#39;s already a little bit out of the ordinary that we would dict=
ate a specific state rather than just one of the normal guarantees when you=
 look elsewhere in the standard library and in other libraries.</div></div>=
</div></blockquote><div><br></div><div>The normal guarantees (valid but uns=
pecified state) don&#39;t cover it in general; you have to have a state whe=
n you cannot guarantee construction of any of the types in the type list.</=
div></div></div></div></blockquote></div></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Perhaps there is miscommunication somewhere -- valueless_=
by_exception is a valid state (it&#39;s just a weird one). If, in each plac=
e we explicitly require valueless by exception, we instead specify any vali=
d but unspecified state, and instead of giving very explicit implementation=
 instructions, we instead specify the overall semantics and guarantees when=
 the appropriate requirements are met, then the (imo) reasonable stdlib imp=
lementation becomes compliant. I think that&#39;s one option and is fine. I=
t also gives more implementation freedom and can become more specific in th=
e future based on actual implementation experience, if we wanted.</div></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/CANh8DEnJ4R4TKuMFXRrpsJyC%3DrFZ2zj3V_=
mwOattW_CAjuwHug%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnJ4R4TKu=
MFXRrpsJyC%3DrFZ2zj3V_mwOattW_CAjuwHug%40mail.gmail.com</a>.<br />

--0000000000009fe4ae056ab319a6--

.

On 26 April 2018 at 00:38, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> Perhaps there is miscommunication somewhere -- valueless_by_exception is a
> valid state (it's just a weird one). If, in each place we explicitly require
> valueless by exception, we instead specify any valid but unspecified state,
> and instead of giving very explicit implementation instructions, we instead
> specify the overall semantics and guarantees when the appropriate
> requirements are met, then the (imo) reasonable stdlib implementation
> becomes compliant. I think that's one option and is fine. It also gives more
> implementation freedom and can become more specific in the future based on
> actual implementation experience, if we wanted.


I am not interested in implementation freedom, I'm interested in
variant being portable. The current implementation
divergence is to a fair extent bugs in libstdc++, and those bugs will
not survive long.

--
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/CAFk2RUbZ_hEH%2Bncsydxr%2BjSLY0Z3rRmeLc0AeVwBAhU_x-TZ-w%40mail.gmail.com.

.

--00000000000022432d056ab34763
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018, 17:43 Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:

> On 26 April 2018 at 00:38, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> > Perhaps there is miscommunication somewhere -- valueless_by_exception is
> a
> > valid state (it's just a weird one). If, in each place we explicitly
> require
> > valueless by exception, we instead specify any valid but unspecified
> state,
> > and instead of giving very explicit implementation instructions, we
> instead
> > specify the overall semantics and guarantees when the appropriate
> > requirements are met, then the (imo) reasonable stdlib implementation
> > becomes compliant. I think that's one option and is fine. It also gives
> more
> > implementation freedom and can become more specific in the future based
> on
> > actual implementation experience, if we wanted.
>
>
> I am not interested in implementation freedom, I'm interested in
> variant being portable. The current implementation
> divergence is to a fair extent bugs in libstdc++, and those bugs will
> not survive long.
>

Then would you or would you not be in favor of a proposal to require that
we do not enter the valueless_by_exception state here? Tony's concern is
that the current specification implies that we can get to
valueless_by_exception in an assignment even when a move constructor does
not actually throw, which is currently true. Should we "fix" this in a
future standard or consider to be fine?

>

--
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/CANh8DEnKB8UjjutTryzrtnmiXfDCqG9Hp_DrQxtsk14DUni--g%40mail.gmail.com.

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Wed, Apr 25, 2018, 17:43 Ville Voutilainen &lt;<a href=3D"mailto:ville.v=
outilainen@gmail.com" target=3D"_blank" rel=3D"noreferrer">ville.voutilaine=
n@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26 Ap=
ril 2018 at 00:38, &#39;Matt Calabrese&#39; via ISO C++ Standard -<br>
Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org" rel=3D"nor=
eferrer noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>&gt; wrot=
e:<br>
&gt; Perhaps there is miscommunication somewhere -- valueless_by_exception =
is a<br>
&gt; valid state (it&#39;s just a weird one). If, in each place we explicit=
ly require<br>
&gt; valueless by exception, we instead specify any valid but unspecified s=
tate,<br>
&gt; and instead of giving very explicit implementation instructions, we in=
stead<br>
&gt; specify the overall semantics and guarantees when the appropriate<br>
&gt; requirements are met, then the (imo) reasonable stdlib implementation<=
br>
&gt; becomes compliant. I think that&#39;s one option and is fine. It also =
gives more<br>
&gt; implementation freedom and can become more specific in the future base=
d on<br>
&gt; actual implementation experience, if we wanted.<br>
<br>
<br>
I am not interested in implementation freedom, I&#39;m interested in<br>
variant being portable. The current implementation<br>
divergence is to a fair extent bugs in libstdc++, and those bugs will<br>
not survive long.<br></blockquote></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Then would you or would you not be in favor of a proposal =
to require that we do not enter the valueless_by_exception state here? Tony=
&#39;s concern is that the current specification implies that we can get to=
 valueless_by_exception in an assignment even when a move constructor does =
not actually throw, which is currently true. Should we &quot;fix&quot; this=
 in a future standard or consider to be fine?</div><div dir=3D"auto"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></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/CANh8DEnKB8UjjutTryzrtnmiXfDCqG9Hp_Dr=
Qxtsk14DUni--g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnKB8UjjutT=
ryzrtnmiXfDCqG9Hp_DrQxtsk14DUni--g%40mail.gmail.com</a>.<br />

--00000000000022432d056ab34763--

.

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

On Wed, Apr 25, 2018 at 4:51 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Then would you or would you not be in favor of a proposal to require that
> we do not enter the valueless_by_exception state here? Tony's concern is
> that the current specification implies that we can get to
> valueless_by_exception in an assignment even when a move constructor does
> not actually throw, which is currently true. Should we "fix" this in a
> future standard or consider to be fine?
>

I would be against because we have better things to do with committee time.

Variations on Boost.Variant, which IIRC picks the first no-throw
default-constructible type on the type list. were already discussed and
rejected.

And it is a breaking change, as you can only safely do this for types known
not to throw or terminate during construction, and noexcept is not
sufficient to determine the latter.

And, as already discussed as part of variant, some move constructors are
slow (std::array<int, 1000000>), because its authors would rather do that
than a heap allocation and a bunch of indirection in their implementation.

Like I said, no new information here...
--
 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%2BPawkZ0zJiM2-Ky8kWDmTUdUJo%3DY02tVMuXPsi-pf0KBg%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, Apr 25, 2018 at 4:51 PM, &#39;Matt Calabrese&#39; =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span class=3D""><div>T=
hen would you or would you not be in favor of a proposal to require that we=
 do not enter the valueless_by_exception state here? Tony&#39;s concern is =
that the current specification implies that we can get to valueless_by_exce=
ption in an assignment even when a move constructor does not actually throw=
, which is currently true. Should we &quot;fix&quot; this in a future stand=
ard or consider to be fine?<br></div></span></div></blockquote><div><br></d=
iv><div>I would be against because we have better things to do with committ=
ee time.</div><div><br></div><div>Variations on Boost.Variant, which IIRC p=
icks the first no-throw default-constructible type on the type list. were a=
lready discussed and rejected.</div><div><br></div><div>And it is a breakin=
g change, as you can only safely do this for types known not to throw or te=
rminate during construction, and noexcept is not sufficient to determine th=
e latter.</div><div><br></div><div>And, as already discussed as part of var=
iant, some move constructors are slow (std::array&lt;int, 1000000&gt;), bec=
ause its authors would rather do that than a heap allocation and a bunch of=
 indirection in their implementation.</div><div><br></div><div>Like I said,=
 no new information here...</div></div>-- <br><div class=3D"gmail_signature=
" data-smartmail=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%2BPawkZ0zJiM2-Ky8kWDmTUdUJo%3D=
Y02tVMuXPsi-pf0KBg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPawk=
Z0zJiM2-Ky8kWDmTUdUJo%3DY02tVMuXPsi-pf0KBg%40mail.gmail.com</a>.<br />

--001a1146696c9761aa056ab367f4--

.

--000000000000223a9c056ab3789c
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018 at 4:59 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On Wed, Apr 25, 2018 at 3:33 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Wed, Apr 25, 2018 at 1:51 PM Tony V E <tvaneerd@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 25, 2018 at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard
>>> - Future Proposals <std-proposals@isocpp.org> wrote:
>>>
>>>> On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com> wrote:
>>>>
>>>>> Also, it will only get into that state because some move-operation
>>>>> threw.
>>>>>
>>>>
>>>> *cough*
>>>>
>>>> libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz
>>>> libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST
>>>>
>>>>
>>>>
>>>
>>> Why doesn't variant revert back to the int when the copy throws?  We
>>> don't want to pay for the moves?
>>>
>>
>> Not taking any specific stance here -- if we want to at least allow
>> implementations to have valueless_by_exception in fewer cases without being
>> non-compliant, I think the easiest catch-all might be to only specify the
>> basic guarantee in places where we currently specify, very explicitly, that
>> we end up in the "valueless_by_exception" state. It's technically breaking,
>> but people actually relying on something necessarily being in the
>> valueless_by_exception state, outside of standard library tests, seems
>> dubious, and we already have implementation divergence anyway. This for
>> emplace as well as for assignments.
>>
>
> Do you and Tony really wish to re-argue variant???
>
>
>> Anyway, it's already a little bit out of the ordinary that we would
>> dictate a specific state rather than just one of the normal guarantees when
>> you look elsewhere in the standard library and in other libraries.
>>
>
> The normal guarantees (valid but unspecified state) don't cover it in
> general; you have to have a state when you cannot guarantee construction of
> any of the types in the type list.  That forces variant to model at-most-1
> instead of exactly-1, and no other states cover variant holding none of the
> types in the type list.
>
> Double buffering was a non-starter.  The endless discussions about
> non-throwing move constructors went nowhere.
>
> Given those constraints, valueless_by_exception is (a) the easiest to
> reason about and (b) the most annoying to deal with.
>
>
No is suggesting getting rid of valueless_by_exception.

It is just a simple question of how "hard" should we try to avoid that
state when we can.



>
> And all that was already discussed ad nauseam.  I see no new information
> being presented here.  I would be strongly against spending any committee
> time on this w/o new information.
> --
>  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%2BMhymTGPCiDRgkTvV0QuXzNJ_BC%
> 2Bhm2mEGuErJ6K3YFtw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMhymTGPCiDRgkTvV0QuXzNJ_BC%2Bhm2mEGuErJ6K3YFtw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
Tony

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivoibSKav%2BDQNt9Y8ybMsxKx%2B9c0XQm1Nvi4YKxVTgDbA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Apr 25, 2018 at 4:59 PM, Nevin Liber <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span class=3D"">On Wed, Apr 25, 2018 at 3:33 PM, &#39;Matt Calabrese&#39=
; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"=
mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org=
</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_quote"><span><div dir=3D"ltr">On Wed, Apr 25, 2018 at=
 1:51 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blan=
k">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Wed, Apr 25, 2018 at 10:40 AM, &#39;Matt Calabrese&#39; via ISO C+=
+ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-p=
roposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><span><div dir=3D"ltr">On Tue, Apr 24, 2018 at 1:32 PM Tony V=
 E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Also, it will only get in=
to that state because some move-operation threw.</div></div></blockquote><d=
iv><br></div></span><div>*cough*=C2=A0</div><div><br></div><div>libc++: <a =
href=3D"https://wandbox.org/permlink/0ag3V2oVa3MBcWmz" target=3D"_blank">ht=
tps://wandbox.org/permlink/0<wbr>ag3V2oVa3MBcWmz</a></div><div>libstdc++:=
=C2=A0<a href=3D"https://wandbox.org/permlink/LEUsrj9ir5vyVcST" target=3D"_=
blank">https://wandbox.org<wbr>/permlink/LEUsrj9ir5vyVcST</a></div></div></=
div><span>

<p></p></span><br clear=3D"all"></blockquote></div><br><br></div><div class=
=3D"gmail_extra">Why doesn&#39;t variant revert back to the int when the co=
py throws?=C2=A0 We don&#39;t want to pay for the moves?</div></div></block=
quote><div><br></div></span><div>Not taking any specific stance here -- if =
we want to at least allow implementations to have valueless_by_exception in=
 fewer cases without being non-compliant, I think the easiest catch-all mig=
ht be to only specify the basic guarantee in places where we currently spec=
ify, very explicitly, that we end up in the &quot;valueless_by_exception&qu=
ot; state. It&#39;s technically breaking, but people actually relying on so=
mething necessarily being in the valueless_by_exception state, outside of s=
tandard library tests, seems dubious, and we already have implementation di=
vergence anyway. This for emplace as well as for assignments.</div></div></=
div></blockquote><div><br></div></span><div>Do you and Tony really wish to =
re-argue variant???</div><span class=3D""><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Anyway, it&=
#39;s already a little bit out of the ordinary that we would dictate a spec=
ific state rather than just one of the normal guarantees when you look else=
where in the standard library and in other libraries.</div></div></div></bl=
ockquote><div><br></div></span><div>The normal guarantees (valid but unspec=
ified state) don&#39;t cover it in general; you have to have a state when y=
ou cannot guarantee construction of any of the types in the type list.=C2=
=A0 That forces variant to model at-most-1 instead of exactly-1, and no oth=
er states cover variant holding none of the types in the type list.</div><d=
iv><br></div><div>Double buffering was a non-starter.=C2=A0 The endless dis=
cussions about non-throwing move constructors went nowhere.</div><div><br><=
/div><div>Given those constraints, valueless_by_exception is (a) the easies=
t to reason about and (b) the most annoying to deal with.</div><div><br></d=
iv></div></div></div></blockquote><div><br></div><div>No is suggesting gett=
ing rid of valueless_by_exception.<br><br></div><div>It is just a simple qu=
estion of how &quot;hard&quot; should we try to avoid that state when we ca=
n.<br><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"><div dir=3D"ltr"><=
div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div><br></=
div><div>And all that was already discussed ad nauseam.=C2=A0 I see no new =
information being presented here.=C2=A0 I would be strongly against spendin=
g any committee time on this w/o new information.</div></div>-- <br><div cl=
ass=3D"m_-8035621358893604204gmail_signature" data-smartmail=3D"gmail_signa=
ture"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quo=
t; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a><wbr>&gt; =C2=A0+1-847-691-1404</div>=
</div></div></div></div>
</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@<wbr>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/CAGg_6%2BMhymTGPCiDRgkTvV0QuXzNJ_BC%2=
Bhm2mEGuErJ6K3YFtw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAGg_6%<wbr>2BMhymTGPCiDRgkTvV0QuXzNJ_BC%<wbr>2Bhm2mEGuE=
rJ6K3YFtw%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></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/CAOHCbivoibSKav%2BDQNt9Y8ybMsxKx%2B9c=
0XQm1Nvi4YKxVTgDbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivoibSK=
av%2BDQNt9Y8ybMsxKx%2B9c0XQm1Nvi4YKxVTgDbA%40mail.gmail.com</a>.<br />

--000000000000223a9c056ab3789c--

.

On 26 April 2018 at 00:51, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> Then would you or would you not be in favor of a proposal to require that we
> do not enter the valueless_by_exception state here? Tony's concern is that
> the current specification implies that we can get to valueless_by_exception
> in an assignment even when a move constructor does not actually throw, which
> is currently true. Should we "fix" this in a future standard or consider to
> be fine?


I would not be in favor of such a proposal. The user attempted to
change the type of the object variant holds,
and that can lead to a valueless state if either copy or move throws.
The user didn't ask for a move, so I don't
know how a non-throwing move is supposed to save the user's bacon. We
can chase corner cases all we want,
and entertain checking for trivial destructibility and non-throwing
move and doing yet another thing in that case,
but doing so would require a demonstrated benefit, and anecdotes from
users who think non-throwing moves are applied to lvalues
don't convince me as evidence of much anything.

--
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/CAFk2RUbc53_cc9mOJrHQLQeBBKehLsHUzJjKj6iqjmDi3RjZag%40mail.gmail.com.

.

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

On Wed, Apr 25, 2018 at 5:17 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 26 April 2018 at 00:51, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:


> > Then would you or would you not be in favor of a proposal to require
> that we
> > do not enter the valueless_by_exception state here? Tony's concern is
> that
> > the current specification implies that we can get to
> valueless_by_exception
> > in an assignment even when a move constructor does not actually throw,
> which
> > is currently true. Should we "fix" this in a future standard or conside=
r
> to
> > be fine?


As already discussed, every extra move is a performance pessimization.
Doing so just to make a rare case theoretically slightly rarer
(theoretically, because it is possible to make it less rare, such as the
old object holding on to memory the new object needs) isn=E2=80=99t worth i=
t.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--=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/CAGg_6%2BMONUcn3BonimMdCn8T8hoTri_5S__a7G_FUTEBL=
ePV9w%40mail.gmail.com.

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

<div>On Wed, Apr 25, 2018 at 5:17 PM, Ville Voutilainen &lt;<a href=3D"mail=
to:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<=
br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26 April 20=
18 at 00:51, &#39;Matt Calabrese&#39; via ISO C++ Standard -<br>
Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"=
_blank">std-proposals@isocpp.org</a>&gt; wrote:</blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><br>
&gt; Then would you or would you not be in favor of a proposal to require t=
hat we<br>
&gt; do not enter the valueless_by_exception state here? Tony&#39;s concern=
 is that<br>
&gt; the current specification implies that we can get to valueless_by_exce=
ption<br>
&gt; in an assignment even when a move constructor does not actually throw,=
 which<br>
&gt; is currently true. Should we &quot;fix&quot; this in a future standard=
 or consider to<br>
&gt; be fine?</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">As =
already discussed, every extra move is a performance pessimization. Doing s=
o just to make a rare case theoretically slightly rarer (theoretically, bec=
ause it is possible to make it less rare, such as the old object holding on=
 to memory the new object needs) isn=E2=80=99t worth it.</div></div></div>-=
- <br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_si=
gnature"><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" targ=
et=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></d=
iv></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%2BMONUcn3BonimMdCn8T8hoTri_5S_=
_a7G_FUTEBLePV9w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMONUcn=
3BonimMdCn8T8hoTri_5S__a7G_FUTEBLePV9w%40mail.gmail.com</a>.<br />

--001a114dcff8009737056ab3e2f3--

.

--0000000000007196bd056ab41001
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018, 18:00 Nevin Liber <nevin@eviloverlord.com> wrote:

> On Wed, Apr 25, 2018 at 4:51 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> Then would you or would you not be in favor of a proposal to require that
>> we do not enter the valueless_by_exception state here? Tony's concern is
>> that the current specification implies that we can get to
>> valueless_by_exception in an assignment even when a move constructor does
>> not actually throw, which is currently true. Should we "fix" this in a
>> future standard or consider to be fine?
>>
>
> I would be against because we have better things to do with committee time.
>
> Variations on Boost.Variant, which IIRC picks the first no-throw
> default-constructible type on the type list. were already discussed and
> rejected.
>

I'll restate: I'm pretty sure you are misunderstanding the specific case we
are talking about. Forget about Boost.Variant or a lack of valueless by
exception -- that ship sailed and this has little to do with it. I am not
at all saying we should try to change consensus on something that already
shipped. Look again at the example -- we are getting to the valueless by
exception state from an assignment operation without ever even having a
move operation that throws, which many advocates of valueless by exception
did not want. We certainly can avoid this if the committee decided (this is
in line with expressed intent and we've already made other changes to
minimize valueless by exception). I'm personally not even advocating this,
nor did I even start this thread. I'm enumerating options for those who
cared. You don't have to do anything like construct the first
default-constructible alternative here.

Backpedalling a little bit though, the current libstdc++ behavior appears
broken, regardless, but that's being fixed anyway.

On Wed, Apr 25, 2018, 18:00 Nevin Liber <nevin@eviloverlord.com> wrote:

> And, as already discussed as part of variant, some move constructors are
> slow (std::array<int, 1000000>), because its authors would rather do that
> than a heap allocation and a bunch of indirection in their implementation.
>

I agree that particular aspect hasn't changed. I'm also not sure you
realize that I am speaking for those who I disagree with -- members who
advocated for valueless by exception explicitly want to minimize getting
into the valueless by exception state. If we don't care to make further
changes then that is fine, but I do not understand the backlash. We've
already made changes akin to this during standardization "with no new
information". Let's at least figure out what the committee's actual goal is
here.

It seems that no matter which side I speak for on this topic I'm either
explicitly called insane or get pounced on. It's getting ridiculous and is
not indicative of an environment where people can speak their mind.

--
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/CANh8DEmfs-9G38GqgmV3jO_7xvQyAL3evb9f96VUw-hXjvkZkw%40mail.gmail.com.

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Wed, Apr 25, 2018, 18:00 Nevin Liber &lt;<a href=3D"mailto:nevin@evilove=
rlord.com" target=3D"_blank" rel=3D"noreferrer">nevin@eviloverlord.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wed,=
 Apr 25, 2018 at 4:51 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard - F=
uture Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocp=
p.org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp=
..org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span><div>Then w=
ould you or would you not be in favor of a proposal to require that we do n=
ot enter the valueless_by_exception state here? Tony&#39;s concern is that =
the current specification implies that we can get to valueless_by_exception=
 in an assignment even when a move constructor does not actually throw, whi=
ch is currently true. Should we &quot;fix&quot; this in a future standard o=
r consider to be fine?<br></div></span></div></blockquote><div><br></div><d=
iv>I would be against because we have better things to do with committee ti=
me.</div><div><br></div><div>Variations on Boost.Variant, which IIRC picks =
the first no-throw default-constructible type on the type list. were alread=
y discussed and rejected.</div></div></div></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;ll restate: I&#39;m pret=
ty sure you are misunderstanding the specific case we are talking about. Fo=
rget about Boost.Variant or a lack of valueless by exception -- that ship s=
ailed and this has little to do with it. I am not at all saying we should t=
ry to change consensus on something that already shipped. Look again at the=
 example -- we are getting to the valueless by exception state from an assi=
gnment operation without ever even having a move operation that throws, whi=
ch many advocates of valueless by exception did not want. We certainly can =
avoid this if the committee decided (this is in line with expressed intent =
and we&#39;ve already made other changes to minimize valueless by exception=
). I&#39;m personally not even advocating this, nor did I even start this t=
hread. I&#39;m enumerating options for those who cared. You don&#39;t have =
to do anything like construct the first default-constructible alternative h=
ere.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Backpedalling a lit=
tle bit though, the current libstdc++ behavior appears broken, regardless, =
but that&#39;s being fixed anyway.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><span style=3D"font-family:sans-serif">On Wed, Apr 25, 2018, 18:=
00 Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bla=
nk" rel=3D"noreferrer">nevin@eviloverlord.com</a>&gt; wrote:</span></div><d=
iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=
And, as already discussed as part of variant, some move constructors are sl=
ow (std::array&lt;int, 1000000&gt;), because its authors would rather do th=
at than a heap allocation and a bunch of indirection in their implementatio=
n.</div></div></div></div></blockquote></div></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">I agree that particular aspect hasn&#39;t changed. I&=
#39;m also not sure you realize that I am speaking for those who I disagree=
 with -- members who advocated for valueless by exception explicitly want t=
o minimize getting into the valueless by exception state. If we don&#39;t c=
are to make further changes then that is fine, but I do not understand the =
backlash. We&#39;ve already made changes akin to this during standardizatio=
n &quot;with no new information&quot;. Let&#39;s at least figure out what t=
he committee&#39;s actual goal is here.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">It seems that no matter which side I speak for on this topi=
c I&#39;m either explicitly called insane or get pounced on. It&#39;s getti=
ng ridiculous and is not indicative of an environment where people can spea=
k their mind.</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/CANh8DEmfs-9G38GqgmV3jO_7xvQyAL3evb9f=
96VUw-hXjvkZkw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmfs-9G38Gq=
gmV3jO_7xvQyAL3evb9f96VUw-hXjvkZkw%40mail.gmail.com</a>.<br />

--0000000000007196bd056ab41001--

.

--94eb2c1925c0a4cbeb056ab760c7
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018 at 5:47 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

>
>
> On Wed, Apr 25, 2018, 18:00 Nevin Liber <nevin@eviloverlord.com> wrote:
>
>> On Wed, Apr 25, 2018 at 4:51 PM, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> Then would you or would you not be in favor of a proposal to require
>>> that we do not enter the valueless_by_exception state here? Tony's concern
>>> is that the current specification implies that we can get to
>>> valueless_by_exception in an assignment even when a move constructor does
>>> not actually throw, which is currently true. Should we "fix" this in a
>>> future standard or consider to be fine?
>>>
>>
>> I would be against because we have better things to do with committee
>> time.
>>
>> Variations on Boost.Variant, which IIRC picks the first no-throw
>> default-constructible type on the type list. were already discussed and
>> rejected.
>>
>
> I'll restate: I'm pretty sure you are misunderstanding the specific case
> we are talking about. Forget about Boost.Variant or a lack of valueless by
> exception -- that ship sailed and this has little to do with it. I am not
> at all saying we should try to change consensus on something that already
> shipped. Look again at the example -- we are getting to the valueless by
> exception state from an assignment operation without ever even having a
> move operation that throws, which many advocates of valueless by exception
> did not want. We certainly can avoid this if the committee decided (this is
> in line with expressed intent and we've already made other changes to
> minimize valueless by exception).
>

As Tony said:

Why doesn't variant revert back to the int when the copy throws?  We don't
> want to pay for the moves?


No, I don't want to pay for the moves.  Moves aren't free, and at times
they aren't even cheap.

Maybe I'm misinterpreting the above, but the way being proposed to avoid
valueless_by_exception is by introducing an extra move operation to
temporarily double buffer, *which is a performance pessimization on the far
more common case of not throwing*.  Oh, and that move operation may
*terminate*, because noexcept only guarantees that an exception will not
escape the function call.


The people I have worked with have consistently wanted variant to be as
fast as possible in the non-exception case.

When the choice was between not having variant in the standard and having a
variant that may not be as fast as possible, I chose the former, because
having variant in the standard was strictly better than not having it.
Consensus isn't about getting what you want; it's about getting what you
can live with.

Now that it shipped with C++17, I no longer have to make performance
compromises with regards to variant.  And I certainly don't want to tell
users that if they want their variants to perform better, they should mark
their operations as noexcept(false) so as not to trigger the pessimization.

And we already spent a huge amount of committee time debating these
issues.  There is nothing new here.  Reopening debate just because either
the grass is greener on the other side, or people didn't quite get their
way the first n times we debated it isn't productive.  Without new
information being presented, I don't see the point.


> I agree that particular aspect hasn't changed. I'm also not sure you
> realize that I am speaking for those who I disagree with -- members who
> advocated for valueless by exception explicitly want to minimize getting
> into the valueless by exception state. If we don't care to make further
> changes then that is fine, but I do not understand the backlash. We've
> already made changes akin to this during standardization "with no new
> information". Let's at least figure out what the committee's actual goal is
> here.
>

The committee (and not just one of the WGs) debated variant in an evening
session and came to consensus, which we shipped.  We are back to what
individual members, and not the committee as a whole, wants.


> It seems that no matter which side I speak for on this topic I'm either
> explicitly called insane or get pounced on. It's getting ridiculous and is
> not indicative of an environment where people can speak their mind.
>

I have no power to stop you.  Really.  If you or Tony wish to make a
proposal, I cannot stop you.  If you two wish to try and schedule a Make
Variant Great Again session in Rapperswil, I cannot stop you.  All I can
try and do is persuade you not to.

But make no mistake:  spending committee time re-debating is committee time
we aren't spending on something more positive.

For instance, in JAX we had to spend nearly a day debating making the
built-in signed integer types always wrap, and by doing so we didn't get to
any papers that might have added new operations and/or types that wrap.
Was it necessary?  Yes, because by our rules we had to debate it.  Was it a
good use of our time?  IMO, no, both because it was extremely unlikely that
wrapping the built in signed types would pass (it didn't) and now we don't
have any progress on adding ops/types that wrap.
--
 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%2BM5D0myUuEqeyQ0nSgGYE_wzewBAOjUQQGsXu0s_gHCxg%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, Apr 25, 2018 at 5:47 PM, &#39;Matt Calabrese&#39; =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex"><div dir=3D"auto"><span><div><br><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr">On Wed, Apr 25, 2018, 18:00 Nevin Liber &lt;<a hr=
ef=3D"mailto:nevin@eviloverlord.com" rel=3D"noreferrer" target=3D"_blank">n=
evin@eviloverlord.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">On Wed, Apr 25, 2018 at 4:51 PM, &#39;Matt Calabrese&#39; via ISO C++ =
Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-pro=
posals@isocpp.org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-prop=
osals@isocpp.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><span><div>Then wou=
ld you or would you not be in favor of a proposal to require that we do not=
 enter the valueless_by_exception state here? Tony&#39;s concern is that th=
e current specification implies that we can get to valueless_by_exception i=
n an assignment even when a move constructor does not actually throw, which=
 is currently true. Should we &quot;fix&quot; this in a future standard or =
consider to be fine?<br></div></span></div></blockquote><div><br></div><div=
>I would be against because we have better things to do with committee time=
..</div><div><br></div><div>Variations on Boost.Variant, which IIRC picks th=
e first no-throw default-constructible type on the type list. were already =
discussed and rejected.</div></div></div></div></blockquote></div></div><di=
v dir=3D"auto"><br></div></span><div dir=3D"auto">I&#39;ll restate: I&#39;m=
 pretty sure you are misunderstanding the specific case we are talking abou=
t. Forget about Boost.Variant or a lack of valueless by exception -- that s=
hip sailed and this has little to do with it. I am not at all saying we sho=
uld try to change consensus on something that already shipped. Look again a=
t the example -- we are getting to the valueless by exception state from an=
 assignment operation without ever even having a move operation that throws=
, which many advocates of valueless by exception did not want. We certainly=
 can avoid this if the committee decided (this is in line with expressed in=
tent and we&#39;ve already made other changes to minimize valueless by exce=
ption).</div></div></blockquote><div><br></div><div>As Tony said:</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><span style=3D"font-size:12.800000190734863px">=
Why doesn&#39;t=C2=A0</span><span class=3D"gmail-il" style=3D"font-size:12.=
800000190734863px">variant</span><span style=3D"font-size:12.80000019073486=
3px">=C2=A0revert back to the int when the copy throws?=C2=A0 We don&#39;t =
want to pay for the moves?</span>=C2=A0</blockquote><div><br></div><div>No,=
 I don&#39;t want to pay for the moves.=C2=A0 Moves aren&#39;t free, and at=
 times they aren&#39;t even cheap.</div><div><br></div><div>Maybe I&#39;m m=
isinterpreting the above, but the way being proposed to avoid valueless_by_=
exception is by introducing an extra move operation to temporarily double b=
uffer, <i>which is a performance pessimization on the far more common case =
of not throwing</i>.=C2=A0 Oh, and that move operation may <i>terminate</i>=
, because noexcept only guarantees that an exception will not escape the fu=
nction call.</div><div><br></div><div><br></div><div>The people I have work=
ed with have consistently wanted variant to be as fast as possible in the n=
on-exception case.</div><div><br></div><div>When the choice was between not=
 having variant in the standard and having a variant that may not be as fas=
t as possible, I chose the former, because having variant in the standard w=
as strictly better than not having it.=C2=A0 Consensus isn&#39;t about gett=
ing what you want; it&#39;s about getting what you can live with.</div><div=
><br></div><div>Now that it shipped with C++17, I no longer have to make pe=
rformance compromises with regards to variant.=C2=A0 And I certainly don&#3=
9;t want to tell users that if they want their variants to perform better, =
they should mark their operations as noexcept(false) so as not to trigger t=
he pessimization.</div><div><br></div><div>And we already spent a huge amou=
nt of committee time debating these issues.=C2=A0 There is nothing new here=
..=C2=A0 Reopening debate just because either the grass is greener on the ot=
her side, or people didn&#39;t quite get their way the first n times we deb=
ated it isn&#39;t productive.=C2=A0 Without new information being presented=
, I don&#39;t see the point.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div di=
r=3D"auto"><div dir=3D"auto">I agree that particular aspect hasn&#39;t chan=
ged. I&#39;m also not sure you realize that I am speaking for those who I d=
isagree with -- members who advocated for valueless by exception explicitly=
 want to minimize getting into the valueless by exception state. If we don&=
#39;t care to make further changes then that is fine, but I do not understa=
nd the backlash. We&#39;ve already made changes akin to this during standar=
dization &quot;with no new information&quot;. Let&#39;s at least figure out=
 what the committee&#39;s actual goal is here.</div></div></blockquote><div=
><br></div><div>The committee (and not just one of the WGs) debated variant=
 in an evening session and came to consensus, which we shipped.=C2=A0 We ar=
e back to what individual members, and not the committee as a whole, wants.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"=
>It seems that no matter which side I speak for on this topic I&#39;m eithe=
r explicitly called insane or get pounced on. It&#39;s getting ridiculous a=
nd is not indicative of an environment where people can speak their mind.<b=
r></div></div></blockquote><div><br></div><div>I have no power to stop you.=
=C2=A0 Really.=C2=A0 If you or Tony wish to make a proposal, I cannot stop =
you.=C2=A0 If you two wish to try and schedule a Make Variant Great Again s=
ession in Rapperswil, I cannot stop you.=C2=A0 All I can try and do is pers=
uade you not to.</div><div><br></div><div>But make no mistake: =C2=A0spendi=
ng committee time re-debating is committee time we aren&#39;t spending on s=
omething more positive.</div><div><br></div><div>For instance, in JAX we ha=
d to spend nearly a day debating making the built-in signed integer types a=
lways wrap, and by doing so we didn&#39;t get to any papers that might have=
 added new operations and/or types that wrap.=C2=A0 Was it necessary?=C2=A0=
 Yes, because by our rules we had to debate it.=C2=A0 Was it a good use of =
our time?=C2=A0 IMO, no, both because it was extremely unlikely that wrappi=
ng the built in signed types would pass (it didn&#39;t) and now we don&#39;=
t have any progress on adding ops/types that wrap.</div><div>--=C2=A0<br></=
div></div><div class=3D"gmail-m_4940659453944466467gmail_signature"><div di=
r=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><wbr>&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%2BM5D0myUuEqeyQ0nSgGYE_wzewBAO=
jUQQGsXu0s_gHCxg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM5D0my=
UuEqeyQ0nSgGYE_wzewBAOjUQQGsXu0s_gHCxg%40mail.gmail.com</a>.<br />

--94eb2c1925c0a4cbeb056ab760c7--

.

------=_Part_4619_117507586.1524749593578
Content-Type: multipart/alternative;
 boundary="----=_Part_4620_1603175667.1524749593578"

------=_Part_4620_1603175667.1524749593578
Content-Type: text/plain; charset="UTF-8"

On Wednesday, April 25, 2018 at 10:45:18 PM UTC-4, Nevin ":-)" Liber wrote:
>
> For instance, in JAX we had to spend nearly a day debating making the
> built-in signed integer types always wrap, and by doing so we didn't get to
> any papers that might have added new operations and/or types that wrap.
> Was it necessary?  Yes, because by our rules we had to debate it.  Was it a
> good use of our time?  IMO, no, both because it was extremely unlikely that
> wrapping the built in signed types would pass (it didn't) and now we don't
> have any progress on adding ops/types that wrap.
>

I disagree with the idea that such a discussion was not a good use of time.
If you pre-emptively ignore people without giving them a fair hearing, you
create problems down the line. By giving these minority viewpoints a fair
hearing, even if they're unlikely to succeed, you at least give them the
sense that the standardization process is reasonable. This makes such
people more likely to be willing to continue to participate in it, and it
makes the people watching the process less likely to rebel against it.

Now sure, some people will never, *ever* be satisfied by anything less than
getting exactly what they want. For them, a hearing is "fair" based on its
output; if it comes to the "right" conclusion (ie: they get what they
want), then its "fair". But there's nothing to be done for such people, so
we need not give them further thought.

Democracy is slow, and from the perspective of the eventual compromise, it
appears to wastes time. But it has the advantage of making even defeated
parties feel like they're actually part of the process, rather than
subjects of some faceless oligarchy with no actual power. The importance of
that should not be so easily discounted.

I'm not saying that repeatedly debating the same points ad nausium is a
good thing. The variant discussion has already been had, and nothing has
materially changed about that discussion. But the wrapping signed integer
question was a different matter and deserved a hearing, even if it's not
something that was ever likely to pass.

--
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/21d17228-7967-4847-b2ce-f1c0be3c1406%40isocpp.org.

------=_Part_4620_1603175667.1524749593578
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, April 25, 2018 at 10:45:18 PM UTC-4, Nevin &=
quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div>For instance, in JAX we =
had to spend nearly a day debating making the built-in signed integer types=
 always wrap, and by doing so we didn&#39;t get to any papers that might ha=
ve added new operations and/or types that wrap.=C2=A0 Was it necessary?=C2=
=A0 Yes, because by our rules we had to debate it.=C2=A0 Was it a good use =
of our time?=C2=A0 IMO, no, both because it was extremely unlikely that wra=
pping the built in signed types would pass (it didn&#39;t) and now we don&#=
39;t have any progress on adding ops/types that wrap.</div></div></div></di=
v></blockquote><div><br>I disagree with the idea that such a discussion was=
 not a good use of time. If you pre-emptively ignore people without giving =
them a fair hearing, you create problems down the line. By giving these min=
ority viewpoints a fair hearing, even if they&#39;re unlikely to succeed, y=
ou at least give them the sense that the standardization process is reasona=
ble. This makes such people more likely to be willing to continue to partic=
ipate in it, and it makes the people watching the process less likely to re=
bel against it.<br><br>Now sure, some people will never, <i>ever</i> be sat=
isfied by anything less than getting exactly what they want. For them, a he=
aring is &quot;fair&quot; based on its output; if it comes to the &quot;rig=
ht&quot; conclusion (ie: they get what they want), then its &quot;fair&quot=
;. But there&#39;s nothing to be done for such people, so we need not give =
them further thought.<br><br>Democracy is slow, and from the perspective of=
 the eventual compromise, it appears to wastes time. But it has the advanta=
ge of making even defeated parties feel like they&#39;re actually part of t=
he process, rather than subjects of some faceless oligarchy with no actual =
power. The importance of that should not be so easily discounted.<br><br>I&=
#39;m not saying that repeatedly debating the same points ad nausium is a g=
ood thing. The variant discussion has already been had, and nothing has mat=
erially changed about that discussion. But the wrapping signed integer ques=
tion was a different matter and deserved a hearing, even if it&#39;s not so=
mething that was ever likely to pass.<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/21d17228-7967-4847-b2ce-f1c0be3c1406%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/21d17228-7967-4847-b2ce-f1c0be3c1406=
%40isocpp.org</a>.<br />

------=_Part_4620_1603175667.1524749593578--

------=_Part_4619_117507586.1524749593578--

.

--000000000000e66d50056ac14209
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com> wrote:

> On Wed, Apr 25, 2018 at 5:47 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>>
>> On Wed, Apr 25, 2018, 18:00 Nevin Liber <nevin@eviloverlord.com> wrote:
>>
>>> On Wed, Apr 25, 2018 at 4:51 PM, 'Matt Calabrese' via ISO C++ Standard -
>>> Future Proposals <std-proposals@isocpp.org> wrote:
>>>
>>>> Then would you or would you not be in favor of a proposal to require
>>>> that we do not enter the valueless_by_exception state here? Tony's concern
>>>> is that the current specification implies that we can get to
>>>> valueless_by_exception in an assignment even when a move constructor does
>>>> not actually throw, which is currently true. Should we "fix" this in a
>>>> future standard or consider to be fine?
>>>>
>>>
>>> I would be against because we have better things to do with committee
>>> time.
>>>
>>> Variations on Boost.Variant, which IIRC picks the first no-throw
>>> default-constructible type on the type list. were already discussed and
>>> rejected.
>>>
>>
>> I'll restate: I'm pretty sure you are misunderstanding the specific case
>> we are talking about. Forget about Boost.Variant or a lack of valueless by
>> exception -- that ship sailed and this has little to do with it. I am not
>> at all saying we should try to change consensus on something that already
>> shipped. Look again at the example -- we are getting to the valueless by
>> exception state from an assignment operation without ever even having a
>> move operation that throws, which many advocates of valueless by exception
>> did not want. We certainly can avoid this if the committee decided (this is
>> in line with expressed intent and we've already made other changes to
>> minimize valueless by exception).
>>
>
> As Tony said:
>
> Why doesn't variant revert back to the int when the copy throws?  We
>> don't want to pay for the moves?
>
>
> No, I don't want to pay for the moves.  Moves aren't free, and at times
> they aren't even cheap
>

> Maybe I'm misinterpreting the above, but the way being proposed to avoid
> valueless_by_exception is by introducing an extra move operation to
> temporarily double buffer, *which is a performance pessimization on the
> far more common case of not throwing*.
>

I agree with you, and I understand that this is also what you want -- to be
very clear, my issues with variant were whether or not we want to introduce
a "valueless by exception" state at all. Now that it is in C++17 with a
valueless by exception state, I don't actually care how frequently we get
into it. At this point, it's one of the valid states of the object
(regardless of what we call it) and we may as well go into the valueless by
exception state any time that an exception is thrown in the places where,
internally, no alternatives are active at the time that the exception would
propagate. I don't think this is even particularly weird -- it's just
something you'd expected from the basic exception guarantee, and like
anywhere else, I agree with you in that I don't think it's worthwhile to do
extra work to strengthen the guarantee in order to avoid it, since we
already have the valueless by exception state anyway. The usual process in
these cases is to just specify the guarantee that naturally comes up.

That said, as I understand it, the intent voiced by many of those who were
in favor of valueless by exception was actually to still minimize the
places where we get into the valueless by exception state. As is, variant
already very explicitly avoids the valuless by exception state and is not
afraid to perform extra moves operations to do so. For instance, when the
copy constructor can throw and the move is noexcept (an extremely common
case, mind you, and possibly even the most common case in many code-bases),
we do not simply destroy and then copy construct, specifying the valueless
by exception state in places where the copy constructor throws. Instead, we
copy-construct to a temporary and then move-assign so as to avoid the
valueless by exception state. This was not by accident, is not free, and
very explicitly uses moves in the way that you have expressed that you
personally wish to avoid. It is not at all obvious to me that the opinion
you and I have expressed actually is intent, and if it was, then overall we
are still being inconsistent. If we are okay with that then it is fine.

My personal thoughts are that, excluding certain standard library
node-based containers and things that contain them, places where neither
the copy nor move are noexcept are often likely to be the legacy case where
people define a copy constructor but not a more efficient move constructor,
and so the move there is more likely to be costly in practice (i.e. it's
more likely to be a true copy even though a more optimal move operational
could have hypothetically been written but was not). So for the sake of
practicality, I could imagine some people preferring this even when overall
they wanted to minimize entering the valueless by exception state. That
said, if those people actually cared about performance, they probably would
have added a move constructor were it in their power to do so. This
specific point may have even been discussed -- I do not recall and we can
go back and check the notes from the meetings, but the backlash I'm seeing
here is quite frankly absurd. We are not in committee, we are not even in
the internal reflectors. We are on a public list before any deep research.
We are not "wasting committee time". This is about as far away from wasting
committee time as possible while still being able to get interested parties
involved in an early discussion if they so choose.

On Wed, Apr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com> wrote:

> Oh, and that move operation may *terminate*, because noexcept only
> guarantees that an exception will not escape the function call.
>

I'm not sure what point you are making here. Are you just giving this as an
example of why it is a breaking change? Yes, it certainly is. I've already
expressed that it is. Even if it doesn't terminate we would change
operations that were explicitly specified to take place.

On Wed, Apr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com> wrote:

> Consensus isn't about getting what you want; it's about getting what you
> can live with.
>

We're going off on a tangent now, but I find that point of view regarding
the committee and consensus somewhat disappointing. Yes, consensus isn't
about getting exactly what you want, however the primary goal of
participating in the committee is not "coming to a consensus" -- it's about
trying to make the language as solid and as consistent as it can be and to
standardize existing practice. Consensus is just our best shot at getting
there. Sometimes consensus leads us to an odd or inconsistent state that
people didn't fully anticipate. Sometimes, we unfortunately design by
committee instead of standardizing existing practice. Members should not be
afraid to identify those cases and try to fix them "because consensus".
This is especially true in cases where "consensus" is often an extremely
small subset of the committee, which itself is already an extremely small
subset of the C++ community (not referring to variant in this case, but
rather other goings-on in the committee as papers make their way through
subgroups). One would hope we are better than that.

On Wed, Apr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com> wrote:

> Now that it shipped with C++17, I no longer have to make performance
> compromises with regards to variant.  And I certainly don't want to tell
> users that if they want their variants to perform better, they should mark
> their operations as noexcept(false) so as not to trigger the pessimization.
>

Who said that adding noexcept(false) would avoid a pessimization? The case
we are talking about "pessimizing" is precisely where both copies and moves
are *already* noexcept(false). And to be clear, library already
"pessimizes" in an actual common case (noexcept move, non-noexcept copy)
because of how variant defines operator= when move is noexcept but copy is
not. We do the extra move in this case -- that is the reality, whether you
or I like it. When both are noexcept, though, we do not make any
sacrifices, and that would never change. I don't understand where you are
expecting to have to tell people to add noexcept(false), whether today or
in some hypothetical future. Someone correct me if I'm wrong here and am
missing something subtle.

On Wed, Apr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com> wrote:

> For instance, in JAX we had to spend nearly a day debating making the
> built-in signed integer types always wrap, and by doing so we didn't get to
> any papers that might have added new operations and/or types that wrap.
> Was it necessary?  Yes, because by our rules we had to debate it.  Was it a
> good use of our time?  IMO, no, both because it was extremely unlikely that
> wrapping the built in signed types would pass (it didn't) and now we don't
> have any progress on adding ops/types that wrap.
>

I wasn't at JAX this time around, but I do agree. Ideally, if we just did a
very quick "over my dead body" poll in plenary before the week even
started, I would have expected it to be killed before any broader
discussion took place. I didn't check to see if something like this
actually happened for signed integer wrap, but I would have thought this
would have killed the discussion pretty quickly. If that poll happened and
it didn't kill it outright, then I am genuinely surprised.

--
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/CANh8DEmuDWSVCgg41dqv9pBwWB1x6%3DS1anau_R6_X_1ZX1EK6w%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"auto"><div><br><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Wed, Apr 25, 2018, 22:45 Nevin Liber &lt;<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wed, A=
pr 25, 2018 at 5:47 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard - Fut=
ure Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.=
org" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>&gt;<=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"auto"><span><div><br><br><div class=3D"gmail_quote=
"><div dir=3D"ltr">On Wed, Apr 25, 2018, 18:00 Nevin Liber &lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" rel=3D"noreferrer noreferrer" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">On Wed, Apr 25, 2018 at 4:51 PM, &#39;Matt Calabrese&#39; via ISO =
C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std=
-proposals@isocpp.org" rel=3D"noreferrer noreferrer noreferrer" target=3D"_=
blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><spa=
n><div>Then would you or would you not be in favor of a proposal to require=
 that we do not enter the valueless_by_exception state here? Tony&#39;s con=
cern is that the current specification implies that we can get to valueless=
_by_exception in an assignment even when a move constructor does not actual=
ly throw, which is currently true. Should we &quot;fix&quot; this in a futu=
re standard or consider to be fine?<br></div></span></div></blockquote><div=
><br></div><div>I would be against because we have better things to do with=
 committee time.</div><div><br></div><div>Variations on Boost.Variant, whic=
h IIRC picks the first no-throw default-constructible type on the type list=
.. were already discussed and rejected.</div></div></div></div></blockquote>=
</div></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">I&#39;ll r=
estate: I&#39;m pretty sure you are misunderstanding the specific case we a=
re talking about. Forget about Boost.Variant or a lack of valueless by exce=
ption -- that ship sailed and this has little to do with it. I am not at al=
l saying we should try to change consensus on something that already shippe=
d. Look again at the example -- we are getting to the valueless by exceptio=
n state from an assignment operation without ever even having a move operat=
ion that throws, which many advocates of valueless by exception did not wan=
t. We certainly can avoid this if the committee decided (this is in line wi=
th expressed intent and we&#39;ve already made other changes to minimize va=
lueless by exception).</div></div></blockquote><div><br></div><div>As Tony =
said:</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-lef=
t-color:rgb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.8000=
00190734863px">Why doesn&#39;t=C2=A0</span><span class=3D"m_288563901478046=
7789m_-2248898569694832541gmail-il" style=3D"font-size:12.800000190734863px=
">variant</span><span style=3D"font-size:12.800000190734863px">=C2=A0revert=
 back to the int when the copy throws?=C2=A0 We don&#39;t want to pay for t=
he moves?</span>=C2=A0</blockquote><div><br></div><div>No, I don&#39;t want=
 to pay for the moves.=C2=A0 Moves aren&#39;t free, and at times they aren&=
#39;t even cheap</div></div></div></div></blockquote></div></div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></=
div><div>Maybe I&#39;m misinterpreting the above, but the way being propose=
d to avoid valueless_by_exception is by introducing an extra move operation=
 to temporarily double buffer, <i>which is a performance pessimization on t=
he far more common case of not throwing</i>.</div></div></div></div></block=
quote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I agree wit=
h you, and I understand that this is also what you want -- to be very clear=
, my issues with variant were whether or not we want to introduce a &quot;v=
alueless by exception&quot; state at all. Now that it is in C++17 with a va=
lueless by exception state, I don&#39;t actually care how frequently we get=
 into it. At this point, it&#39;s one of the valid states of the object (re=
gardless of what we call it) and we may as well go into the valueless by ex=
ception state any time that an exception is thrown in the places where, int=
ernally, no alternatives are active at the time that the exception would pr=
opagate. I don&#39;t think this is even particularly weird -- it&#39;s just=
 something you&#39;d expected from the basic exception guarantee, and like =
anywhere else, I agree with you in that I don&#39;t think it&#39;s worthwhi=
le to do extra work to strengthen the guarantee in order to avoid it, since=
 we already have the valueless by exception state anyway. The usual process=
 in these cases is to just specify the guarantee that naturally comes up.</=
div><div dir=3D"auto"><br></div><div>That said, as I understand it, the int=
ent voiced by many of those who were in favor of valueless by exception was=
 actually to still minimize the places where we get into the valueless by e=
xception state. As is, variant already very explicitly avoids the valuless =
by exception state and is not afraid to perform extra moves operations to d=
o so. For instance, when the copy constructor can throw and the move is noe=
xcept (an extremely common case, mind you, and possibly even the most commo=
n case in many code-bases), we do not simply destroy and then copy construc=
t, specifying the valueless by exception state in places where the copy con=
structor throws. Instead, we copy-construct to a temporary and then move-as=
sign so as to avoid the valueless by exception state. This was not by accid=
ent, is not free, and very explicitly uses moves in the way that you have e=
xpressed that you personally wish to avoid. It is not at all obvious to me =
that the opinion you and I have expressed actually is intent, and if it was=
, then overall we are still being inconsistent. If we are okay with that th=
en it is fine.</div><div><br></div><div>My personal thoughts are that, excl=
uding certain standard library node-based containers and things that contai=
n them, places where neither the copy nor move are noexcept are often likel=
y to be the legacy case where people define a copy constructor but not a mo=
re efficient move constructor, and so the move there is more likely to be c=
ostly in practice (i.e. it&#39;s more likely to be a true copy even though =
a more optimal move operational could have hypothetically been written but =
was not). So for the sake of practicality, I could imagine some people pref=
erring this even when overall they wanted to minimize entering the valueles=
s by exception state. That said, if those people actually cared about perfo=
rmance, they probably would have added a move constructor were it in their =
power to do so. This specific point may have even been discussed -- I do no=
t recall and we can go back and check the notes from the meetings, but the =
backlash I&#39;m seeing here is quite frankly absurd. We are not in committ=
ee, we are not even in the internal reflectors. We are on a public list bef=
ore any deep research. We are not &quot;wasting committee time&quot;. This =
is about as far away from wasting committee time as possible while still be=
ing able to get interested parties involved in an early discussion if they =
so choose.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><span sty=
le=3D"font-family:sans-serif">On Wed, Apr 25, 2018, 22:45 Nevin Liber &lt;<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo=
rd.com</a>&gt; wrote:</span><br></div><div dir=3D"auto"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><div>Oh, and that move operation may <i>=
terminate</i>, because noexcept only guarantees that an exception will not =
escape the function call.</div></div></div></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m not sure what point yo=
u are making here. Are you just giving this as an example of why it is a br=
eaking change? Yes, it certainly is. I&#39;ve already expressed that it is.=
 Even if it doesn&#39;t terminate we would change operations that were expl=
icitly specified to take place.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><span style=3D"font-family:sans-serif">On Wed, Apr 25, 2018, 22:4=
5 Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt; wrote:</span></div><div dir=3D"auto"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Consensus isn&#39;t =
about getting what you want; it&#39;s about getting what you can live with.=
</div></div></div></div></blockquote></div></div><div dir=3D"auto"><br></di=
v><div>We&#39;re going off on a tangent now, but I find that point of view =
regarding the committee and consensus somewhat disappointing. Yes, consensu=
s isn&#39;t about getting exactly what you want, however the primary goal o=
f participating in the committee is not &quot;coming to a consensus&quot; -=
- it&#39;s about trying to make the language as solid and as consistent as =
it can be and to standardize existing practice. Consensus is just our best =
shot at getting there. Sometimes consensus leads us to an odd or inconsiste=
nt state that people didn&#39;t fully anticipate. Sometimes, we unfortunate=
ly design by committee instead of standardizing existing practice. Members =
should not be afraid to identify those cases and try to fix them &quot;beca=
use consensus&quot;. This is especially true in cases where &quot;consensus=
&quot; is often an extremely small subset of the committee, which itself is=
 already an extremely small subset of the C++ community (not referring to v=
ariant in this case, but rather other goings-on in the committee as papers =
make their way through subgroups). One would hope we are better than that.<=
/div><div dir=3D"auto"><br class=3D"gmail-Apple-interchange-newline"><span =
style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-sty=
le:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weigh=
t:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)=
;text-decoration-style:initial;text-decoration-color:initial;float:none;dis=
play:inline">On Wed, Apr 25, 2018, 22:45 Nevin Liber &lt;</span><a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank" style=3D"color:rgb(17,85,2=
04);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-li=
gatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255)">nevin@eviloverlord.com<=
/a><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px=
;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;f=
ont-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-=
transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255=
,255,255);text-decoration-style:initial;text-decoration-color:initial;float=
:none;display:inline">&gt; wrote:</span></div><div dir=3D"auto"><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"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Now that it shipped with C=
++17, I no longer have to make performance compromises with regards to vari=
ant.=C2=A0 And I certainly don&#39;t want to tell users that if they want t=
heir variants to perform better, they should mark their operations as noexc=
ept(false) so as not to trigger the pessimization.</div></div></div></div><=
/blockquote><div><br></div><div>Who said that adding noexcept(false) would =
avoid a pessimization? The case we are talking about &quot;pessimizing&quot=
; is precisely where both copies and moves are *already* noexcept(false). A=
nd to be clear, library already &quot;pessimizes&quot; in an actual common =
case (noexcept move, non-noexcept copy) because of how variant defines oper=
ator=3D when move is noexcept but copy is not. We do the extra move in this=
 case -- that is the reality, whether you or I like it. When both are noexc=
ept, though, we do not make any sacrifices, and that would never change. I =
don&#39;t understand where you are expecting to have to tell people to add =
noexcept(false), whether today or in some hypothetical future. Someone corr=
ect me if I&#39;m wrong here and am missing something subtle.<br></div><div=
><br class=3D"gmail-Apple-interchange-newline"><span style=3D"color:rgb(34,=
34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant=
-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style=
:initial;text-decoration-color:initial;float:none;display:inline">On Wed, A=
pr 25, 2018, 22:45 Nevin Liber &lt;</span><a href=3D"mailto:nevin@eviloverl=
ord.com" target=3D"_blank" style=3D"color:rgb(17,85,204);font-family:sans-s=
erif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-va=
riant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backg=
round-color:rgb(255,255,255)">nevin@eviloverlord.com</a><span style=3D"colo=
r:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;fon=
t-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-=
spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decorat=
ion-style:initial;text-decoration-color:initial;float:none;display:inline">=
&gt; wrote:</span></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><div>For instance, in JA=
X we had to spend nearly a day debating making the built-in signed integer =
types always wrap, and by doing so we didn&#39;t get to any papers that mig=
ht have added new operations and/or types that wrap.=C2=A0 Was it necessary=
?=C2=A0 Yes, because by our rules we had to debate it.=C2=A0 Was it a good =
use of our time?=C2=A0 IMO, no, both because it was extremely unlikely that=
 wrapping the built in signed types would pass (it didn&#39;t) and now we d=
on&#39;t have any progress on adding ops/types that wrap.</div></div></div>=
</div></blockquote><div><br></div><div>I wasn&#39;t at JAX this time around=
, but I do agree. Ideally, if we just did a very quick &quot;over my dead b=
ody&quot; poll in plenary before the week even started, I would have expect=
ed it to be killed before any broader discussion took place. I didn&#39;t c=
heck to see if something like this actually happened for signed integer wra=
p, but I would have thought this would have killed the discussion pretty qu=
ickly. If that poll happened and it didn&#39;t kill it outright, then I am =
genuinely surprised.</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/CANh8DEmuDWSVCgg41dqv9pBwWB1x6%3DS1an=
au_R6_X_1ZX1EK6w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmuDWSVCg=
g41dqv9pBwWB1x6%3DS1anau_R6_X_1ZX1EK6w%40mail.gmail.com</a>.<br />

--000000000000e66d50056ac14209--

.

--00000000000066f3eb056ac195d1
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 26, 2018 at 9:33 AM Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, April 25, 2018 at 10:45:18 PM UTC-4, Nevin ":-)" Liber wrote:
>>
>> For instance, in JAX we had to spend nearly a day debating making the
>> built-in signed integer types always wrap, and by doing so we didn't get to
>> any papers that might have added new operations and/or types that wrap.
>> Was it necessary?  Yes, because by our rules we had to debate it.  Was it a
>> good use of our time?  IMO, no, both because it was extremely unlikely that
>> wrapping the built in signed types would pass (it didn't) and now we don't
>> have any progress on adding ops/types that wrap.
>>
>
> I disagree with the idea that such a discussion was not a good use of
> time. If you pre-emptively ignore people without giving them a fair
> hearing, you create problems down the line. By giving these minority
> viewpoints a fair hearing, even if they're unlikely to succeed, you at
> least give them the sense that the standardization process is reasonable.
> This makes such people more likely to be willing to continue to participate
> in it, and it makes the people watching the process less likely to rebel
> against it.
>

I may agree on principle if we had more time, but because of how rarely the
committee actually meets, we end up having to prioritize and not all papers
can be discussed. I think the best that one can do for things like this is
identify and make sure people read the controversial paper in the mailing
and express any over-my-dead-body concerns that a debate cannot possibly
change before we even get to a meeting. If the rationale in the paper does
not change over-my-dead-body concerns and it is inconceivable that an
in-person debate would change those over-my-dead-body concerns due to
fundamental issues with the proposal, then I find it difficult to advocate
spending any time in the meeting on 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/CANh8DE%3DCj-0uQ-PELLOsj-%3DuL0vV-O0F%3D599gVwDRPXNg-R6QA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Apr 26=
, 2018 at 9:33 AM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jm=
ckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">On Wednesday, April 25, 2018 at 10:45:18 PM UTC-4, Nevin &qu=
ot;:-)&quot; Liber 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"ltr"><div><div class=3D"gmail_quote"><div>For instance, in JAX we had t=
o spend nearly a day debating making the built-in signed integer types alwa=
ys wrap, and by doing so we didn&#39;t get to any papers that might have ad=
ded new operations and/or types that wrap.=C2=A0 Was it necessary?=C2=A0 Ye=
s, because by our rules we had to debate it.=C2=A0 Was it a good use of our=
 time?=C2=A0 IMO, no, both because it was extremely unlikely that wrapping =
the built in signed types would pass (it didn&#39;t) and now we don&#39;t h=
ave any progress on adding ops/types that wrap.</div></div></div></div></bl=
ockquote><div><br>I disagree with the idea that such a discussion was not a=
 good use of time. If you pre-emptively ignore people without giving them a=
 fair hearing, you create problems down the line. By giving these minority =
viewpoints a fair hearing, even if they&#39;re unlikely to succeed, you at =
least give them the sense that the standardization process is reasonable. T=
his makes such people more likely to be willing to continue to participate =
in it, and it makes the people watching the process less likely to rebel ag=
ainst it.<br></div></div></blockquote><div><br></div><div>I may agree on pr=
inciple if we had more time, but because of how rarely the committee actual=
ly meets, we end up having to prioritize and not all papers can be discusse=
d. I think the best that one can do for things like this is identify and ma=
ke sure people read the controversial paper in the mailing and express any =
over-my-dead-body concerns that a debate cannot possibly change before we e=
ven get to a meeting. If the rationale in the paper does not change over-my=
-dead-body concerns and it is inconceivable that an in-person debate would =
change those over-my-dead-body concerns due to fundamental issues with the =
proposal, then I find it difficult to advocate spending any time in the mee=
ting on it.</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/CANh8DE%3DCj-0uQ-PELLOsj-%3DuL0vV-O0F=
%3D599gVwDRPXNg-R6QA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3DC=
j-0uQ-PELLOsj-%3DuL0vV-O0F%3D599gVwDRPXNg-R6QA%40mail.gmail.com</a>.<br />

--00000000000066f3eb056ac195d1--

.