------=_Part_7633_515428226.1532297512936
Content-Type: multipart/alternative;
 boundary="----=_Part_7634_2142251410.1532297512936"

------=_Part_7634_2142251410.1532297512936
Content-Type: text/plain; charset="UTF-8"



On Sunday, July 22, 2018 at 6:58:37 PM UTC+2, Niall Douglas wrote:
>
> The attached proposal is by a WG14 member who felt that he could improve
> on my _Fails() proposal (formerly the _Either proposal). It is posted here
> with his permission.
>
> Comments welcome.
>
> Niall
>

For me `_Fails`  work better because of explicit need for `_Try` and
`_Catch`.
This is good because it force user to choose what to do and made this very
visible.
Another thing is allow of strong typed custom error types.

--
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/a210e7bc-5958-437b-85a3-dab48a98d385%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, July 22, 2018 at 6:58:37 PM UTC+2, Nial=
l Douglas 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"lt=
r">The attached proposal is by a WG14 member who felt that he could improve=
 on my _Fails() proposal (formerly the _Either proposal). It is posted here=
 with his permission.<div><br></div><div>Comments welcome.</div><div><br></=
div><div>Niall</div></div></blockquote><div><br></div><div>For me `_Fails`=
=C2=A0 work better because of explicit need for `_Try` and `_Catch`.</div><=
div>This is good because it force user to choose what to do and made this v=
ery visible.<br></div><div> Another thing is allow of strong typed custom e=
rror types.<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/a210e7bc-5958-437b-85a3-dab48a98d385%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a210e7bc-5958-437b-85a3-dab48a98d385=
%40isocpp.org</a>.<br />

------=_Part_7634_2142251410.1532297512936--

------=_Part_7633_515428226.1532297512936--

.

------=_Part_7711_1738017687.1532300459975
Content-Type: multipart/alternative;
 boundary="----=_Part_7712_897747478.1532300459975"

------=_Part_7712_897747478.1532300459975
Content-Type: text/plain; charset="UTF-8"


"To discriminate between integers and pointers we require that all pointers
must point to data aligned at an even address, and that all error codes
should be
odd. We use then, the least significant bit of the error to discriminate
between
a pointer to some data containing further information about the error
(error is
even), and an integer that directly encodes information about the error
(error
is odd) 1"

This to me seems pretty horrible.

Overall, do we really need this 'expected' kind of type to be quite so
constrained and magic, to require an even address etc. etc.
In other words, if the type was actually something that was specified as a
'normal' C/C++ struct without any of those gymnastics and data packing
or require some carry register etc., would the code be that dramatically
worse that we should require such magic or constraints than a regular type
without all the magic and alignment requirements?

--
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/87240a3d-623f-4f7f-8e7c-fa8c9482fa72%40isocpp.org.

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

<div dir=3D"ltr"><div><br></div><div>&quot;To discriminate between integers=
 and pointers we require that all pointers<br>must point to data aligned at=
 an even address, and that all error codes should be<br>odd. We use then, t=
he least significant bit of the error to discriminate between<br>a pointer =
to some data containing further information about the error (error is<br>ev=
en), and an integer that directly encodes information about the error (erro=
r<br>is odd) 1&quot;</div><div><br></div><div>This to me seems pretty horri=
ble.</div><div><br></div><div>Overall, do we really need this &#39;expected=
&#39; kind of type to be quite so constrained and magic,=C2=A0to require an=
 even address etc. etc.</div><div>In other words, if the type was actually =
something that was specified=C2=A0as a &#39;normal&#39; C/C++ struct withou=
t any of those gymnastics and data packing or=C2=A0require some carry regis=
ter etc., would the code be that dramatically worse that we should require =
such magic or constraints than a regular type without all the magic and ali=
gnment requirements?</div><div><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/87240a3d-623f-4f7f-8e7c-fa8c9482fa72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/87240a3d-623f-4f7f-8e7c-fa8c9482fa72=
%40isocpp.org</a>.<br />

------=_Part_7712_897747478.1532300459975--

------=_Part_7711_1738017687.1532300459975--

.

------=_Part_7856_1220127829.1532333505118
Content-Type: multipart/alternative;
 boundary="----=_Part_7857_2114595971.1532333505118"

------=_Part_7857_2114595971.1532333505118
Content-Type: text/plain; charset="UTF-8"


>
> Overall, do we really need this 'expected' kind of type to be quite so
> constrained and magic, to require an even address etc. etc.
> In other words, if the type was actually something that was specified as a
> 'normal' C/C++ struct without any of those gymnastics and data packing
> or require some carry register etc., would the code be that dramatically
> worse that we should require such magic or constraints than a regular type
> without all the magic and alignment requirements?
>
> Not speaking for the above proposal, but in general, it is currently
believed that using something like the CPU carry bit ought to be zero
overhead on most CPUs, whereas a discriminant stored in the layout would
not be zero overhead on more CPUs.

The situation of RISC-V, which has no status register, is a particular
unknown. Our current best guess is that either we keep the discriminant in
the structure, or we fiddle with the return address e.g. offset it by four.
There are no good options on that architecture.

Niall

--
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/5a449c86-b0f4-4b07-b5d6-21b7adbfd63b%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>Overall, do we really need this &#39;expected&#39; kind of type to=
 be quite so constrained and magic,=C2=A0to require an even address etc. et=
c.</div><div>In other words, if the type was actually something that was sp=
ecified=C2=A0as a &#39;normal&#39; C/C++ struct without any of those gymnas=
tics and data packing or=C2=A0require some carry register etc., would the c=
ode be that dramatically worse that we should require such magic or constra=
ints than a regular type without all the magic and alignment requirements?<=
/div><div><br></div></div></blockquote><div>Not speaking for the above prop=
osal, but in general, it is currently believed that using something like th=
e CPU carry bit ought to be zero overhead on most CPUs, whereas a discrimin=
ant stored in the layout would not be zero overhead on more CPUs.</div><div=
><br></div><div>The situation of RISC-V, which has no status register, is a=
 particular unknown. Our current best guess is that either we keep the disc=
riminant in the structure, or we fiddle with the return address e.g. offset=
 it by four. There are no good options on that architecture.</div><div><br>=
</div><div>Niall=C2=A0</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/5a449c86-b0f4-4b07-b5d6-21b7adbfd63b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a449c86-b0f4-4b07-b5d6-21b7adbfd63b=
%40isocpp.org</a>.<br />

------=_Part_7857_2114595971.1532333505118--

------=_Part_7856_1220127829.1532333505118--

.

------=_Part_8410_149376670.1532365324099
Content-Type: multipart/alternative;
 boundary="----=_Part_8411_676606002.1532365324099"

------=_Part_8411_676606002.1532365324099
Content-Type: text/plain; charset="UTF-8"

On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, Niall Douglas wrote:
>
> The attached proposal is by a WG14 member who felt that he could improve
> on my _Fails() proposal (formerly the _Either proposal). It is posted here
> with his permission.
>
> Comments welcome.
>
> Niall
>

This seems like a step back from earlier proposals, without any rationale
given for any of the differences. For example:

Why switch from the expression-based `return _Fail(error);` to the
imperative `name_of_the_current_function.error = error; return
_Exception;`? The latter still has the magic `_Exception` value, but now
also has the potential for name collisions, the potential to `return
_Exception` without ever setting the error, and needless verbosity.

Why place further requirements on the error value? It may be nice to have a
standard way to indicate error code vs error pointer, but the "even/odd"
requirement breaks the ability to use existing error codes *and* existing
error pointers! APIs and their clients will have to agree on *which* error
codes/pointers are meaningful regardless, so this defeats the purpose of
improving interoperability, and would likely doom this feature to be
completely unused.

Why the requirement that the `failed` bit be volatile, and readable only
immediately after the call? This seems like a misunderstanding of compiler
implementation- register allocators already have the necessary machinery to
lift these restrictions, which they must use regularly to handle normal
register-based calling conventions regardless.

--
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/e9a98a5f-cbb9-45ad-9380-253318a8108c%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, Niall Dougla=
s 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">The a=
ttached proposal is by a WG14 member who felt that he could improve on my _=
Fails() proposal (formerly the _Either proposal). It is posted here with hi=
s permission.<div><br></div><div>Comments welcome.</div><div><br></div><div=
>Niall</div></div></blockquote><div><br></div><div>This seems like a step b=
ack from earlier proposals, without any rationale given for any of the diff=
erences. For example:<br></div><div><br></div><div>Why switch from the expr=
ession-based `return _Fail(error);` to the imperative `name_of_the_current_=
function.error =3D error; return _Exception;`? The latter still has the mag=
ic `_Exception` value, but now also has the potential for name collisions, =
the potential to `return _Exception` without ever setting the error, and ne=
edless verbosity.<br></div><div><br></div><div>Why place further requiremen=
ts on the error value? It may be nice to have a standard way to indicate er=
ror code vs error pointer, but the &quot;even/odd&quot; requirement breaks =
the ability to use existing error codes *and* existing error pointers! APIs=
 and their clients will have to agree on *which* error codes/pointers are m=
eaningful regardless, so this defeats the purpose of improving interoperabi=
lity, and would likely doom this feature to be completely unused.</div><div=
><br></div><div>Why the requirement that the `failed` bit be volatile, and =
readable only immediately after the call? This seems like a misunderstandin=
g of compiler implementation- register allocators already have the necessar=
y machinery to lift these restrictions, which they must use regularly to ha=
ndle normal register-based calling conventions regardless.<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/e9a98a5f-cbb9-45ad-9380-253318a8108c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e9a98a5f-cbb9-45ad-9380-253318a8108c=
%40isocpp.org</a>.<br />

------=_Part_8411_676606002.1532365324099--

------=_Part_8410_149376670.1532365324099--

.

------=_Part_8519_1714243726.1532367012993
Content-Type: multipart/alternative;
 boundary="----=_Part_8520_1785100287.1532367012993"

------=_Part_8520_1785100287.1532367012993
Content-Type: text/plain; charset="UTF-8"



On Monday, July 23, 2018 at 10:11:45 AM UTC+2, Niall Douglas wrote:
>
> Overall, do we really need this 'expected' kind of type to be quite so
>> constrained and magic, to require an even address etc. etc.
>> In other words, if the type was actually something that was specified as
>> a 'normal' C/C++ struct without any of those gymnastics and data packing
>> or require some carry register etc., would the code be that dramatically
>> worse that we should require such magic or constraints than a regular type
>> without all the magic and alignment requirements?
>>
>> Not speaking for the above proposal, but in general, it is currently
> believed that using something like the CPU carry bit ought to be zero
> overhead on most CPUs, whereas a discriminant stored in the layout would
> not be zero overhead on more CPUs.
>
> The situation of RISC-V, which has no status register, is a particular
> unknown. Our current best guess is that either we keep the discriminant in
> the structure, or we fiddle with the return address e.g. offset it by four.
> There are no good options on that architecture.
>
> Niall
>

On RISC-V then cost will be same to `bool foo(void* ret)`. This will be
still "zero overhead", simply for other architectures it will be "negative
overhead" compared to equivalent manual checks in code.

Another way could be use RVO-like calling convention. Place for return
union with discriminant will be pass as one pointer to function, this
storage could even be reused by next function if it return same error type.

--
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/c3b7a4c0-b76a-4b23-817c-abd445c270c1%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, July 23, 2018 at 10:11:45 AM UTC+2, Nia=
ll Douglas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Overall, =
do we really need this &#39;expected&#39; kind of type to be quite so const=
rained and magic,=C2=A0to require an even address etc. etc.</div><div>In ot=
her words, if the type was actually something that was specified=C2=A0as a =
&#39;normal&#39; C/C++ struct without any of those gymnastics and data pack=
ing or=C2=A0require some carry register etc., would the code be that dramat=
ically worse that we should require such magic or constraints than a regula=
r type without all the magic and alignment requirements?</div><div><br></di=
v></div></blockquote><div>Not speaking for the above proposal, but in gener=
al, it is currently believed that using something like the CPU carry bit ou=
ght to be zero overhead on most CPUs, whereas a discriminant stored in the =
layout would not be zero overhead on more CPUs.</div><div><br></div><div>Th=
e situation of RISC-V, which has no status register, is a particular unknow=
n. Our current best guess is that either we keep the discriminant in the st=
ructure, or we fiddle with the return address e.g. offset it by four. There=
 are no good options on that architecture.</div><div><br></div><div>Niall=
=C2=A0</div></div></blockquote><div><br></div><div>On RISC-V then cost will=
 be same to `bool foo(void* ret)`. This will be still &quot;zero overhead&q=
uot;, simply for other architectures it will be &quot;negative overhead&quo=
t; compared to equivalent manual checks in code.</div><div><br></div><div>A=
nother way could be use RVO-like calling convention. Place for return union=
 with discriminant will be pass as one pointer to function, this storage co=
uld even be reused by next function if it return same error type.</div><div=
><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/c3b7a4c0-b76a-4b23-817c-abd445c270c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c3b7a4c0-b76a-4b23-817c-abd445c270c1=
%40isocpp.org</a>.<br />

------=_Part_8520_1785100287.1532367012993--

------=_Part_8519_1714243726.1532367012993--

.

------=_Part_8239_978675479.1532367244429
Content-Type: multipart/alternative;
 boundary="----=_Part_8240_53264138.1532367244429"

------=_Part_8240_53264138.1532367244429
Content-Type: text/plain; charset="UTF-8"



On Monday, July 23, 2018 at 10:30:13 AM UTC-7, Marcin Jaczewski wrote:

>
> On RISC-V then cost will be same to `bool foo(void* ret)`. This will be
> still "zero overhead", simply for other architectures it will be "negative
> overhead" compared to equivalent manual checks in code.
>
> Another way could be use RVO-like calling convention. Place for return
> union with discriminant will be pass as one pointer to function, this
> storage could even be reused by next function if it return same error type.
>

A third option is to match the behavior of other platforms, and store the
discriminant in an extra register. There should already be plenty of
caller-saved registers in the ABI, used primarily for passing arguments-
their use could be extended to the return value's discriminant. This would
also be "negative overhead" compared to passing a pointer.

--
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/5a247f18-6cf7-4b92-8572-877c6ffc8da4%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, July 23, 2018 at 10:30:13 AM UTC-7, Mar=
cin Jaczewski wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><br></div><div>On RISC-V then cost will be same to `bool fo=
o(void* ret)`. This will be still &quot;zero overhead&quot;, simply for oth=
er architectures it will be &quot;negative overhead&quot; compared to equiv=
alent manual checks in code.</div><div><br></div><div>Another way could be =
use RVO-like calling convention. Place for return union with discriminant w=
ill be pass as one pointer to function, this storage could even be reused b=
y next function if it return same error type.</div></div></blockquote><div>=
<br></div><div>A third option is to match the behavior of other platforms, =
and store the discriminant in an extra register. There should already be pl=
enty of caller-saved registers in the ABI, used primarily for passing argum=
ents- their use could be extended to the return value&#39;s discriminant. T=
his would also be &quot;negative overhead&quot; compared to passing a point=
er.<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/5a247f18-6cf7-4b92-8572-877c6ffc8da4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a247f18-6cf7-4b92-8572-877c6ffc8da4=
%40isocpp.org</a>.<br />

------=_Part_8240_53264138.1532367244429--

------=_Part_8239_978675479.1532367244429--

.

------=_Part_8398_1591993824.1532368470816
Content-Type: multipart/alternative;
 boundary="----=_Part_8399_1467947416.1532368470816"

------=_Part_8399_1467947416.1532368470816
Content-Type: text/plain; charset="UTF-8"


>
>
> This seems like a step back from earlier proposals, without any rationale
> given for any of the differences. For example:
>
> Just to be clear, this is not my proposal. This is a counterproposal to my
proposal by a WG14 member who feels that my proposal does not suit C well.

Niall

--
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/0f505fb3-1f16-4e19-b54c-444943eb7091%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>This seems like a step back from earlier proposals,=
 without any rationale given for any of the differences. For example:<br></=
div><div><br></div></div></blockquote><div>Just to be clear, this is not my=
 proposal. This is a counterproposal to my proposal by a WG14 member who fe=
els that my proposal does not suit C well.</div><div><br></div><div>Niall=
=C2=A0</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/0f505fb3-1f16-4e19-b54c-444943eb7091%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f505fb3-1f16-4e19-b54c-444943eb7091=
%40isocpp.org</a>.<br />

------=_Part_8399_1467947416.1532368470816--

------=_Part_8398_1591993824.1532368470816--

.

------=_Part_8717_965850256.1532383644602
Content-Type: multipart/alternative;
 boundary="----=_Part_8718_1741114569.1532383644602"

------=_Part_8718_1741114569.1532383644602
Content-Type: text/plain; charset="UTF-8"

On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, Niall Douglas wrote:
>
> Comments welcome.
>

I like the idea of recycling the function name to set the return value. Is
that original in the paper or has the idea been expressed before?

Thanks


--
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/1c229827-6d5d-45bd-8766-c3af818b2b0b%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, Niall Dougla=
s 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>=
Comments welcome.</div></div></blockquote><div><br></div><div>I like the id=
ea of recycling the function name to set the return value. Is that original=
 in the paper or has the idea been expressed before?</div><div><br></div><d=
iv>Thanks<br>=C2=A0</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/1c229827-6d5d-45bd-8766-c3af818b2b0b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1c229827-6d5d-45bd-8766-c3af818b2b0b=
%40isocpp.org</a>.<br />

------=_Part_8718_1741114569.1532383644602--

------=_Part_8717_965850256.1532383644602--

.

------=_Part_8777_1510610408.1532384368707
Content-Type: multipart/alternative;
 boundary="----=_Part_8778_44890467.1532384368707"

------=_Part_8778_44890467.1532384368707
Content-Type: text/plain; charset="UTF-8"

Would it be unthinkable for C to implement this limited form of throw/catch
system in full? After all almost all C compilers are also C++ compilers so
the implementation job is probably negative (you don't have to
differentiate between languages in the compiler code).

I guess the main problem would be the keywords as such, but maybe the
__throw/__except that is already used (and thereby reserved) in MSVC can be
used at least.


Den tisdag 24 juli 2018 kl. 00:07:24 UTC+2 skrev Vinnie Falco:
>
> On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, Niall Douglas wrote:
>>
>> Comments welcome.
>>
>
> I like the idea of recycling the function name to set the return value. Is
> that original in the paper or has the idea been expressed before?
>
> Thanks
>
>

--
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/fedd123c-a385-49cb-b9b0-6b9ef4e29671%40isocpp.org.

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

<div dir=3D"ltr">Would it be unthinkable for C to implement this limited fo=
rm of throw/catch system in full? After all almost all C compilers are also=
 C++ compilers so the implementation job is probably negative (you don&#39;=
t have to differentiate between languages in the compiler code).<div><br></=
div><div>I guess the main problem would be the keywords as such, but maybe =
the __throw/__except that is already used (and thereby reserved) in MSVC ca=
n be used at least.=C2=A0</div><div><br></div><div><br>Den tisdag 24 juli 2=
018 kl. 00:07:24 UTC+2 skrev Vinnie Falco:<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">On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, =
Niall Douglas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>Comments welcome.</div></div></blockquote><div><br></div><div>I like=
 the idea of recycling the function name to set the return value. Is that o=
riginal in the paper or has the idea been expressed before?</div><div><br><=
/div><div>Thanks<br>=C2=A0</div></div></blockquote></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/fedd123c-a385-49cb-b9b0-6b9ef4e29671%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fedd123c-a385-49cb-b9b0-6b9ef4e29671=
%40isocpp.org</a>.<br />

------=_Part_8778_44890467.1532384368707--

------=_Part_8777_1510610408.1532384368707--

.

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

Error handling via an effective static state isn't thread safe. Marking the
flag as volatile and telling users to check for errors immediately after
the function call goes some way to help, I guess, but it's not sufficient
to guarantee that errors won't crop up in the wrong thread (or do I have
some reading to do?)

This issue is conceded in the paper, albeit referenced as "complicated
function calls", but later they state that the C standard library should
make this ubiquitous.

It follows that any code using this approach in future (and any code that
calls that code, and so on) is not thread safe. Any error which occurs in
one thread could pop up as an error in a different thread - and depending
how deep that error handling code is in a library, this could have a
devastating impact.

An option is to have the error structs as an array indexed by
thrd_current(). This means dynamic allocation and the introduction of
helper functions rather than the nice direct struct member access, and thus
it is unlikely to gain much traction.

--
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/CAC%2B0CCP_jeR%3Dfr7a%2BXVeVJ%2B0wm4KG9U6iEunOHk3y2qSi3jrjg%40mail.gmail.com.

--0000000000004130860571b50d36
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">Error ha=
ndling via an effective static state isn&#39;t thread safe. Marking the fla=
g as volatile and telling users to check for errors immediately after the f=
unction call goes some way to help, I guess, but it&#39;s not sufficient to=
 guarantee that errors won&#39;t crop up in the wrong thread (or do I have =
some reading to do?)</div></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This issue is conceded in the paper,=C2=A0albeit referenced as &q=
uot;complicated function calls&quot;, but later they state that the C stand=
ard library should make this ubiquitous.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">It follows that any code using this approach in future (an=
d any code that calls that code, and so on) is not thread safe. Any error w=
hich occurs in one thread could pop up as an error in a different thread - =
and depending how deep that error handling code is in a library, this could=
 have a devastating impact.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">An option is to have the error structs as an array indexed by thrd_curr=
ent(). This means dynamic allocation and the introduction of helper functio=
ns rather than the nice direct struct member access, and thus it is unlikel=
y to gain much traction.</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/CAC%2B0CCP_jeR%3Dfr7a%2BXVeVJ%2B0wm4K=
G9U6iEunOHk3y2qSi3jrjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
P_jeR%3Dfr7a%2BXVeVJ%2B0wm4KG9U6iEunOHk3y2qSi3jrjg%40mail.gmail.com</a>.<br=
 />

--0000000000004130860571b50d36--

.

------=_Part_3648_525886493.1532407437861
Content-Type: multipart/alternative;
 boundary="----=_Part_3649_1482762122.1532407437861"

------=_Part_3649_1482762122.1532407437861
Content-Type: text/plain; charset="UTF-8"

On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinstall wrote:
>
> Error handling via an effective static state isn't thread safe. Marking
> the flag as volatile and telling users to check for errors immediately
> after the function call goes some way to help, I guess, but it's not
> sufficient to guarantee that errors won't crop up in the wrong thread (or
> do I have some reading to do?)
>

I think this is a misunderstanding of what the paper is saying. It is not
talking about "static state" (even though it appears to). The
`funcName.failed` bit is not intended to be a static property of
`funcName`; it's closer to an invisible stack variable, which you access by
using the function's name. The compiler turns "funcName.failed" into the
specific stack location or register or whatever that maps to that data.

Everything is on the stack, so nothing from other threads can influence
this one. That is, two functions in two threads that both call `funcName`
and attempt to access `funcName.failed` will be accessing stack
data/registers, not static data.

--
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/4ac80882-16fc-4ab4-9a12-64da1ef0e974%40isocpp.org.

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

<div dir=3D"ltr">On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinst=
all wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><d=
iv><div class=3D"gmail_quote"><div dir=3D"ltr">Error handling via an effect=
ive static state isn&#39;t thread safe. Marking the flag as volatile and te=
lling users to check for errors immediately after the function call goes so=
me way to help, I guess, but it&#39;s not sufficient to guarantee that erro=
rs won&#39;t crop up in the wrong thread (or do I have some reading to do?)=
</div></div></div></div></blockquote><div><br></div><div>I think this is a =
misunderstanding of what the paper is saying. It is not talking about &quot=
;static state&quot; (even though it appears to). The `funcName.failed` bit =
is not intended to be a static property of `funcName`; it&#39;s closer to a=
n invisible stack variable, which you access by using the function&#39;s na=
me. The compiler turns &quot;funcName.failed&quot; into the specific stack =
location or register or whatever that maps to that data.<br></div><div><br>=
</div><div>Everything is on the stack, so nothing from other threads can in=
fluence this one. That is, two functions in two threads that both call `fun=
cName` and attempt to access `funcName.failed` will be accessing stack data=
/registers, not static data.</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4ac80882-16fc-4ab4-9a12-64da1ef0e974%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4ac80882-16fc-4ab4-9a12-64da1ef0e974=
%40isocpp.org</a>.<br />

------=_Part_3649_1482762122.1532407437861--

------=_Part_3648_525886493.1532407437861--

.

------=_Part_8818_1047639448.1532420424347
Content-Type: multipart/alternative;
 boundary="----=_Part_8819_211700596.1532420424347"

------=_Part_8819_211700596.1532420424347
Content-Type: text/plain; charset="UTF-8"

On Monday, July 23, 2018 at 11:19:28 PM UTC+1, Bengt Gustafsson wrote:
>
> Would it be unthinkable for C to implement this limited form of
> throw/catch system in full? After all almost all C compilers are also C++
> compilers so the implementation job is probably negative (you don't have to
> differentiate between languages in the compiler code).
>

The next draft of my D1095 proposal is a one-to-one mapping into C of P0709
deterministic exceptions + P1028 std::error. The mechanism I think has
consensus on WG14. The choice of standard error object (std::error) is
disliked by a significant minority in C because you must fall back onto
either a library or macro based API to construct and inspect such objects.

Now, me personally, I find that acceptable, though obviously laborious to
work with. Some on WG14 want the compiler to hide more boilerplate. Hence
the counterproposal.

The next draft of D1095 I think won't mention any standard error object.
That can be another paper for WG14, and we in C++ can simply provide a C
macro API for P1028 like Boost.Outcome does.


>
> I guess the main problem would be the keywords as such, but maybe the
> __throw/__except that is already used (and thereby reserved) in MSVC can be
> used at least.
>
>
Those keywords will always implement type based C++ exception handling. You
must remember that those are not going anywhere in future C++. We'll have
two exception throwing mechanisms, value based and type based. This is
unavoidable if you wish to preserve backwards binary compatibility. I also
suspect that std::uncaught_exceptions() and possibly std::exception_ptr is
unimplementable in deterministic exceptions, so code relying on them would
break if we simply switched all exceptions to the new mechanism.

(Just to be clear, I think a compiler flag should be available which turns
on all-deterministic exceptions, with legacy exceptions emulated, but with
some functions like the above no longer compiling in some circumstances.
But I don't think it should be default)

Niall

--
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/7e8f93d6-7dd8-422f-a13f-b63b43d772ec%40isocpp.org.

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

<div dir=3D"ltr">On Monday, July 23, 2018 at 11:19:28 PM UTC+1, Bengt Gusta=
fsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">W=
ould it be unthinkable for C to implement this limited form of throw/catch =
system in full? After all almost all C compilers are also C++ compilers so =
the implementation job is probably negative (you don&#39;t have to differen=
tiate between languages in the compiler code).</div></blockquote><div><br><=
/div><div>The next draft of my D1095 proposal is a one-to-one mapping into =
C of P0709 deterministic exceptions + P1028 std::error. The mechanism I thi=
nk has consensus on WG14. The choice of standard error object (std::error) =
is disliked by a significant minority in C because you must fall back onto =
either a library or macro based API to construct and inspect such objects.<=
/div><div><br></div><div>Now, me personally, I find that acceptable, though=
 obviously laborious to work with. Some on WG14 want the compiler to hide m=
ore boilerplate. Hence the counterproposal.</div><div><br></div><div>The ne=
xt draft of D1095 I think won&#39;t mention any standard error object. That=
 can be another paper for WG14, and we in C++ can simply provide a C macro =
API for P1028 like Boost.Outcome does.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>I guess=
 the main problem would be the keywords as such, but maybe the __throw/__ex=
cept that is already used (and thereby reserved) in MSVC can be used at lea=
st.=C2=A0</div><div><br></div></div></blockquote><div><br></div><div>Those =
keywords will always implement type based C++ exception handling. You must =
remember that those are not going anywhere in future C++. We&#39;ll have tw=
o exception throwing mechanisms, value based and type based. This is unavoi=
dable if you wish to preserve backwards binary compatibility. I also suspec=
t that std::uncaught_exceptions() and possibly std::exception_ptr is unimpl=
ementable in deterministic exceptions, so code relying on them would break =
if we simply switched all exceptions to the new mechanism.</div><div><br></=
div><div>(Just to be clear, I think a compiler flag should be available whi=
ch turns on all-deterministic exceptions, with legacy exceptions emulated, =
but with some functions like the above no longer compiling in some circumst=
ances. But I don&#39;t think it should be default)</div><div><br></div><div=
>Niall</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/7e8f93d6-7dd8-422f-a13f-b63b43d772ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7e8f93d6-7dd8-422f-a13f-b63b43d772ec=
%40isocpp.org</a>.<br />

------=_Part_8819_211700596.1532420424347--

------=_Part_8818_1047639448.1532420424347--

.

------=_Part_1430_545821883.1532420527539
Content-Type: multipart/alternative;
 boundary="----=_Part_1431_606919540.1532420527539"

------=_Part_1431_606919540.1532420527539
Content-Type: text/plain; charset="UTF-8"


>
>
> I like the idea of recycling the function name to set the return value. Is
> that original in the paper or has the idea been expressed before?
>
> It's the OP's idea.

I personally find it confusing. Function names are pointers to the
function's implementation. Accessing it like a struct makes one assume such
storage is similarly static.

Niall

--
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/5e1086ff-802e-4e45-bd6c-077a93287b08%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>I like the idea of recycling the function name to s=
et the return value. Is that original in the paper or has the idea been exp=
ressed before?</div><div><br></div></div></blockquote><div>It&#39;s the OP&=
#39;s idea.</div><div><br></div><div>I personally find it confusing. Functi=
on names are pointers to the function&#39;s implementation. Accessing it li=
ke a struct makes one assume such storage is similarly static.</div><div><b=
r></div><div>Niall</div><div><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/5e1086ff-802e-4e45-bd6c-077a93287b08%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e1086ff-802e-4e45-bd6c-077a93287b08=
%40isocpp.org</a>.<br />

------=_Part_1431_606919540.1532420527539--

------=_Part_1430_545821883.1532420527539--

.

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

If we are to use the function's name, how do we deal with unutterable
functions, like lambdas, or methods? You can dismiss it as "right, C
doesn't have those", but they might in the future. I don't think it's a
good idea at all.

I also don't like that if I rename the function, I now have to change its
body. That makes very little sense to me. A rose by any other name *should*
smell as sweet.

Ga=C5=A1per

On Tue, Jul 24, 2018 at 9:22 AM, Niall Douglas <nialldouglas14@gmail.com>
wrote:

>
>> I like the idea of recycling the function name to set the return value.
>> Is that original in the paper or has the idea been expressed before?
>>
>> It's the OP's idea.
>
> I personally find it confusing. Function names are pointers to the
> function's implementation. Accessing it like a struct makes one assume su=
ch
> storage is similarly static.
>
> Niall
>
> --
> 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/5e1086ff-802e-4e45-
> bd6c-077a93287b08%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5e1086ff-80=
2e-4e45-bd6c-077a93287b08%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAANG%3DkWaY76_oC2xPbkj68sa0hMP0eKc7CDRbJt20oLJT=
bHu3g%40mail.gmail.com.

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

<div dir=3D"ltr">If we are to use the function&#39;s name, how do we deal w=
ith unutterable functions, like lambdas, or methods? You can dismiss it as =
&quot;right, C doesn&#39;t have those&quot;, but they might in the future. =
I don&#39;t think it&#39;s a good idea at all.<div><br></div><div>I also do=
n&#39;t like that if I rename the function, I now have to change its body. =
That makes very little sense to me. A rose by any other name *should* smell=
 as sweet.<br><div><br></div><div>Ga=C5=A1per</div></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 24, 2018 at 9:2=
2 AM, Niall Douglas <span dir=3D"ltr">&lt;<a href=3D"mailto:nialldouglas14@=
gmail.com" target=3D"_blank">nialldouglas14@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><block=
quote 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><br></div><div>I li=
ke the idea of recycling the function name to set the return value. Is that=
 original in the paper or has the idea been expressed before?</div><div><br=
></div></div></blockquote></span><div>It&#39;s the OP&#39;s idea.</div><div=
><br></div><div>I personally find it confusing. Function names are pointers=
 to the function&#39;s implementation. Accessing it like a struct makes one=
 assume such storage is similarly static.</div><div><br></div><div>Niall</d=
iv><div><br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<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/5e1086ff-802e-4e45-bd6c-077a93287b08%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5e10=
86ff-802e-4e45-<wbr>bd6c-077a93287b08%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWaY76_oC2xPbkj68sa0hMP0eKc7C=
DRbJt20oLJTbHu3g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWaY76_=
oC2xPbkj68sa0hMP0eKc7CDRbJt20oLJTbHu3g%40mail.gmail.com</a>.<br />

--000000000000716dbc0571ba81af--

.

On 24/07/18 10:25, Ga=C5=A1per A=C5=BEman wrote:
> If we are to use the function's name, how do we deal with unutterable
> functions, like lambdas, or methods? You can dismiss it as "right, C
> doesn't have those", but they might in the future. I don't think it's a
> good idea at all.
>=20
> I also don't like that if I rename the function, I now have to change
> its body. That makes very little sense to me. A rose by any other name
> *should* smell as sweet.
>=20

Having programmed in Pascal, where you use the function's name as the
return value pseudo-variable, I agree with that - it is a pain.

It may also be a challenge for recursive functions, and it will
certainly be a problem if you want to use the function more than once
before checking for errors:

 x =3D foo(y) + foo(z);
 if (foo.error) ...  // Which foo call?

I appreciate the desire for cheap and standardised error handling, but
this syntax is not going to work.



--=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/pj6q6g%24ep3%241%40blaine.gmane.org.

.

On 23/07/18 10:11, Niall Douglas wrote:
>     Overall, do we really need this 'expected' kind of type to be quite
>     so constrained and magic, to require an even address etc. etc.
>     In other words, if the type was actually something that was
>     specified as a 'normal' C/C++ struct without any of those gymnastics
>     and data packing or require some carry register etc., would the code
>     be that dramatically worse that we should require such magic or
>     constraints than a regular type without all the magic and alignment
>     requirements?
>
> Not speaking for the above proposal, but in general, it is currently
> believed that using something like the CPU carry bit ought to be zero
> overhead on most CPUs, whereas a discriminant stored in the layout would
> not be zero overhead on more CPUs.

For some cpus, there are cheap flags like this.  (Some cpus even have
"return with carry flag set" and "return with carry flag clear"
instructions that are tailor-made for such usage.)  On many bigger cpus,
however, working with flags can cause stalls in the processor pipelines
- the flag becomes a bottleneck dependency.  It is precisely for that
reason that RISC-V and some other newer designs have no flags.

>
> The situation of RISC-V, which has no status register, is a particular
> unknown. Our current best guess is that either we keep the discriminant
> in the structure, or we fiddle with the return address e.g. offset it by
> four. There are no good options on that architecture.
>
> Niall
>


--
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/pj6qkr%24elo%241%40blaine.gmane.org.

.

------=_Part_8798_1103664545.1532428681828
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The pipeline bubbles you refer to only occur when testing more than one CPU=
 flag at a time. One of the main reasons for choosing the carry bit as retu=
rn discriminant is because there are instructions for testing just the carr=
y bit alone on all such architectures. Thus such partial flags stalls will =
never occur in this specific use case.

Niall

--=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/4e6835ac-6975-4c89-81c4-fc038d004cb7%40isocpp.or=
g.

------=_Part_8798_1103664545.1532428681828--

.

On 24/07/18 12:38, Niall Douglas wrote:
> The pipeline bubbles you refer to only occur when testing more than
> one CPU flag at a time. One of the main reasons for choosing the
> carry bit as return discriminant is because there are instructions
> for testing just the carry bit alone on all such architectures. Thus
> such partial flags stalls will never occur in this specific use
> case.
>

I am reluctant to be so confident about the effects here - I really
don't think you can generalise and say these stalls will never occur.  I
think it will depend a lot on the cpu ISA, the details of its
implementation (scheduling, out-of-order execution, register renaming,
pipelining, speculative execution, etc.), and the type of code you are
dealing with.  On many cpus, there are quite a lot of instructions that
use or affect the carry flag (or any other flags) - these pose a
challenge for scheduling.  They also pose a challenge for the compiler,
if it would want to use such instructions between the call to "foo" and
the check for "foo.error".

It may be fair to say that using the carry flag here would not cause
much in the way of stalling or delays - but I would not say "never"
without a lot more thorough analysis with a range of different processors.

On a related point, many compilers do not track the state of flags
across instruction pattern boundaries - /any/ use of a carry flag like
this would involve significant engineering effort.


--
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/pj78nm%24loi%241%40blaine.gmane.org.

.

------=_Part_9190_24718504.1532443239122
Content-Type: multipart/alternative;
 boundary="----=_Part_9191_628476589.1532443239122"

------=_Part_9191_628476589.1532443239122
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tuesday, July 24, 2018 at 5:08:45 AM UTC-4, David Brown wrote:
>
> On 24/07/18 10:25, Ga=C5=A1per A=C5=BEman wrote:=20
> > If we are to use the function's name, how do we deal with unutterable=
=20
> > functions, like lambdas, or methods? You can dismiss it as "right, C=20
> > doesn't have those", but they might in the future. I don't think it's a=
=20
> > good idea at all.=20
> >=20
> > I also don't like that if I rename the function, I now have to change=
=20
> > its body. That makes very little sense to me. A rose by any other name=
=20
> > *should* smell as sweet.=20
> >=20
>
> Having programmed in Pascal, where you use the function's name as the=20
> return value pseudo-variable, I agree with that - it is a pain.=20
>
> It may also be a challenge for recursive functions, and it will=20
> certainly be a problem if you want to use the function more than once=20
> before checking for errors:=20
>
>         x =3D foo(y) + foo(z);=20
>         if (foo.error) ...  // Which foo call?=20
>
> I appreciate the desire for cheap and standardised error handling, but=20
> this syntax is not going to work.
>

I think the design of this proposal is intended to be much more=20
conservative than Niall's. In particular, it is *purely* focused on the=20
transmission of error codes via this invisible fail state. That is, it's a=
=20
mere optimization of what you would otherwise have written in an=20
error-code-based world.

If your hypothetical `foo` function had returned an error code, then=20
there's no way for that `foo(y) + foo(z)` code to work. Therefore,=20
error-code-based functions wouldn't have been written that way, so=20
functions under the new paradigm also wouldn't be written this way.

Now personally, I think that's basically throwing away a golden opportunity=
=20
to more reasonably handle errors in C. But that is the basic thinking=20
behind the proposal; that kind of compatibility is exactly what it's going=
=20
for. The idea is that this is merely about how you transmit the information=
=20
you would have, rather than how you process it.

--=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/6a349048-5ffe-4d46-9b6a-d3246e2d505b%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 5:08:45 AM UTC-4, Dav=
id Brown wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24/07/18 10:=
25, Ga=C5=A1per A=C5=BEman wrote:
<br>&gt; If we are to use the function&#39;s name, how do we deal with unut=
terable
<br>&gt; functions, like lambdas, or methods? You can dismiss it as &quot;r=
ight, C
<br>&gt; doesn&#39;t have those&quot;, but they might in the future. I don&=
#39;t think it&#39;s a
<br>&gt; good idea at all.
<br>&gt;=20
<br>&gt; I also don&#39;t like that if I rename the function, I now have to=
 change
<br>&gt; its body. That makes very little sense to me. A rose by any other =
name
<br>&gt; *should* smell as sweet.
<br>&gt;=20
<br>
<br>Having programmed in Pascal, where you use the function&#39;s name as t=
he
<br>return value pseudo-variable, I agree with that - it is a pain.
<br>
<br>It may also be a challenge for recursive functions, and it will
<br>certainly be a problem if you want to use the function more than once
<br>before checking for errors:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0x =3D foo(y) + foo(z);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (foo.error) ... =C2=
=A0// Which foo call?
<br>
<br>I appreciate the desire for cheap and standardised error handling, but
<br>this syntax is not going to work.<br></blockquote><div><br></div><div>I=
 think the design of this proposal is intended to be much more conservative=
 than Niall&#39;s. In particular, it is <i>purely</i> focused on the transm=
ission of error codes via this invisible fail state. That is, it&#39;s a me=
re optimization of what you would otherwise have written in an error-code-b=
ased world.</div><div><br></div><div>If your hypothetical `foo` function ha=
d returned an error code, then there&#39;s no way for that `foo(y) + foo(z)=
` code to work. Therefore, error-code-based functions wouldn&#39;t have bee=
n written that way, so functions under the new paradigm also wouldn&#39;t b=
e written this way.</div><div><br></div><div>Now personally, I think that&#=
39;s basically throwing away a golden opportunity to more reasonably handle=
 errors in C. But that is the basic thinking behind the proposal; that kind=
 of compatibility is exactly what it&#39;s going for. The idea is that this=
 is merely about how you transmit the information you would have, rather th=
an how you process it.<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/6a349048-5ffe-4d46-9b6a-d3246e2d505b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a349048-5ffe-4d46-9b6a-d3246e2d505b=
%40isocpp.org</a>.<br />

------=_Part_9191_628476589.1532443239122--

------=_Part_9190_24718504.1532443239122--

.

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

On Tue, 24 Jul 2018, 05:43 Nicol Bolas, <jmckesson@gmail.com> wrote:

> On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinstall wrote:
>>
>> Error handling via an effective static state isn't thread safe. Marking
>> the flag as volatile and telling users to check for errors immediately
>> after the function call goes some way to help, I guess, but it's not
>> sufficient to guarantee that errors won't crop up in the wrong thread (or
>> do I have some reading to do?)
>>
>
> I think this is a misunderstanding of what the paper is saying. It is not
> talking about "static state" (even though it appears to). The
> `funcName.failed` bit is not intended to be a static property of
> `funcName`; it's closer to an invisible stack variable, which you access by
> using the function's name. The compiler turns "funcName.failed" into the
> specific stack location or register or whatever that maps to that data.
>

Well, that leaves me with egg on my face. The proposal certainly makes more
sense given what you've said. On a similar note, then, what would this do
to our constexpr?

--
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/CAC%2B0CCPJLYt4frAh%2BxcSyEpA9qiEdy%3DO98utgxz2Or5mwMoabw%40mail.gmail.com.

--0000000000004e8afe0571c099fd
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 Tue, =
24 Jul 2018, 05:43 Nicol Bolas, &lt;<a href=3D"mailto:jmckesson@gmail.com">=
jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinst=
all wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">Error handling via an effective s=
tatic state isn&#39;t thread safe. Marking the flag as volatile and telling=
 users to check for errors immediately after the function call goes some wa=
y to help, I guess, but it&#39;s not sufficient to guarantee that errors wo=
n&#39;t crop up in the wrong thread (or do I have some reading to do?)</div=
></div></div></div></blockquote><div><br></div><div>I think this is a misun=
derstanding of what the paper is saying. It is not talking about &quot;stat=
ic state&quot; (even though it appears to). The `funcName.failed` bit is no=
t intended to be a static property of `funcName`; it&#39;s closer to an inv=
isible stack variable, which you access by using the function&#39;s name. T=
he compiler turns &quot;funcName.failed&quot; into the specific stack locat=
ion or register or whatever that maps to that data.<br></div></div></blockq=
uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Well, that l=
eaves me with egg on my face. The proposal certainly makes more sense given=
 what you&#39;ve said. On a similar note, then, what would this do to our c=
onstexpr?</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/CAC%2B0CCPJLYt4frAh%2BxcSyEpA9qiEdy%3=
DO98utgxz2Or5mwMoabw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJ=
LYt4frAh%2BxcSyEpA9qiEdy%3DO98utgxz2Or5mwMoabw%40mail.gmail.com</a>.<br />

--0000000000004e8afe0571c099fd--

.

------=_Part_9239_1139466791.1532447903690
Content-Type: multipart/alternative;
 boundary="----=_Part_9240_2042727669.1532447903691"

------=_Part_9240_2042727669.1532447903691
Content-Type: text/plain; charset="UTF-8"



On Tuesday, July 24, 2018 at 11:41:45 AM UTC-4, Jake Arkinstall wrote:
>
> On Tue, 24 Jul 2018, 05:43 Nicol Bolas, <jmck...@gmail.com <javascript:>>
> wrote:
>
>> On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinstall wrote:
>>>
>>> Error handling via an effective static state isn't thread safe. Marking
>>> the flag as volatile and telling users to check for errors immediately
>>> after the function call goes some way to help, I guess, but it's not
>>> sufficient to guarantee that errors won't crop up in the wrong thread (or
>>> do I have some reading to do?)
>>>
>>
>> I think this is a misunderstanding of what the paper is saying. It is not
>> talking about "static state" (even though it appears to). The
>> `funcName.failed` bit is not intended to be a static property of
>> `funcName`; it's closer to an invisible stack variable, which you access by
>> using the function's name. The compiler turns "funcName.failed" into the
>> specific stack location or register or whatever that maps to that data.
>>
>
> Well, that leaves me with egg on my face. The proposal certainly makes
> more sense given what you've said. On a similar note, then, what would this
> do to our constexpr?
>

It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of its
biggest flaws is that it doesn't allow for inter-operation with C++ static
exceptions at all, despite being in part based on the same principle.

--
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/8866881c-ef1d-4c37-9242-5b1d3327c288%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 11:41:45 AM UTC-4, Ja=
ke Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 24 Jul 2=
018, 05:43 Nicol Bolas, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"I4dIPue7DAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">On Monday, July 23, 2018 at 9:55:11 P=
M UTC-4, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">Error handli=
ng via an effective static state isn&#39;t thread safe. Marking the flag as=
 volatile and telling users to check for errors immediately after the funct=
ion call goes some way to help, I guess, but it&#39;s not sufficient to gua=
rantee that errors won&#39;t crop up in the wrong thread (or do I have some=
 reading to do?)</div></div></div></div></blockquote><div><br></div><div>I =
think this is a misunderstanding of what the paper is saying. It is not tal=
king about &quot;static state&quot; (even though it appears to). The `funcN=
ame.failed` bit is not intended to be a static property of `funcName`; it&#=
39;s closer to an invisible stack variable, which you access by using the f=
unction&#39;s name. The compiler turns &quot;funcName.failed&quot; into the=
 specific stack location or register or whatever that maps to that data.<br=
></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Well, that leaves me with egg on my face. The proposal certainly =
makes more sense given what you&#39;ve said. On a similar note, then, what =
would this do to our constexpr?</div></div></blockquote><div><br></div><div=
>It&#39;s a C proposal; it doesn&#39;t interact with `constexpr`. Indeed, o=
ne of its biggest flaws is that it doesn&#39;t allow for inter-operation wi=
th C++ static exceptions at all, despite being in part based on the same pr=
inciple.<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/8866881c-ef1d-4c37-9242-5b1d3327c288%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8866881c-ef1d-4c37-9242-5b1d3327c288=
%40isocpp.org</a>.<br />

------=_Part_9240_2042727669.1532447903691--

------=_Part_9239_1139466791.1532447903690--

.

------=_Part_1168_624415036.1532454741343
Content-Type: multipart/alternative;
 boundary="----=_Part_1169_837385565.1532454741343"

------=_Part_1169_837385565.1532454741343
Content-Type: text/plain; charset="UTF-8"


>
> Well, that leaves me with egg on my face. The proposal certainly makes
>> more sense given what you've said. On a similar note, then, what would this
>> do to our constexpr?
>>
>
> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of
> its biggest flaws is that it doesn't allow for inter-operation with C++
> static exceptions at all, despite being in part based on the same principle.
>

My _Fails() proposal does however work in constexpr, as deterministic
exceptions is ordinary control flow.

I appreciate that will be a controversial statement. However I've been
working in this area closely for a long time now, and I am afraid that is
ordinary control flow. This says nothing about whether one ought to use it
as control flow, just that it is control flow in a way unlike type based
exception throws.

Besides, I intend for P1031 Low level file i/o to work in constexpr as soon
as I can persuade the committee, and being that it fails via deterministic
exceptions, that would also need to work in constexpr.

Niall

--
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/e8190580-cda9-4899-ba2b-9a0fd5d48073%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"a=
uto">Well, that leaves me with egg on my face. The proposal certainly makes=
 more sense given what you&#39;ve said. On a similar note, then, what would=
 this do to our constexpr?</div></div></blockquote><div><br></div><div>It&#=
39;s a C proposal; it doesn&#39;t interact with `constexpr`. Indeed, one of=
 its biggest flaws is that it doesn&#39;t allow for inter-operation with C+=
+ static exceptions at all, despite being in part based on the same princip=
le.<br></div></div></blockquote><div><br></div><div>My _Fails() proposal do=
es however work in constexpr, as deterministic exceptions is ordinary contr=
ol flow.</div><div><br></div><div>I appreciate that will be a controversial=
 statement. However I&#39;ve been working in this area closely for a long t=
ime now, and I am afraid that is ordinary control flow. This says nothing a=
bout whether one ought to use it as control flow, just that it is control f=
low in a way unlike type based exception throws.</div><div><br></div><div>B=
esides, I intend for P1031 Low level file i/o to work in constexpr as soon =
as I can persuade the committee, and being that it fails via deterministic =
exceptions, that would also need to work in constexpr.</div><div><br></div>=
<div>Niall=C2=A0</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/e8190580-cda9-4899-ba2b-9a0fd5d48073%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8190580-cda9-4899-ba2b-9a0fd5d48073=
%40isocpp.org</a>.<br />

------=_Part_1169_837385565.1532454741343--

------=_Part_1168_624415036.1532454741343--

.

------=_Part_9408_1967338886.1532457361992
Content-Type: multipart/alternative;
 boundary="----=_Part_9409_308190184.1532457361992"

------=_Part_9409_308190184.1532457361992
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 24, 2018 at 1:52:21 PM UTC-4, Niall Douglas wrote:
>
> Well, that leaves me with egg on my face. The proposal certainly makes
>>> more sense given what you've said. On a similar note, then, what would this
>>> do to our constexpr?
>>>
>>
>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of
>> its biggest flaws is that it doesn't allow for inter-operation with C++
>> static exceptions at all, despite being in part based on the same principle.
>>
>
> My _Fails() proposal does however work in constexpr,
>

`_Fails()` is not valid C++, and `constexpr` is not valid C. How can they
work with one another? Unless you're proposing to add `_Fails()` to C++,
which I think would be a rather hard sell.

--
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/363df3db-b747-449f-b95d-81d15b6c3842%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 1:52:21 PM UTC-4, Niall Dougl=
as 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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Well, that leaves me =
with egg on my face. The proposal certainly makes more sense given what you=
&#39;ve said. On a similar note, then, what would this do to our constexpr?=
</div></div></blockquote><div><br></div><div>It&#39;s a C proposal; it does=
n&#39;t interact with `constexpr`. Indeed, one of its biggest flaws is that=
 it doesn&#39;t allow for inter-operation with C++ static exceptions at all=
, despite being in part based on the same principle.<br></div></div></block=
quote><div><br></div><div>My _Fails() proposal does however work in constex=
pr,</div></div></blockquote><div><br></div><div>`_Fails()` is not valid C++=
, and `constexpr` is not valid C. How can they work with one another? Unles=
s you&#39;re proposing to add `_Fails()` to C++, which I think would be a r=
ather hard sell.</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/363df3db-b747-449f-b95d-81d15b6c3842%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/363df3db-b747-449f-b95d-81d15b6c3842=
%40isocpp.org</a>.<br />

------=_Part_9409_308190184.1532457361992--

------=_Part_9408_1967338886.1532457361992--

.

On Tuesday, 24 July 2018 06:16:42 PDT David Brown wrote:
> I am reluctant to be so confident about the effects here - I really
> don't think you can generalise and say these stalls will never occur.  I
> think it will depend a lot on the cpu ISA, the details of its
> implementation (scheduling, out-of-order execution, register renaming,
> pipelining, speculative execution, etc.), and the type of code you are
> dealing with.  On many cpus, there are quite a lot of instructions that
> use or affect the carry flag (or any other flags) - these pose a
> challenge for scheduling.  They also pose a challenge for the compiler,
> if it would want to use such instructions between the call to "foo" and
> the check for "foo.error".
>
> It may be fair to say that using the carry flag here would not cause
> much in the way of stalling or delays - but I would not say "never"
> without a lot more thorough analysis with a range of different processors.

That's entirely QoI. If the compiler that targets this particular system where
setting or testing a particular flag is slow, the compiler can simply choose
another way of returning the information.

Let's take another example of a CPU without flags: IA-64. Instead of having
flags, the CPU has 1-bit predicate registers, which are set or unset depending
on the comparison operation that was performed. So IA-64 could then use one of
the scratch predicate registers as an extra return value. There are 10 of
them.

Another example is MIPS: it has no carry flag and no predicate register. In
that case, it would need to use an extra register (currently used for scratch)
with either a zero or non-zero value, which would allow the caller to use the
BNEZ instruction to jump to the failure path. Fortunately, MIPS has plenty of
registers, so it can do that.

This is up to the ABI documents for each platform to determine.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1957969.uOyN2Jk7ag%40tjmaciei-mobl1.

.

------=_Part_9352_1102128798.1532472955786
Content-Type: multipart/alternative;
 boundary="----=_Part_9353_752563752.1532472955787"

------=_Part_9353_752563752.1532472955787
Content-Type: text/plain; charset="UTF-8"



On Tuesday, July 24, 2018 at 8:36:02 PM UTC+2, Nicol Bolas wrote:
>
> On Tuesday, July 24, 2018 at 1:52:21 PM UTC-4, Niall Douglas wrote:
>>
>> Well, that leaves me with egg on my face. The proposal certainly makes
>>>> more sense given what you've said. On a similar note, then, what would this
>>>> do to our constexpr?
>>>>
>>>
>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of
>>> its biggest flaws is that it doesn't allow for inter-operation with C++
>>> static exceptions at all, despite being in part based on the same principle.
>>>
>>
>> My _Fails() proposal does however work in constexpr,
>>
>
> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can they
> work with one another? Unless you're proposing to add `_Fails()` to C++,
> which I think would be a rather hard sell.
>

Why not? C++ inhered multiple things from C, this could be another one. If
Niall define this functionality in compatible way for C++ then we need only
add one paragraph that "behavior of C exceptions from C2x work same way in
C++2y" and another one how glue both. I would even go further and build C++
exception on top of C as syntax sugar but this probably is not direction
that Niall is going.

--
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/76fcc1f3-6d58-409c-824e-47af1c49d3ec%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 8:36:02 PM UTC+2, Nic=
ol Bolas 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=
">On Tuesday, July 24, 2018 at 1:52:21 PM UTC-4, Niall Douglas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"auto"><div dir=3D"auto">Well, that leaves me with egg on my face.=
 The proposal certainly makes more sense given what you&#39;ve said. On a s=
imilar note, then, what would this do to our constexpr?</div></div></blockq=
uote><div><br></div><div>It&#39;s a C proposal; it doesn&#39;t interact wit=
h `constexpr`. Indeed, one of its biggest flaws is that it doesn&#39;t allo=
w for inter-operation with C++ static exceptions at all, despite being in p=
art based on the same principle.<br></div></div></blockquote><div><br></div=
><div>My _Fails() proposal does however work in constexpr,</div></div></blo=
ckquote><div><br></div><div>`_Fails()` is not valid C++, and `constexpr` is=
 not valid C. How can they work with one another? Unless you&#39;re proposi=
ng to add `_Fails()` to C++, which I think would be a rather hard sell.</di=
v></div></blockquote><div><br></div><div>Why not? C++ inhered multiple thin=
gs from C, this could be another one. If Niall define this functionality in=
 compatible way for C++ then we need only add one paragraph that &quot;beha=
vior of C exceptions from C2x work same way in C++2y&quot; and another one =
how glue both. I would even go further and build C++ exception on top of C =
as syntax sugar but this probably is not direction that Niall is going.<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/76fcc1f3-6d58-409c-824e-47af1c49d3ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76fcc1f3-6d58-409c-824e-47af1c49d3ec=
%40isocpp.org</a>.<br />

------=_Part_9353_752563752.1532472955787--

------=_Part_9352_1102128798.1532472955786--

.

------=_Part_9366_1083856855.1532481884106
Content-Type: multipart/alternative;
 boundary="----=_Part_9367_1957304967.1532481884106"

------=_Part_9367_1957304967.1532481884106
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 24, 2018 at 6:55:55 PM UTC-4, Marcin Jaczewski wrote:
>
> On Tuesday, July 24, 2018 at 8:36:02 PM UTC+2, Nicol Bolas wrote:
>>
>> On Tuesday, July 24, 2018 at 1:52:21 PM UTC-4, Niall Douglas wrote:
>>>
>>> Well, that leaves me with egg on my face. The proposal certainly makes
>>>>> more sense given what you've said. On a similar note, then, what would this
>>>>> do to our constexpr?
>>>>>
>>>>
>>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of
>>>> its biggest flaws is that it doesn't allow for inter-operation with C++
>>>> static exceptions at all, despite being in part based on the same principle.
>>>>
>>>
>>> My _Fails() proposal does however work in constexpr,
>>>
>>
>> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can they
>> work with one another? Unless you're proposing to add `_Fails()` to C++,
>> which I think would be a rather hard sell.
>>
>
> Why not?
>

Because P0709 is superior in pretty much every way. From the fixed, simple,
and highly flexible error type to making error handling control flow
distinct from regular code flow, and with plenty of points of extension
besides (such as my suggestion for allowing `try` to unpack ValueOrError
types into exceptions).

I just don't see any reason to use the C mechanism. Doubly so because it is
only compatible if you choose to make it compatible (by using `_Fails` with
the `std::error`-equivalent object). So why have an option that people
shouldn't be using?

C++ inhered multiple things from C, this could be another one.
>

And C++ has *not* inherited multiple other things from C; this could be
another one. The `_Fails()` mechanism is a perfectly fine C-ism. But it is
not a C++ solution to the problem, and we should not encourage it by
canonizing it for our language.

They may share the underlying ABI, similar substructure for communicating
between functions. And there could even be some declaration in the C++
standard which says that an `extern "C"` function declared with `throws`
shall be equivalent in some way to a C function with `_Fails(cxx_error)` or
whatever.

But having `_Fails()` be legal C++? No. The point of giving C `_Fails()`
from our perspective is so that C++ static exceptions can at least pass
*through* C APIs.

If Niall define this functionality in compatible way for C++ then we need
> only add one paragraph that "behavior of C exceptions from C2x work same
> way in C++2y" and another one how glue both. I would even go further and
> build C++ exception on top of C as syntax sugar but this probably is not
> direction that Niall is going.
>

--
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/a32c119b-f891-4bf1-b130-e1815954b86e%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 6:55:55 PM UTC-4, Marcin Jacz=
ewski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Tuesday, July 24, 2018 at 8:36:02 PM UTC+2, Nicol Bolas 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">On Tuesday, July 24, 2018 at =
1:52:21 PM UTC-4, Niall Douglas wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"aut=
o">Well, that leaves me with egg on my face. The proposal certainly makes m=
ore sense given what you&#39;ve said. On a similar note, then, what would t=
his do to our constexpr?</div></div></blockquote><div><br></div><div>It&#39=
;s a C proposal; it doesn&#39;t interact with `constexpr`. Indeed, one of i=
ts biggest flaws is that it doesn&#39;t allow for inter-operation with C++ =
static exceptions at all, despite being in part based on the same principle=
..<br></div></div></blockquote><div><br></div><div>My _Fails() proposal does=
 however work in constexpr,</div></div></blockquote><div><br></div><div>`_F=
ails()` is not valid C++, and `constexpr` is not valid C. How can they work=
 with one another? Unless you&#39;re proposing to add `_Fails()` to C++, wh=
ich I think would be a rather hard sell.</div></div></blockquote><div><br><=
/div><div>Why not?</div></div></blockquote><div><br></div><div>Because P070=
9 is superior in pretty much every way. From the fixed, simple, and highly =
flexible error type to making error handling control flow distinct from reg=
ular code flow, and with plenty of points of extension besides (such as my =
suggestion for allowing `try` to unpack ValueOrError types into exceptions)=
..</div><div><br></div><div>I just don&#39;t see any reason to use the C mec=
hanism. Doubly so because it is only compatible if you choose to make it co=
mpatible (by using `_Fails` with the `std::error`-equivalent object). So wh=
y have an option that people shouldn&#39;t be using?<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>C++ in=
hered multiple things from C, this could be another one.</div></div></block=
quote><div><br></div><div>And C++ has <i>not</i> inherited multiple other t=
hings from C; this could be another one. The `_Fails()` mechanism is a perf=
ectly fine C-ism. But it is not a C++ solution to the problem, and we shoul=
d not encourage it by canonizing it for our language.</div><div><br></div><=
div>They may share the underlying ABI, similar substructure for communicati=
ng between functions. And there could even be some declaration in the C++ s=
tandard which says that an `extern &quot;C&quot;` function declared with `t=
hrows` shall be equivalent in some way to a C function with `_Fails(cxx_err=
or)` or whatever.</div><div><br></div><div>But having `_Fails()` be legal C=
++? No. The point of giving C `_Fails()` from our perspective is so that C+=
+ static exceptions can at least pass <i>through</i> C APIs.<br></div><div>=
<br></div><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"><di=
v>If Niall define this functionality in compatible way for C++ then we need=
 only add one paragraph that &quot;behavior of C exceptions from C2x work s=
ame way in C++2y&quot; and another one how glue both. I would even go furth=
er and build C++ exception on top of C as syntax sugar but this probably is=
 not direction that Niall is going.<br></div></div></blockquote></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/a32c119b-f891-4bf1-b130-e1815954b86e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a32c119b-f891-4bf1-b130-e1815954b86e=
%40isocpp.org</a>.<br />

------=_Part_9367_1957304967.1532481884106--

------=_Part_9366_1083856855.1532481884106--

.

On 24/07/18 21:27, Thiago Macieira wrote:
> On Tuesday, 24 July 2018 06:16:42 PDT David Brown wrote:
>> I am reluctant to be so confident about the effects here - I really
>> don't think you can generalise and say these stalls will never occur.  I
>> think it will depend a lot on the cpu ISA, the details of its
>> implementation (scheduling, out-of-order execution, register renaming,
>> pipelining, speculative execution, etc.), and the type of code you are
>> dealing with.  On many cpus, there are quite a lot of instructions that
>> use or affect the carry flag (or any other flags) - these pose a
>> challenge for scheduling.  They also pose a challenge for the compiler,
>> if it would want to use such instructions between the call to "foo" and
>> the check for "foo.error".
>>
>> It may be fair to say that using the carry flag here would not cause
>> much in the way of stalling or delays - but I would not say "never"
>> without a lot more thorough analysis with a range of different processors.
>
> That's entirely QoI. If the compiler that targets this particular system where
> setting or testing a particular flag is slow, the compiler can simply choose
> another way of returning the information.

Exactly.  Well, /almost/ exactly - it could be a problem for ISA's where
the cost of using a carry flag is cheap (cheaper than using a standard
bool in a register) on some implementations and costly in other
implementations, since they need to share the same standardised ABI.  (I
am thinking primarily of the x86 world here, where there is a huge
variation in the implementation details.)

This would be easier if it really was the compiler that could make the
choices here - but the proposal is for an ABI change, not just an
internal compiler choice.

>
> Let's take another example of a CPU without flags: IA-64. Instead of having
> flags, the CPU has 1-bit predicate registers, which are set or unset depending
> on the comparison operation that was performed. So IA-64 could then use one of
> the scratch predicate registers as an extra return value. There are 10 of
> them.
>
> Another example is MIPS: it has no carry flag and no predicate register. In
> that case, it would need to use an extra register (currently used for scratch)
> with either a zero or non-zero value, which would allow the caller to use the
> BNEZ instruction to jump to the failure path. Fortunately, MIPS has plenty of
> registers, so it can do that.
>
> This is up to the ABI documents for each platform to determine.
>

Indeed.

My point was merely that using a carry flag would not necessarily be
"zero overhead" even on cpus that have a carry flag.  For different
cpus, different solutions would be more efficient.

All in all, I am sceptical to the idea that using a carry flag would be
a big enough win on any platform (except, perhaps, on some small
microcontrollers) to be worth the massive complications involved.  If
the whole concept were handled using a regular C struct and union with a
bool member, then it would work already with existing tools and ABI's -
it is merely syntactic sugar in the compiler front-end, rather than a
major change throughout the chain.

(Of course, there is nothing wrong with defining an ABI to say that a
"bool" return, either in a small struct or stand-alone, is returned in a
flag or predicate register - just as the ABI defines register choices
for different sized integers and floats in returns.  Then the benefits
would be seen on all functions returning a bool, not just these proposed
exceptions.)


--
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/pj978s%24tjv%241%40blaine.gmane.org.

.

On 24/07/18 16:40, Nicol Bolas wrote:
>=20
>=20
> On Tuesday, July 24, 2018 at 5:08:45 AM UTC-4, David Brown wrote:
>=20
>     On 24/07/18 10:25, Ga=C5=A1per A=C5=BEman wrote:
>     > If we are to use the function's name, how do we deal with unutterab=
le
>     > functions, like lambdas, or methods? You can dismiss it as "right, =
C
>     > doesn't have those", but they might in the future. I don't think
>     it's a
>     > good idea at all.
>     >
>     > I also don't like that if I rename the function, I now have to chan=
ge
>     > its body. That makes very little sense to me. A rose by any other
>     name
>     > *should* smell as sweet.
>     >
>=20
>     Having programmed in Pascal, where you use the function's name as the
>     return value pseudo-variable, I agree with that - it is a pain.
>=20
>     It may also be a challenge for recursive functions, and it will
>     certainly be a problem if you want to use the function more than once
>     before checking for errors:
>=20
>             x =3D foo(y) + foo(z);
>             if (foo.error) ...  // Which foo call?
>=20
>     I appreciate the desire for cheap and standardised error handling, bu=
t
>     this syntax is not going to work.
>=20
>=20
> I think the design of this proposal is intended to be much more
> conservative than Niall's. In particular, it is /purely/ focused on the
> transmission of error codes via this invisible fail state. That is, it's
> a mere optimization of what you would otherwise have written in an
> error-code-based world.
>=20
> If your hypothetical `foo` function had returned an error code, then
> there's no way for that `foo(y) + foo(z)` code to work. Therefore,
> error-code-based functions wouldn't have been written that way, so
> functions under the new paradigm also wouldn't be written this way.

There are currently two main ways of handling errors in C++.

You can use C-style status returns.  In that case, "foo(y) + foo(z)"
does not work.  But you /know/ it does not work - it is very clear from
the way the functions are declared and used.

Or you can use exceptions.  Then "foo(y) + foo(z)" /does/ work, and it
is clear that it works.

With this proposal, it looks like "foo(y) + foo(z)" should work, but it
does not work.  And therein lies the danger.

>=20
> Now personally, I think that's basically throwing away a golden
> opportunity to more reasonably handle errors in C. But that is the basic
> thinking behind the proposal; that kind of compatibility is exactly what
> it's going for. The idea is that this is merely about how you transmit
> the information you would have, rather than how you process it.
>=20



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

.

------=_Part_9700_875305197.1532506473553
Content-Type: multipart/alternative;
 boundary="----=_Part_9701_448495247.1532506473553"

------=_Part_9701_448495247.1532506473553
Content-Type: text/plain; charset="UTF-8"


>
>
>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of
>>> its biggest flaws is that it doesn't allow for inter-operation with C++
>>> static exceptions at all, despite being in part based on the same principle.
>>>
>>
>> My _Fails() proposal does however work in constexpr,
>>
>
> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can they
> work with one another? Unless you're proposing to add `_Fails()` to C++,
> which I think would be a rather hard sell.
>

I appreciate you are probably not up to date, as I have not issued a new
draft of  D1095 which incorporates the substantial feedback I received from
WG14. And I have only very briefly summarised what will go into that draft
on std-proposals and /r/cpp/.

But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T). The only
difference is auto-propagation, so a _Fails(T) if unhandled results in a
failure to compile, whereas a throws(T) if unhandled propagates upwards.

This is what WG14 asked for. As C++ 23 would surely be incorporating C22
into itself, whatever goes into C also goes in C++. I intend to propose, in
fact, that both mechanisms work perfectly in constexpr. It would let
constexpr code choose whether failure should be handled explicitly (_Fails)
or implicitly (throws), exactly the same as in non-constexpr.

Niall

--
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/ceee4153-dde7-43a3-b43f-aaf62aa01b60%40isocpp.org.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><br></div><div>It&#39;s a C proposal; it doe=
sn&#39;t interact with `constexpr`. Indeed, one of its biggest flaws is tha=
t it doesn&#39;t allow for inter-operation with C++ static exceptions at al=
l, despite being in part based on the same principle.<br></div></div></bloc=
kquote><div><br></div><div>My _Fails() proposal does however work in conste=
xpr,</div></div></blockquote><div><br></div><div>`_Fails()` is not valid C+=
+, and `constexpr` is not valid C. How can they work with one another? Unle=
ss you&#39;re proposing to add `_Fails()` to C++, which I think would be a =
rather hard sell.</div></div></blockquote><div><br></div><div>I appreciate =
you are probably not up to date, as I have not issued a new draft of=C2=A0 =
D1095 which incorporates the substantial feedback I received from WG14. And=
 I have only very briefly summarised what will go into that draft on std-pr=
oposals and /r/cpp/.</div><div><br></div><div>But in short, C22 _Fails(T) m=
aps directly onto C++ 23 throws(T). The only difference is auto-propagation=
, so a _Fails(T) if unhandled results in a failure to compile, whereas a th=
rows(T) if unhandled propagates upwards.</div><div><br></div><div>This is w=
hat WG14 asked for. As C++ 23 would surely be incorporating C22 into itself=
, whatever goes into C also goes in C++. I intend to propose, in fact, that=
 both mechanisms work perfectly in constexpr. It would let constexpr code c=
hoose whether failure should be handled explicitly (_Fails) or implicitly (=
throws), exactly the same as in non-constexpr.</div><div><br></div><div>Nia=
ll</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/ceee4153-dde7-43a3-b43f-aaf62aa01b60%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ceee4153-dde7-43a3-b43f-aaf62aa01b60=
%40isocpp.org</a>.<br />

------=_Part_9701_448495247.1532506473553--

------=_Part_9700_875305197.1532506473553--

.

------=_Part_9646_85301419.1532507110259
Content-Type: multipart/alternative;
 boundary="----=_Part_9647_1588443923.1532507110259"

------=_Part_9647_1588443923.1532507110259
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 24, 2018 at 2:16:56 PM UTC+1, David Brown wrote:
>
> On 24/07/18 12:38, Niall Douglas wrote:
> > The pipeline bubbles you refer to only occur when testing more than
> > one CPU flag at a time. One of the main reasons for choosing the
> > carry bit as return discriminant is because there are instructions
> > for testing just the carry bit alone on all such architectures. Thus
> > such partial flags stalls will never occur in this specific use
> > case.
> >
>
> I am reluctant to be so confident about the effects here - I really
> don't think you can generalise and say these stalls will never occur.


Remember we only care about the specific case of where an extern,
non-inlined function returns. On every architecture, that would involve
causing the carry flag to be set or be cleared, executing a return from
subroutine, and in the caller doing a branch if carry set or clear.

When researching all this some years ago now, I studied x64, ARM and
AArch64, both in order and out of order variants. On those architectures -
which represent a good fraction of all CPUs likely to be in use in five
years time - I found between zero and two CPU cycle overhead, assuming all
warm cache. The out of order cores were almost always zero overhead as the
code after the return from function is speculatively executed.


>
> On a related point, many compilers do not track the state of flags
> across instruction pattern boundaries - /any/ use of a carry flag like
> this would involve significant engineering effort.
>
> Again, we only care about calls to non-inlined extern functions. In all
other cases, any use of the carry flag will be optimised out. So in fact
the proposed mechanism is purely about calling convention of extern
functions only, and should require very little work on the compiler because
for calls of extern functions, no optimisation is possible in its calling
convention anyway.

Niall

--
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/c0b3f7b6-e611-45a9-8f54-e49b7e840b6b%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 2:16:56 PM UTC+1, David Brown=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24/07/18 12:38, Nial=
l Douglas wrote:
<br>&gt; The pipeline bubbles you refer to only occur when testing more tha=
n
<br>&gt; one CPU flag at a time. One of the main reasons for choosing the
<br>&gt; carry bit as return discriminant is because there are instructions
<br>&gt; for testing just the carry bit alone on all such architectures. Th=
us
<br>&gt; such partial flags stalls will never occur in this specific use
<br>&gt; case.
<br>&gt;=20
<br>
<br>I am reluctant to be so confident about the effects here - I really
<br>don&#39;t think you can generalise and say these stalls will never occu=
r. </blockquote><div><br></div><div>Remember we only care about the specifi=
c case of where an extern, non-inlined function returns. On every architect=
ure, that would involve causing the carry flag to be set or be cleared, exe=
cuting a return from subroutine, and in the caller doing a branch if carry =
set or clear.</div><div><br></div><div>When researching all this some years=
 ago now, I studied x64, ARM and AArch64, both in order and out of order va=
riants. On those architectures - which represent a good fraction of all CPU=
s likely to be in use in five years time - I found between zero and two CPU=
 cycle overhead, assuming all warm cache. The out of order cores were almos=
t always zero overhead as the code after the return from function is specul=
atively executed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><br>On a related point, many compilers do not track the state of =
flags
<br>across instruction pattern boundaries - /any/ use of a carry flag like
<br>this would involve significant engineering effort.
<br><br></blockquote><div>Again, we only care about calls to non-inlined ex=
tern functions. In all other cases, any use of the carry flag will be optim=
ised out. So in fact the proposed mechanism is purely about calling convent=
ion of extern functions only, and should require very little work on the co=
mpiler because for calls of extern functions, no optimisation is possible i=
n its calling convention anyway.</div><div><br></div><div>Niall=C2=A0</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/c0b3f7b6-e611-45a9-8f54-e49b7e840b6b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0b3f7b6-e611-45a9-8f54-e49b7e840b6b=
%40isocpp.org</a>.<br />

------=_Part_9647_1588443923.1532507110259--

------=_Part_9646_85301419.1532507110259--

.

------=_Part_9409_346432197.1532507211862
Content-Type: multipart/alternative;
 boundary="----=_Part_9410_604003079.1532507211863"

------=_Part_9410_604003079.1532507211863
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 24, 2018 at 2:16:56 PM UTC+1, David Brown wrote:
>
> On 24/07/18 12:38, Niall Douglas wrote:
> > The pipeline bubbles you refer to only occur when testing more than
> > one CPU flag at a time. One of the main reasons for choosing the
> > carry bit as return discriminant is because there are instructions
> > for testing just the carry bit alone on all such architectures. Thus
> > such partial flags stalls will never occur in this specific use
> > case.
> >
>
> I am reluctant to be so confident about the effects here - I really
> don't think you can generalise and say these stalls will never occur.


Remember we only care about the specific case of where an extern,
non-inlined function returns. On every architecture, that would involve
causing the carry flag to be set or be cleared (or equivalent in TLS),
executing a return from subroutine, and in the caller doing a branch if
carry set or clear.

When researching all this some years ago now, I studied x64, ARM and
AArch64, both in order and out of order variants. On those architectures -
which represent a good fraction of all CPUs likely to be in use in five
years time - I found between zero and three CPU cycle overhead, assuming
all warm cache. The out of order cores were almost always zero overhead as
the code after the return from function is speculatively executed.


>
> On a related point, many compilers do not track the state of flags
> across instruction pattern boundaries - /any/ use of a carry flag like
> this would involve significant engineering effort.
>
> Again, we only care about calls to non-inlined extern functions. In all
other cases, any use of the carry flag will be optimised out. So in fact
the proposed mechanism is purely about calling convention of extern
functions only, and should require very little work on the compiler because
for calls of extern functions, no optimisation is possible in its calling
convention anyway.

Niall

--
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/9ae9bd6a-a5cd-4aa7-b603-24f8964cbe2e%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 2:16:56 PM UTC+1, David Brown=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24/07/18 12:38, Nial=
l Douglas wrote:
<br>&gt; The pipeline bubbles you refer to only occur when testing more tha=
n
<br>&gt; one CPU flag at a time. One of the main reasons for choosing the
<br>&gt; carry bit as return discriminant is because there are instructions
<br>&gt; for testing just the carry bit alone on all such architectures. Th=
us
<br>&gt; such partial flags stalls will never occur in this specific use
<br>&gt; case.
<br>&gt;=20
<br>
<br>I am reluctant to be so confident about the effects here - I really
<br>don&#39;t think you can generalise and say these stalls will never occu=
r. </blockquote><div><br></div><div>Remember we only care about the specifi=
c case of where an extern, non-inlined function returns. On every architect=
ure, that would involve causing the carry flag to be set or be cleared (or =
equivalent in TLS), executing a return from subroutine, and in the caller d=
oing a branch if carry set or clear.</div><div><br></div><div>When research=
ing all this some years ago now, I studied x64, ARM and AArch64, both in or=
der and out of order variants. On those architectures - which represent a g=
ood fraction of all CPUs likely to be in use in five years time - I found b=
etween zero and three CPU cycle overhead, assuming all warm cache. The out =
of order cores were almost always zero overhead as the code after the retur=
n from function is speculatively executed.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><br>On a related point, many compilers d=
o not track the state of flags
<br>across instruction pattern boundaries - /any/ use of a carry flag like
<br>this would involve significant engineering effort.
<br><br></blockquote><div>Again, we only care about calls to non-inlined ex=
tern functions. In all other cases, any use of the carry flag will be optim=
ised out. So in fact the proposed mechanism is purely about calling convent=
ion of extern functions only, and should require very little work on the co=
mpiler because for calls of extern functions, no optimisation is possible i=
n its calling convention anyway.</div><div><br></div><div>Niall=C2=A0</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/9ae9bd6a-a5cd-4aa7-b603-24f8964cbe2e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ae9bd6a-a5cd-4aa7-b603-24f8964cbe2e=
%40isocpp.org</a>.<br />

------=_Part_9410_604003079.1532507211863--

------=_Part_9409_346432197.1532507211862--

.

------=_Part_9594_1060711400.1532532259209
Content-Type: multipart/alternative;
 boundary="----=_Part_9595_461667012.1532532259209"

------=_Part_9595_461667012.1532532259209
Content-Type: text/plain; charset="UTF-8"

On Wednesday, July 25, 2018 at 4:14:33 AM UTC-4, Niall Douglas wrote:
>
>
>>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of
>>>> its biggest flaws is that it doesn't allow for inter-operation with C++
>>>> static exceptions at all, despite being in part based on the same principle.
>>>>
>>>
>>> My _Fails() proposal does however work in constexpr,
>>>
>>
>> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can they
>> work with one another? Unless you're proposing to add `_Fails()` to C++,
>> which I think would be a rather hard sell.
>>
>
> I appreciate you are probably not up to date, as I have not issued a new
> draft of  D1095 which incorporates the substantial feedback I received from
> WG14. And I have only very briefly summarised what will go into that draft
> on std-proposals and /r/cpp/.
>
> But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T).
>

Pedantic note: `throws(T)` doesn't exist. `throws(<expr>)` is a
*conditional* throws declaration, much like `noexcept(<expr>)`. P0709 makes
that abundantly clear.

What you're looking for is `throws{T}`. Which P0709 treats as an extension,
not a required part of the proposal. So there's no guarantee it will make
it into any hypothetical C++23.

The only difference is auto-propagation, so a _Fails(T) if unhandled
> results in a failure to compile, whereas a throws(T) if unhandled
> propagates upwards.
>
> This is what WG14 asked for. As C++ 23 would surely be incorporating C22
> into itself, whatever goes into C also goes in C++.
>

That's not how C++ has worked since 1998. C++11 did not incorporate C99
wholesale; it only took specific things from it. Similarly, C++14/17/20 did
not adopt C11 wholesale. The two languages are *diverging*.

So why should we expect C++23 to adopt C22 in this way?

I intend to propose, in fact, that both mechanisms work perfectly in
> constexpr. It would let constexpr code choose whether failure should be
> handled explicitly (_Fails) or implicitly (throws), exactly the same as in
> non-constexpr.
>
> Niall
>

--
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/edaab808-c155-4369-9be9-e1a0fad36265%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, July 25, 2018 at 4:14:33 AM UTC-4, Niall Dou=
glas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><br></div><div>It&#39;s a C proposal; it doesn&#39;t interact with=
 `constexpr`. Indeed, one of its biggest flaws is that it doesn&#39;t allow=
 for inter-operation with C++ static exceptions at all, despite being in pa=
rt based on the same principle.<br></div></div></blockquote><div><br></div>=
<div>My _Fails() proposal does however work in constexpr,</div></div></bloc=
kquote><div><br></div><div>`_Fails()` is not valid C++, and `constexpr` is =
not valid C. How can they work with one another? Unless you&#39;re proposin=
g to add `_Fails()` to C++, which I think would be a rather hard sell.</div=
></div></blockquote><div><br></div><div>I appreciate you are probably not u=
p to date, as I have not issued a new draft of=C2=A0 D1095 which incorporat=
es the substantial feedback I received from WG14. And I have only very brie=
fly summarised what will go into that draft on std-proposals and /r/cpp/.</=
div><div><br></div><div>But in short, C22 _Fails(T) maps directly onto C++ =
23 throws(T).</div></blockquote><div><br></div><div>Pedantic note: `throws(=
T)` doesn&#39;t exist. `throws(&lt;expr&gt;)` is a <i>conditional</i> throw=
s declaration, much like `noexcept(&lt;expr&gt;)`. P0709 makes that abundan=
tly clear.</div><div><br></div><div>What you&#39;re looking for is `throws{=
T}`. Which P0709 treats as an extension, not a required part of the proposa=
l. So there&#39;s no guarantee it will make it into any hypothetical C++23.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>The =
only difference is auto-propagation, so a _Fails(T) if unhandled results in=
 a failure to compile, whereas a throws(T) if unhandled propagates upwards.=
</div><div><br></div><div>This is what WG14 asked for. As C++ 23 would sure=
ly be incorporating C22 into itself, whatever goes into C also goes in C++.=
</div></blockquote><div><br></div><div>That&#39;s not how C++ has worked si=
nce 1998. C++11 did not incorporate C99 wholesale; it only took specific th=
ings from it. Similarly, C++14/17/20 did not adopt C11 wholesale. The two l=
anguages are <i>diverging</i>.<br></div><div><br></div><div>So why should w=
e expect C++23 to adopt C22 in this way?<br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div>I intend to propose, in fact, that =
both mechanisms work perfectly in constexpr. It would let constexpr code ch=
oose whether failure should be handled explicitly (_Fails) or implicitly (t=
hrows), exactly the same as in non-constexpr.</div><div><br></div><div>Nial=
l</div></blockquote></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/edaab808-c155-4369-9be9-e1a0fad36265%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/edaab808-c155-4369-9be9-e1a0fad36265=
%40isocpp.org</a>.<br />

------=_Part_9595_461667012.1532532259209--

------=_Part_9594_1060711400.1532532259209--

.

------=_Part_9634_1944432700.1532537034498
Content-Type: multipart/alternative;
 boundary="----=_Part_9635_11244141.1532537034498"

------=_Part_9635_11244141.1532537034498
Content-Type: text/plain; charset="UTF-8"



On Wednesday, July 25, 2018 at 5:24:19 PM UTC+2, Nicol Bolas wrote:
>
> On Wednesday, July 25, 2018 at 4:14:33 AM UTC-4, Niall Douglas wrote:
>>
>>
>>>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one
>>>>> of its biggest flaws is that it doesn't allow for inter-operation with C++
>>>>> static exceptions at all, despite being in part based on the same principle.
>>>>>
>>>>
>>>> My _Fails() proposal does however work in constexpr,
>>>>
>>>
>>> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can
>>> they work with one another? Unless you're proposing to add `_Fails()` to
>>> C++, which I think would be a rather hard sell.
>>>
>>
>> I appreciate you are probably not up to date, as I have not issued a new
>> draft of  D1095 which incorporates the substantial feedback I received from
>> WG14. And I have only very briefly summarised what will go into that draft
>> on std-proposals and /r/cpp/.
>>
>> But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T).
>>
>
> Pedantic note: `throws(T)` doesn't exist. `throws(<expr>)` is a
> *conditional* throws declaration, much like `noexcept(<expr>)`. P0709
> makes that abundantly clear.
>
> What you're looking for is `throws{T}`. Which P0709 treats as an
> extension, not a required part of the proposal. So there's no guarantee it
> will make it into any hypothetical C++23.
>
> The only difference is auto-propagation, so a _Fails(T) if unhandled
>> results in a failure to compile, whereas a throws(T) if unhandled
>> propagates upwards.
>>
>> This is what WG14 asked for. As C++ 23 would surely be incorporating C22
>> into itself, whatever goes into C also goes in C++.
>>
>
> That's not how C++ has worked since 1998. C++11 did not incorporate C99
> wholesale; it only took specific things from it. Similarly, C++14/17/20 did
> not adopt C11 wholesale. The two languages are *diverging*.
>
> So why should we expect C++23 to adopt C22 in this way?
>
>
To make easier to share code between? Image big C22 library that use this
new calling convention in headers, if we accept this part of C22 using this
library in C++23 will be trivial. This is too other way around, it allow
C++ to define headers that will be easy consumable by C and other languages
that will support C22 exceptions (this is major reason).


> I intend to propose, in fact, that both mechanisms work perfectly in
>> constexpr. It would let constexpr code choose whether failure should be
>> handled explicitly (_Fails) or implicitly (throws), exactly the same as in
>> non-constexpr.
>>
>> Niall
>>
>

--
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/61682de8-3bf2-42d4-ae19-fcf3bd1d93a0%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, July 25, 2018 at 5:24:19 PM UTC+2, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Wednesday, July 25, 2018 at 4:14:33 AM UTC-4, Niall Douglas wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><=
div>It&#39;s a C proposal; it doesn&#39;t interact with `constexpr`. Indeed=
, one of its biggest flaws is that it doesn&#39;t allow for inter-operation=
 with C++ static exceptions at all, despite being in part based on the same=
 principle.<br></div></div></blockquote><div><br></div><div>My _Fails() pro=
posal does however work in constexpr,</div></div></blockquote><div><br></di=
v><div>`_Fails()` is not valid C++, and `constexpr` is not valid C. How can=
 they work with one another? Unless you&#39;re proposing to add `_Fails()` =
to C++, which I think would be a rather hard sell.</div></div></blockquote>=
<div><br></div><div>I appreciate you are probably not up to date, as I have=
 not issued a new draft of=C2=A0 D1095 which incorporates the substantial f=
eedback I received from WG14. And I have only very briefly summarised what =
will go into that draft on std-proposals and /r/cpp/.</div><div><br></div><=
div>But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T).</div><=
/blockquote><div><br></div><div>Pedantic note: `throws(T)` doesn&#39;t exis=
t. `throws(&lt;expr&gt;)` is a <i>conditional</i> throws declaration, much =
like `noexcept(&lt;expr&gt;)`. P0709 makes that abundantly clear.</div><div=
><br></div><div>What you&#39;re looking for is `throws{T}`. Which P0709 tre=
ats as an extension, not a required part of the proposal. So there&#39;s no=
 guarantee it will make it into any hypothetical C++23.</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div>The only difference is auto-p=
ropagation, so a _Fails(T) if unhandled results in a failure to compile, wh=
ereas a throws(T) if unhandled propagates upwards.</div><div><br></div><div=
>This is what WG14 asked for. As C++ 23 would surely be incorporating C22 i=
nto itself, whatever goes into C also goes in C++.</div></blockquote><div><=
br></div><div>That&#39;s not how C++ has worked since 1998. C++11 did not i=
ncorporate C99 wholesale; it only took specific things from it. Similarly, =
C++14/17/20 did not adopt C11 wholesale. The two languages are <i>diverging=
</i>.<br></div><div><br></div><div>So why should we expect C++23 to adopt C=
22 in this way?<br></div><div><br></div></div></blockquote><div>=C2=A0</div=
><div>To make easier to share code between? Image big C22 library that use =
this new calling convention in headers, if we accept this part of C22 using=
 this library in C++23 will be trivial. This is too other way around, it al=
low C++ to define headers that will be easy consumable by C and other langu=
ages that will support C22 exceptions (this is major reason).<br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I intend to propose=
, in fact, that both mechanisms work perfectly in constexpr. It would let c=
onstexpr code choose whether failure should be handled explicitly (_Fails) =
or implicitly (throws), exactly the same as in non-constexpr.</div><div><br=
></div><div>Niall</div></blockquote></div></blockquote></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/61682de8-3bf2-42d4-ae19-fcf3bd1d93a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61682de8-3bf2-42d4-ae19-fcf3bd1d93a0=
%40isocpp.org</a>.<br />

------=_Part_9635_11244141.1532537034498--

------=_Part_9634_1944432700.1532537034498--

.

------=_Part_631_879644784.1532538445856
Content-Type: multipart/alternative;
 boundary="----=_Part_632_1086212527.1532538445856"

------=_Part_632_1086212527.1532538445856
Content-Type: text/plain; charset="UTF-8"

On Wednesday, July 25, 2018 at 12:43:54 PM UTC-4, Marcin Jaczewski wrote:
>
> On Wednesday, July 25, 2018 at 5:24:19 PM UTC+2, Nicol Bolas wrote:
>>
>> On Wednesday, July 25, 2018 at 4:14:33 AM UTC-4, Niall Douglas wrote:
>>>
>>>
>>>>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one
>>>>>> of its biggest flaws is that it doesn't allow for inter-operation with C++
>>>>>> static exceptions at all, despite being in part based on the same principle.
>>>>>>
>>>>>
>>>>> My _Fails() proposal does however work in constexpr,
>>>>>
>>>>
>>>> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can
>>>> they work with one another? Unless you're proposing to add `_Fails()` to
>>>> C++, which I think would be a rather hard sell.
>>>>
>>>
>>> I appreciate you are probably not up to date, as I have not issued a new
>>> draft of  D1095 which incorporates the substantial feedback I received from
>>> WG14. And I have only very briefly summarised what will go into that draft
>>> on std-proposals and /r/cpp/.
>>>
>>> But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T).
>>>
>>
>> Pedantic note: `throws(T)` doesn't exist. `throws(<expr>)` is a
>> *conditional* throws declaration, much like `noexcept(<expr>)`. P0709
>> makes that abundantly clear.
>>
>> What you're looking for is `throws{T}`. Which P0709 treats as an
>> extension, not a required part of the proposal. So there's no guarantee it
>> will make it into any hypothetical C++23.
>>
>> The only difference is auto-propagation, so a _Fails(T) if unhandled
>>> results in a failure to compile, whereas a throws(T) if unhandled
>>> propagates upwards.
>>>
>>> This is what WG14 asked for. As C++ 23 would surely be incorporating C22
>>> into itself, whatever goes into C also goes in C++.
>>>
>>
>> That's not how C++ has worked since 1998. C++11 did not incorporate C99
>> wholesale; it only took specific things from it. Similarly, C++14/17/20 did
>> not adopt C11 wholesale. The two languages are *diverging*.
>>
>> So why should we expect C++23 to adopt C22 in this way?
>>
>>
> To make easier to share code between? Image big C22 library that use this
> new calling convention in headers, if we accept this part of C22 using this
> library in C++23 will be trivial.
>

Define "using this library in C++23". Do you mean compiling it as C++? Or
linking with it in C++? If it's compiling as C++, then that library's
writer would still have to limit themselves to the subset of C22 that C++
supports.

If you're talking about ABI interop, we don't need C++ to be able to read
C22 to have that. ABIs can allow a C++ `throws` function that is declared
`extern "C"` to be ABI-equivalent to a `_Fails(cxx_error)` or whatever.
Yes, there would have to be two versions of the header to make that work.

However, if C++ consuming C headers directly is an important thing, then
C++ would still not have to include the entire mechanism. We would simply
declare that `_Fails()` is a legal thing, but that you can only fail with
`cxx_error` as the type, and that such a function's declaration is exactly
equivalent to a function declared with `throws`. And that's it. C uses its
mechanism on its side, and C++ uses its mechanism on its side.

The problem of course is that C users may not want to use our error type.
And if they don't, that limits interoperation drastically.

This is too other way around, it allow C++ to define headers that will be
> easy consumable by C and other languages that will support C22 exceptions
> (this is major reason).
>

Such "C++ headers" would just be C22 headers, since they couldn't contain
any actual C++.

--
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/9ae0c0a2-2fde-4260-bae3-ba74623ec139%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, July 25, 2018 at 12:43:54 PM UTC-4, Marcin J=
aczewski 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=
">On Wednesday, July 25, 2018 at 5:24:19 PM UTC+2, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, July 25, 2=
018 at 4:14:33 AM UTC-4, Niall Douglas wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><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"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><br></div><div>It&#39;s a C proposal; i=
t doesn&#39;t interact with `constexpr`. Indeed, one of its biggest flaws i=
s that it doesn&#39;t allow for inter-operation with C++ static exceptions =
at all, despite being in part based on the same principle.<br></div></div><=
/blockquote><div><br></div><div>My _Fails() proposal does however work in c=
onstexpr,</div></div></blockquote><div><br></div><div>`_Fails()` is not val=
id C++, and `constexpr` is not valid C. How can they work with one another?=
 Unless you&#39;re proposing to add `_Fails()` to C++, which I think would =
be a rather hard sell.</div></div></blockquote><div><br></div><div>I apprec=
iate you are probably not up to date, as I have not issued a new draft of=
=C2=A0 D1095 which incorporates the substantial feedback I received from WG=
14. And I have only very briefly summarised what will go into that draft on=
 std-proposals and /r/cpp/.</div><div><br></div><div>But in short, C22 _Fai=
ls(T) maps directly onto C++ 23 throws(T).</div></blockquote><div><br></div=
><div>Pedantic note: `throws(T)` doesn&#39;t exist. `throws(&lt;expr&gt;)` =
is a <i>conditional</i> throws declaration, much like `noexcept(&lt;expr&gt=
;)`. P0709 makes that abundantly clear.</div><div><br></div><div>What you&#=
39;re looking for is `throws{T}`. Which P0709 treats as an extension, not a=
 required part of the proposal. So there&#39;s no guarantee it will make it=
 into any hypothetical C++23.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div>The only difference is auto-propagation, so a _Fails(T)=
 if unhandled results in a failure to compile, whereas a throws(T) if unhan=
dled propagates upwards.</div><div><br></div><div>This is what WG14 asked f=
or. As C++ 23 would surely be incorporating C22 into itself, whatever goes =
into C also goes in C++.</div></blockquote><div><br></div><div>That&#39;s n=
ot how C++ has worked since 1998. C++11 did not incorporate C99 wholesale; =
it only took specific things from it. Similarly, C++14/17/20 did not adopt =
C11 wholesale. The two languages are <i>diverging</i>.<br></div><div><br></=
div><div>So why should we expect C++23 to adopt C22 in this way?<br></div><=
div><br></div></div></blockquote><div>=C2=A0</div><div>To make easier to sh=
are code between? Image big C22 library that use this new calling conventio=
n in headers, if we accept this part of C22 using this library in C++23 wil=
l be trivial.</div></div></blockquote><div><br></div><div>Define &quot;usin=
g this library in C++23&quot;. Do you mean compiling it as C++? Or linking =
with it in C++? If it&#39;s compiling as C++, then that library&#39;s write=
r would still have to limit themselves to the subset of C22 that C++ suppor=
ts.</div><div><br></div><div>If you&#39;re talking about ABI interop, we do=
n&#39;t need C++ to be able to read C22 to have that. ABIs can allow a C++ =
`throws` function that is declared `extern &quot;C&quot;` to be ABI-equival=
ent to a `_Fails(cxx_error)` or whatever. Yes, there would have to be two v=
ersions of the header to make that work.<br></div><div><br></div><div></div=
><div>However, if C++ consuming C headers directly is an important thing, t=
hen C++ would still not have to include the entire mechanism. We would simp=
ly declare that `_Fails()` is a legal thing, but that you can only fail wit=
h `cxx_error` as the type, and that such a function&#39;s declaration is ex=
actly equivalent to a function declared with `throws`. And that&#39;s it. C=
 uses its mechanism on its side, and C++ uses its mechanism on its side.</d=
iv><div><br></div><div>The problem of course is that C users may not want t=
o use our error type. And if they don&#39;t, that limits interoperation dra=
stically.<br></div><div><br></div><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>This is too other way around, it allow C++ to d=
efine headers that will be easy consumable by C and other languages that wi=
ll support C22 exceptions (this is major reason).<br></div></div></blockquo=
te><div><br></div><div>Such &quot;C++ headers&quot; would just be C22 heade=
rs, since they couldn&#39;t contain any actual C++.<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/9ae0c0a2-2fde-4260-bae3-ba74623ec139%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ae0c0a2-2fde-4260-bae3-ba74623ec139=
%40isocpp.org</a>.<br />

------=_Part_632_1086212527.1532538445856--

------=_Part_631_879644784.1532538445856--

.

------=_Part_348_1830221235.1532543233759
Content-Type: multipart/alternative;
 boundary="----=_Part_349_1384241990.1532543233760"

------=_Part_349_1384241990.1532543233760
Content-Type: text/plain; charset="UTF-8"



On Wednesday, July 25, 2018 at 7:07:26 PM UTC+2, Nicol Bolas wrote:
>
> On Wednesday, July 25, 2018 at 12:43:54 PM UTC-4, Marcin Jaczewski wrote:
>>
>> On Wednesday, July 25, 2018 at 5:24:19 PM UTC+2, Nicol Bolas wrote:
>>>
>>> On Wednesday, July 25, 2018 at 4:14:33 AM UTC-4, Niall Douglas wrote:
>>>>
>>>>
>>>>>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one
>>>>>>> of its biggest flaws is that it doesn't allow for inter-operation with C++
>>>>>>> static exceptions at all, despite being in part based on the same principle.
>>>>>>>
>>>>>>
>>>>>> My _Fails() proposal does however work in constexpr,
>>>>>>
>>>>>
>>>>> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can
>>>>> they work with one another? Unless you're proposing to add `_Fails()` to
>>>>> C++, which I think would be a rather hard sell.
>>>>>
>>>>
>>>> I appreciate you are probably not up to date, as I have not issued a
>>>> new draft of  D1095 which incorporates the substantial feedback I received
>>>> from WG14. And I have only very briefly summarised what will go into that
>>>> draft on std-proposals and /r/cpp/.
>>>>
>>>> But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T).
>>>>
>>>
>>> Pedantic note: `throws(T)` doesn't exist. `throws(<expr>)` is a
>>> *conditional* throws declaration, much like `noexcept(<expr>)`. P0709
>>> makes that abundantly clear.
>>>
>>> What you're looking for is `throws{T}`. Which P0709 treats as an
>>> extension, not a required part of the proposal. So there's no guarantee it
>>> will make it into any hypothetical C++23.
>>>
>>> The only difference is auto-propagation, so a _Fails(T) if unhandled
>>>> results in a failure to compile, whereas a throws(T) if unhandled
>>>> propagates upwards.
>>>>
>>>> This is what WG14 asked for. As C++ 23 would surely be incorporating
>>>> C22 into itself, whatever goes into C also goes in C++.
>>>>
>>>
>>> That's not how C++ has worked since 1998. C++11 did not incorporate C99
>>> wholesale; it only took specific things from it. Similarly, C++14/17/20 did
>>> not adopt C11 wholesale. The two languages are *diverging*.
>>>
>>> So why should we expect C++23 to adopt C22 in this way?
>>>
>>>
>> To make easier to share code between? Image big C22 library that use this
>> new calling convention in headers, if we accept this part of C22 using this
>> library in C++23 will be trivial.
>>
>
> Define "using this library in C++23". Do you mean compiling it as C++? Or
> linking with it in C++? If it's compiling as C++, then that library's
> writer would still have to limit themselves to the subset of C22 that C++
> supports.
>
>
Yes, and whole point is to expand things that are shared between C and C++
that more libs are compatible even if authors do not focus on this.


> If you're talking about ABI interop, we don't need C++ to be able to read
> C22 to have that. ABIs can allow a C++ `throws` function that is declared
> `extern "C"` to be ABI-equivalent to a `_Fails(cxx_error)` or whatever.
> Yes, there would have to be two versions of the header to make that work.
>
> However, if C++ consuming C headers directly is an important thing, then
> C++ would still not have to include the entire mechanism. We would simply
> declare that `_Fails()` is a legal thing, but that you can only fail with
> `cxx_error` as the type, and that such a function's declaration is exactly
> equivalent to a function declared with `throws`. And that's it. C uses its
> mechanism on its side, and C++ uses its mechanism on its side.
>
>
Agree, this could this could work too.


> The problem of course is that C users may not want to use our error type.
> And if they don't, that limits interoperation drastically.
>
>
This depend on exactly version will be added to C++, if we have only
`std::error` then yes, if not and C++ support `throws{T}` then we could
handle more types.
But this will need some conversion because it would be very hard to have
`_Fails(T)` and `throws{T}` for same type. Reason is different requirement
for both versions.
From previous discussion I could see this avoided by using different
related types like `_Fails(T::exception_payload)` and `throws{T}`.
If this new exception would be implemented in way I see then this will not
be big problem but if another way will be choose then this indeed become
problematic to easy share headers.


> This is too other way around, it allow C++ to define headers that will be
>> easy consumable by C and other languages that will support C22 exceptions
>> (this is major reason).
>>
>
> Such "C++ headers" would just be C22 headers, since they couldn't contain
> any actual C++.
>

Right

--
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/5d615d65-ca5e-4cbe-920b-59b47082b929%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, July 25, 2018 at 7:07:26 PM UTC+2, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Wednesday, July 25, 2018 at 12:43:54 PM UTC-4, Marcin Jaczewski wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, Ju=
ly 25, 2018 at 5:24:19 PM UTC+2, Nicol Bolas wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Wednesday, July 25, 2018 at 4:14:33 AM =
UTC-4, Niall Douglas wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br></div><div>It&#39;s a C proposal; it doesn&#39;t inte=
ract with `constexpr`. Indeed, one of its biggest flaws is that it doesn&#3=
9;t allow for inter-operation with C++ static exceptions at all, despite be=
ing in part based on the same principle.<br></div></div></blockquote><div><=
br></div><div>My _Fails() proposal does however work in constexpr,</div></d=
iv></blockquote><div><br></div><div>`_Fails()` is not valid C++, and `const=
expr` is not valid C. How can they work with one another? Unless you&#39;re=
 proposing to add `_Fails()` to C++, which I think would be a rather hard s=
ell.</div></div></blockquote><div><br></div><div>I appreciate you are proba=
bly not up to date, as I have not issued a new draft of=C2=A0 D1095 which i=
ncorporates the substantial feedback I received from WG14. And I have only =
very briefly summarised what will go into that draft on std-proposals and /=
r/cpp/.</div><div><br></div><div>But in short, C22 _Fails(T) maps directly =
onto C++ 23 throws(T).</div></blockquote><div><br></div><div>Pedantic note:=
 `throws(T)` doesn&#39;t exist. `throws(&lt;expr&gt;)` is a <i>conditional<=
/i> throws declaration, much like `noexcept(&lt;expr&gt;)`. P0709 makes tha=
t abundantly clear.</div><div><br></div><div>What you&#39;re looking for is=
 `throws{T}`. Which P0709 treats as an extension, not a required part of th=
e proposal. So there&#39;s no guarantee it will make it into any hypothetic=
al C++23.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
The only difference is auto-propagation, so a _Fails(T) if unhandled result=
s in a failure to compile, whereas a throws(T) if unhandled propagates upwa=
rds.</div><div><br></div><div>This is what WG14 asked for. As C++ 23 would =
surely be incorporating C22 into itself, whatever goes into C also goes in =
C++.</div></blockquote><div><br></div><div>That&#39;s not how C++ has worke=
d since 1998. C++11 did not incorporate C99 wholesale; it only took specifi=
c things from it. Similarly, C++14/17/20 did not adopt C11 wholesale. The t=
wo languages are <i>diverging</i>.<br></div><div><br></div><div>So why shou=
ld we expect C++23 to adopt C22 in this way?<br></div><div><br></div></div>=
</blockquote><div>=C2=A0</div><div>To make easier to share code between? Im=
age big C22 library that use this new calling convention in headers, if we =
accept this part of C22 using this library in C++23 will be trivial.</div><=
/div></blockquote><div><br></div><div>Define &quot;using this library in C+=
+23&quot;. Do you mean compiling it as C++? Or linking with it in C++? If i=
t&#39;s compiling as C++, then that library&#39;s writer would still have t=
o limit themselves to the subset of C22 that C++ supports.</div><div><br></=
div></div></blockquote><div><br></div><div>Yes, and whole point is to expan=
d things that are shared between C and C++ that more libs are compatible ev=
en if authors do not focus on this.<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>If you&#39=
;re talking about ABI interop, we don&#39;t need C++ to be able to read C22=
 to have that. ABIs can allow a C++ `throws` function that is declared `ext=
ern &quot;C&quot;` to be ABI-equivalent to a `_Fails(cxx_error)` or whateve=
r. Yes, there would have to be two versions of the header to make that work=
..<br></div><div><br></div><div></div><div>However, if C++ consuming C heade=
rs directly is an important thing, then C++ would still not have to include=
 the entire mechanism. We would simply declare that `_Fails()` is a legal t=
hing, but that you can only fail with `cxx_error` as the type, and that suc=
h a function&#39;s declaration is exactly equivalent to a function declared=
 with `throws`. And that&#39;s it. C uses its mechanism on its side, and C+=
+ uses its mechanism on its side.</div><div><br></div></div></blockquote><d=
iv><br></div><div>Agree, this could this could work too.<br></div><div>=C2=
=A0</div><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><div>The problem of course is that C users may not want to use our e=
rror type. And if they don&#39;t, that limits interoperation drastically.<b=
r></div><div><br></div></div></blockquote><div><br></div><div>This depend o=
n exactly version will be added to C++, if we have only `std::error` then y=
es, if not and C++ support `throws{T}` then we could handle more types.</di=
v><div>But this will need some conversion because it would be very hard to =
have `_Fails(T)` and `throws{T}` for same type. Reason is different require=
ment for both versions.</div><div>From previous discussion I could see this=
 avoided by using different related types like `_Fails(T::exception_payload=
)` and `throws{T}`.</div><div>If this new exception would be implemented in=
 way I see then this will not be big problem but if another way will be cho=
ose then this indeed become problematic to easy share headers.<br></div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div></div><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>T=
his is too other way around, it allow C++ to define headers that will be ea=
sy consumable by C and other languages that will support C22 exceptions (th=
is is major reason).<br></div></div></blockquote><div><br></div><div>Such &=
quot;C++ headers&quot; would just be C22 headers, since they couldn&#39;t c=
ontain any actual C++.<br></div></div></blockquote><div><br></div><div>Righ=
t<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/5d615d65-ca5e-4cbe-920b-59b47082b929%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d615d65-ca5e-4cbe-920b-59b47082b929=
%40isocpp.org</a>.<br />

------=_Part_349_1384241990.1532543233760--

------=_Part_348_1830221235.1532543233759--

.

------=_Part_9439_1083350221.1532548023426
Content-Type: multipart/alternative;
 boundary="----=_Part_9440_1277428745.1532548023426"

------=_Part_9440_1277428745.1532548023426
Content-Type: text/plain; charset="UTF-8"


>
> But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T).
>>
>
> Pedantic note: `throws(T)` doesn't exist. `throws(<expr>)` is a
> *conditional* throws declaration, much like `noexcept(<expr>)`. P0709
> makes that abundantly clear.
>
> What you're looking for is `throws{T}`. Which P0709 treats as an
> extension, not a required part of the proposal. So there's no guarantee it
> will make it into any hypothetical C++23.
>

There may be some movement on that next revision of P0709 in order to ease
things for WG14.


>
> The only difference is auto-propagation, so a _Fails(T) if unhandled
>> results in a failure to compile, whereas a throws(T) if unhandled
>> propagates upwards.
>>
>> This is what WG14 asked for. As C++ 23 would surely be incorporating C22
>> into itself, whatever goes into C also goes in C++.
>>
>
> That's not how C++ has worked since 1998. C++11 did not incorporate C99
> wholesale; it only took specific things from it. Similarly, C++14/17/20 did
> not adopt C11 wholesale. The two languages are *diverging*.
>

> So why should we expect C++23 to adopt C22 in this way?
>
> Both convenors of WG14 and WG21 want coevolution on this feature,
especially as it makes it much easier to bring C++ contracts into C. That
doesn't mean it will happen of course. But it does mean that right now,
that's the aim, until either committee conclusively decides otherwise.

Niall

--
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/fa71557a-d506-4f1d-b39e-590f337b8ae3%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>But in short, C22 _Fails(T=
) maps directly onto C++ 23 throws(T).</div></blockquote><div><br></div><di=
v>Pedantic note: `throws(T)` doesn&#39;t exist. `throws(&lt;expr&gt;)` is a=
 <i>conditional</i> throws declaration, much like `noexcept(&lt;expr&gt;)`.=
 P0709 makes that abundantly clear.</div><div><br></div><div>What you&#39;r=
e looking for is `throws{T}`. Which P0709 treats as an extension, not a req=
uired part of the proposal. So there&#39;s no guarantee it will make it int=
o any hypothetical C++23.</div></div></blockquote><div><br></div><div>There=
 may be some movement on that next revision of P0709 in order to ease thing=
s for WG14.</div><div>=C2=A0</div><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><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div>The only difference is auto-propagation, so a _Fails(T) if unhandle=
d results in a failure to compile, whereas a throws(T) if unhandled propaga=
tes upwards.</div><div><br></div><div>This is what WG14 asked for. As C++ 2=
3 would surely be incorporating C22 into itself, whatever goes into C also =
goes in C++.</div></blockquote><div><br></div><div>That&#39;s not how C++ h=
as worked since 1998. C++11 did not incorporate C99 wholesale; it only took=
 specific things from it. Similarly, C++14/17/20 did not adopt C11 wholesal=
e. The two languages are <i>diverging</i>.<br></div></div></blockquote><blo=
ckquote 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><br></div><d=
iv>So why should we expect C++23 to adopt C22 in this way?<br></div><div><b=
r></div></div></blockquote><div>Both convenors of WG14 and WG21 want coevol=
ution on this feature, especially as it makes it much easier to bring C++ c=
ontracts into C. That doesn&#39;t mean it will happen of course. But it doe=
s mean that right now, that&#39;s the aim, until either committee conclusiv=
ely decides otherwise.</div><div><br></div><div>Niall</div><div><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/fa71557a-d506-4f1d-b39e-590f337b8ae3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fa71557a-d506-4f1d-b39e-590f337b8ae3=
%40isocpp.org</a>.<br />

------=_Part_9440_1277428745.1532548023426--

------=_Part_9439_1083350221.1532548023426--

.

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

Niall,

Do you have an updated version of your mechanism paper? Among my
colleagues, there is a lot of informal interest that Herb's paper just
doesn't address - and your paper is really good for shutting down FUD.

If you do, could you ping it through here?

Thanks,

Ga=C5=A1per

On Wed, Jul 25, 2018 at 8:47 PM, Niall Douglas <nialldouglas14@gmail.com>
wrote:

> But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T).
>>>
>>
>> Pedantic note: `throws(T)` doesn't exist. `throws(<expr>)` is a
>> *conditional* throws declaration, much like `noexcept(<expr>)`. P0709
>> makes that abundantly clear.
>>
>> What you're looking for is `throws{T}`. Which P0709 treats as an
>> extension, not a required part of the proposal. So there's no guarantee =
it
>> will make it into any hypothetical C++23.
>>
>
> There may be some movement on that next revision of P0709 in order to eas=
e
> things for WG14.
>
>
>>
>> The only difference is auto-propagation, so a _Fails(T) if unhandled
>>> results in a failure to compile, whereas a throws(T) if unhandled
>>> propagates upwards.
>>>
>>> This is what WG14 asked for. As C++ 23 would surely be incorporating C2=
2
>>> into itself, whatever goes into C also goes in C++.
>>>
>>
>> That's not how C++ has worked since 1998. C++11 did not incorporate C99
>> wholesale; it only took specific things from it. Similarly, C++14/17/20 =
did
>> not adopt C11 wholesale. The two languages are *diverging*.
>>
>
>> So why should we expect C++23 to adopt C22 in this way?
>>
>> Both convenors of WG14 and WG21 want coevolution on this feature,
> especially as it makes it much easier to bring C++ contracts into C. That
> doesn't mean it will happen of course. But it does mean that right now,
> that's the aim, until either committee conclusively decides otherwise.
>
> Niall
>
> --
> 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/fa71557a-d506-4f1d-
> b39e-590f337b8ae3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fa71557a-d5=
06-4f1d-b39e-590f337b8ae3%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAANG%3DkXwsh37OYXvLrfTo8oFuW3q%2BxR-DheGYTN%2BD=
kUzwWVziA%40mail.gmail.com.

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

<div dir=3D"ltr">Niall,<div><br></div><div>Do you have an updated version o=
f your mechanism paper? Among my colleagues, there is a lot of informal int=
erest that Herb&#39;s paper just doesn&#39;t address - and your paper is re=
ally good for shutting down FUD.</div><div><br></div><div>If you do, could =
you ping it through here?</div><div><br></div><div>Thanks,</div><div><br></=
div><div>Ga=C5=A1per</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Jul 25, 2018 at 8:47 PM, Niall Douglas <span dir=
=3D"ltr">&lt;<a href=3D"mailto:nialldouglas14@gmail.com" target=3D"_blank">=
nialldouglas14@gmail.com</a>&gt;</span> wrote:<br><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"><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>But in s=
hort, C22 _Fails(T) maps directly onto C++ 23 throws(T).</div></blockquote>=
<div><br></div><div>Pedantic note: `throws(T)` doesn&#39;t exist. `throws(&=
lt;expr&gt;)` is a <i>conditional</i> throws declaration, much like `noexce=
pt(&lt;expr&gt;)`. P0709 makes that abundantly clear.</div><div><br></div><=
div>What you&#39;re looking for is `throws{T}`. Which P0709 treats as an ex=
tension, not a required part of the proposal. So there&#39;s no guarantee i=
t will make it into any hypothetical C++23.</div></div></blockquote><div><b=
r></div></span><div>There may be some movement on that next revision of P07=
09 in order to ease things for WG14.</div><span class=3D""><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div>The only difference is auto-prop=
agation, so a _Fails(T) if unhandled results in a failure to compile, where=
as a throws(T) if unhandled propagates upwards.</div><div><br></div><div>Th=
is is what WG14 asked for. As C++ 23 would surely be incorporating C22 into=
 itself, whatever goes into C also goes in C++.</div></blockquote><div><br>=
</div><div>That&#39;s not how C++ has worked since 1998. C++11 did not inco=
rporate C99 wholesale; it only took specific things from it. Similarly, C++=
14/17/20 did not adopt C11 wholesale. The two languages are <i>diverging</i=
>.<br></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br></div><div>So why should we expect C++23 to adopt C22=
 in this way?<br></div><div><br></div></div></blockquote></span><div>Both c=
onvenors of WG14 and WG21 want coevolution on this feature, especially as i=
t makes it much easier to bring C++ contracts into C. That doesn&#39;t mean=
 it will happen of course. But it does mean that right now, that&#39;s the =
aim, until either committee conclusively decides otherwise.</div><div><br><=
/div><div>Niall</div><div><br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<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/fa71557a-d506-4f1d-b39e-590f337b8ae3%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/fa71=
557a-d506-4f1d-<wbr>b39e-590f337b8ae3%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXwsh37OYXvLrfTo8oFuW3q%2BxR-=
DheGYTN%2BDkUzwWVziA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXw=
sh37OYXvLrfTo8oFuW3q%2BxR-DheGYTN%2BDkUzwWVziA%40mail.gmail.com</a>.<br />

--0000000000005b76090571e3906d--

.

------=_Part_311_1699157424.1532627516301
Content-Type: multipart/alternative;
 boundary="----=_Part_312_602961286.1532627516301"

------=_Part_312_602961286.1532627516301
Content-Type: text/plain; charset="UTF-8"


>
>
> Do you have an updated version of your mechanism paper? Among my
> colleagues, there is a lot of informal interest that Herb's paper just
> doesn't address - and your paper is really good for shutting down FUD.
>
> If you do, could you ping it through here?
>
> Only the drafts posted to std-proposals so far.

I aim to have the next draft of said papers ready for the August SG14
telecon, which is mid-August.

Final paper will need to be ready for the September WG14 mailing deadline
or the October WG21 mailing deadline.

They'll all be posted to std-proposals beforehand, so watch this forum.

Niall

--
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/d5e41850-3433-4195-b9c3-123ce20dc4e2%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>Do you have an updated version of your mechanism pa=
per? Among my colleagues, there is a lot of informal interest that Herb&#39=
;s paper just doesn&#39;t address - and your paper is really good for shutt=
ing down FUD.</div><div><br></div><div>If you do, could you ping it through=
 here?</div><div><br></div></div></blockquote><div>Only the drafts posted t=
o std-proposals so far.</div><div><br></div><div>I aim to have the next dra=
ft of said papers ready for the August SG14 telecon, which is mid-August.</=
div><div><br></div><div>Final paper will need to be ready for the September=
 WG14 mailing deadline or the October WG21 mailing deadline.</div><div><br>=
</div><div>They&#39;ll all be posted to std-proposals beforehand, so watch =
this forum.</div><div><br></div><div>Niall=C2=A0</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/d5e41850-3433-4195-b9c3-123ce20dc4e2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d5e41850-3433-4195-b9c3-123ce20dc4e2=
%40isocpp.org</a>.<br />

------=_Part_312_602961286.1532627516301--

------=_Part_311_1699157424.1532627516301--

.