------=_Part_707_1731475089.1533890070558
Content-Type: multipart/alternative;
 boundary="----=_Part_708_1786737424.1533890070558"

------=_Part_708_1786737424.1533890070558
Content-Type: text/plain; charset="UTF-8"

Just to keep everybody on WG21 up to date, WG14 likes this proposal a lot,
and apart from the .left, .right and .positive being replaced with
_EitherValue(), _EitherError() and _EitherHasValue(), the above is
essentially the paper to be published.

Obviously if you have any additional feedback, please send it.

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/b1e954fb-bab8-4746-abf1-2e699e702787%40isocpp.org.

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

<div dir=3D"ltr">Just to keep everybody on WG21 up to date, WG14 likes this=
 proposal a lot, and apart from the .left, .right and .positive being repla=
ced with _EitherValue(), _EitherError() and _EitherHasValue(), the above is=
 essentially the paper to be published.<div><br></div><div>Obviously if you=
 have any additional feedback, please send it.</div><div><br></div><div>Nia=
ll</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/b1e954fb-bab8-4746-abf1-2e699e702787%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1e954fb-bab8-4746-abf1-2e699e702787=
%40isocpp.org</a>.<br />

------=_Part_708_1786737424.1533890070558--

------=_Part_707_1731475089.1533890070558--

.

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

The version you posted is the most elegant that I have seen. My only
concern was what the C guys would think about the errno discussion, but
that was obviously misplaced.

However, I think the new syntax is uglier than the struct approach. Can you
provide a code example?

I get why the prefix is wanted, but that prefix is screwing up the
connection between name and meaning. If I said to you "either value", it
will make you think theres some kind of selection between two values. Same
with error and hasvalue. I think this is going to confuse the hell out of
fresh eyes.

On Fri, 10 Aug 2018, 09:34 Niall Douglas, <nialldouglas14@gmail.com> wrote:

> Just to keep everybody on WG21 up to date, WG14 likes this proposal a lot,
> and apart from the .left, .right and .positive being replaced with
> _EitherValue(), _EitherError() and _EitherHasValue(), the above is
> essentially the paper to be published.
>
> Obviously if you have any additional feedback, please send it.
>
> 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/b1e954fb-bab8-4746-abf1-2e699e702787%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b1e954fb-bab8-4746-abf1-2e699e702787%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"auto"><div>The version you posted is the most elegant that I ha=
ve seen. My only concern was what the C guys would think about the errno di=
scussion, but that was obviously misplaced.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">However, I think the new syntax is uglier than the stru=
ct approach. Can you provide a code example?</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">I get why the prefix is wanted, but that prefix is scr=
ewing up the connection between name and meaning. If I said to you &quot;ei=
ther value&quot;, it will make you think theres some kind of selection betw=
een two values. Same with error and hasvalue. I think this is going to conf=
use the hell out of fresh eyes.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Fri, =
10 Aug 2018, 09:34 Niall Douglas, &lt;<a href=3D"mailto:nialldouglas14@gmai=
l.com">nialldouglas14@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Just to keep everybody on WG21 up to date, W=
G14 likes this proposal a lot, and apart from the .left, .right and .positi=
ve being replaced with _EitherValue(), _EitherError() and _EitherHasValue()=
, the above is essentially the paper to be published.<div><br></div><div>Ob=
viously if you have any additional feedback, please send it.</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" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/b1e954fb-bab8-4746-abf1-2e699e702787%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/b1e954fb-bab8-4746-abf1-2e699e702787%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

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

--0000000000009c36b1057311a8f2--

.

------=_Part_762_1402125512.1533896576633
Content-Type: multipart/alternative;
 boundary="----=_Part_763_113070160.1533896576633"

------=_Part_763_113070160.1533896576633
Content-Type: text/plain; charset="UTF-8"

From C++ point of view this seems to me like an implementation detail for
the zero-overhead deterministic exceptions, rather than actual language
specification. I'd rather see an actual implementation, than a
specification that we don't know if it works. Only when you try to
implement something, you will notice all the details you are probably
missing now.

From C point of view, you are proposing a new feature, a new way of error
handing in C, that is also very similar to the zero-overhead deterministic
exceptions. Then you propose some compatibility between your C proposal and
the C++ zero-overhead deterministic exception.

The question is, why would you want to bring in a C++ feature into C?
Should we maybe try to map C++ classes and polymorphism and templates into
C features?

Compatibility comes in two ways, calling C++ code from C, and calling C
code from C++. Lets look at them.


   1. Calling C++ code from C is done by creating wrapper C++ functions
   that hide all the C++ features (only use C types), and then we expose these
   functions via C compatible header and with the extern "C" stuff. With this
   proposal this will continue to be this way.
   2. Calling C code from C++ comes (mostly) out of the box. Now lets say
   this proposal gets accepted into C. To get out of the box support for C
   code, in C++ _Fails, _Either have to be copied into C++ specs too. Now
   let's say zero-overhead deterministic exceptions get into C++. Now we have
   two syntaxes for the same feature. I don't like that. And maybe a third
   syntax will be needed to create the mappings.


On Wednesday, August 8, 2018 at 9:56:47 PM UTC+2, Niall Douglas wrote:
>
> Please find attached draft 4 of the previous C _Either(A, B) paper, with
> this edition completely rearchitected to meet WG14 feedback. It is very
> different from the C _Either proposal sent here earlier.
>
> Changes since draft 3:
>
>    - Dropped section on Rust for brevity.
>    - Rebased onto _Fails syntax as per advice from the WG14 reflector.
>    - Converted _Either(A, B) from a meta-type into an ordinary sum type
>    as per WG14 reflector suggestion.
>    - Added _Fails(errno) to solve the errno impurity problem as suggested
>    by the WG14 reflector.
>
> I'm hoping that this draft strongly resembles the final paper to be
> submitted for Pittsburgh and San Diego, but we'll see what you make of it.
>
> I'm also going to send this draft to the Austin Working Group for
> feedback, as I promised WG14 that I would do.
>
> Thanks in advance for any comments.
>
> 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/b955a733-faf1-412c-a99a-89c54083bc2a%40isocpp.org.

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

<div dir=3D"ltr"><div>From C++ point of view this seems to me like an imple=
mentation detail for the zero-overhead deterministic exceptions, rather tha=
n actual language specification. I&#39;d rather see an actual implementatio=
n, than a specification that we don&#39;t know if it works. Only when you t=
ry to implement something, you will notice all the details you are probably=
 missing now.</div><div><br></div><div>From C point of view, you are propos=
ing a new feature, a new way of error handing in C, that is also very simil=
ar to the zero-overhead deterministic exceptions. Then you propose some com=
patibility between your C proposal and the C++ zero-overhead deterministic =
exception.</div><div><br></div><div>The question is, why would you want to =
bring in a C++ feature into C? Should we maybe try to map C++ classes and p=
olymorphism and templates into C features?</div><div><br></div><div>Compati=
bility comes in two ways, calling C++ code from C, and calling C code from =
C++. Lets look at them.</div><div><br></div><ol><li>Calling C++ code from C=
 is done by creating wrapper C++ functions that hide all the C++ features (=
only use C types), and then we expose these functions via C compatible head=
er and with the extern &quot;C&quot; stuff. With this proposal this will co=
ntinue to be this way.</li><li>Calling C code from C++ comes (mostly) out o=
f the box. Now lets say this proposal gets accepted into C. To get out of t=
he box support for C code, in C++ _Fails, _Either have to be copied into C+=
+ specs too. Now let&#39;s say zero-overhead deterministic exceptions get i=
nto C++. Now we have two syntaxes for the same feature. I don&#39;t like th=
at. And maybe a third syntax will be needed to create the mappings.<br></li=
></ol><br>On Wednesday, August 8, 2018 at 9:56:47 PM UTC+2, Niall Douglas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Ple=
ase find attached draft 4 of the previous C _Either(A, B) paper, with this =
edition completely rearchitected to meet WG14 feedback. It is very differen=
t from the C _Either proposal sent here earlier.</div><div><br></div><div>C=
hanges since draft 3:</div><div><ul><li>Dropped section on Rust for brevity=
..</li><li>Rebased onto _Fails syntax as per advice from the WG14 reflector.=
</li><li>Converted _Either(A, B) from a meta-type into an ordinary sum type=
 as per WG14 reflector suggestion.</li><li>Added _Fails(errno) to solve the=
 errno impurity problem as suggested by the WG14 reflector.</li></ul></div>=
<div>I&#39;m hoping that this draft strongly resembles the final paper to b=
e submitted for Pittsburgh and San Diego, but we&#39;ll see what you make o=
f it.</div><div><br></div><div>I&#39;m also going to send this draft to the=
 Austin Working Group for feedback, as I promised WG14 that I would do.</di=
v><div><br></div><div>Thanks in advance for any comments.</div><div><br></d=
iv><div>Niall</div><div><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/b955a733-faf1-412c-a99a-89c54083bc2a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b955a733-faf1-412c-a99a-89c54083bc2a=
%40isocpp.org</a>.<br />

------=_Part_763_113070160.1533896576633--

------=_Part_762_1402125512.1533896576633--

.

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

On Fri, 10 Aug 2018, 11:22 Dimitrij Mijoski, <dim.mj.p@gmail.com> wrote:

> From C point of view, you are proposing a new feature, a new way of error
> handing in C, that is also very similar to the zero-overhead deterministic
> exceptions. Then you propose some compatibility between your C proposal and
> the C++ zero-overhead deterministic exception.
>

> The question is, why would you want to bring in a C++ feature into C?
>

The question is, as far as I'm concerned, Why wouldn't you?

We are both facing a problem with error handling. The C approach doesn't
scale, and the C++ approach is inefficient. So it is a known problem in
both languages, for different reasons.

If you have to work with some C library in a C++ setting (e.g. sockets),
you notice that your code becomes rather messy. Half of your code is just
in trying to catch errors in C and convert them into a format suitable for
a C++ user (the other half is declaring would-be-temporaries just so that C
functions can accept them as pointers). C handling errors in a sane way
would easily cut my signalling codebase in half.

We can't have exactly the same syntax, particularly because we have access
to nicer syntax and want to keep it that way. We also have different
conventions, and I don't want to be adopting C's.

We also have a lot of shared functionality. Our math libraries, for
example, are (though implementation defined) identical except for
namespacing, and the errno setting in C prevents constexpr math. We could
either branch off and make the two languages incompatible, or unify the
approach to allow the communities to work together.

A unified approach is easier for both to work with, and makes it easier on
C++ programmers who want to interface with C. Low latency developers in
particular will love that - and that's why SG14 is involved.

--
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%2B0CCOjkG7WBLCjbLp-TSN6cxP49GpRT3%2Bd%3D3p6w27eu5JLuA%40mail.gmail.com.

--000000000000e14913057312939f
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 Fri, =
10 Aug 2018, 11:22 Dimitrij Mijoski, &lt;<a href=3D"mailto:dim.mj.p@gmail.c=
om" rel=3D"noreferrer noreferrer" target=3D"_blank">dim.mj.p@gmail.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Fr=
om C point of view, you are proposing a new feature, a new way of error han=
ding in C, that is also very similar to the zero-overhead deterministic exc=
eptions. Then you propose some compatibility between your C proposal and th=
e C++ zero-overhead deterministic exception.</div></div></blockquote></div>=
</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><br></div><div>The question is, why would you =
want to bring in a C++ feature into C?</div></div></blockquote></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">The question is, as far as I&=
#39;m concerned, Why wouldn&#39;t you?</div><div dir=3D"auto"></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">We are both facing a problem with er=
ror handling. The C approach doesn&#39;t scale, and the C++ approach is ine=
fficient. So it is a known problem in both languages, for different reasons=
..</div><div dir=3D"auto"><br></div><div dir=3D"auto">If you have to work wi=
th some C library in a C++ setting (e.g. sockets), you notice that your cod=
e becomes rather messy. Half of your code is just in trying to catch errors=
 in C and convert them into a format suitable for a C++ user (the other hal=
f is declaring would-be-temporaries just so that C functions can accept the=
m as pointers). C handling errors in a sane way would easily cut my signall=
ing codebase in half.</div><div dir=3D"auto"><br></div><div dir=3D"auto">We=
 can&#39;t have exactly the same syntax, particularly because we have acces=
s to nicer syntax and want to keep it that way. We also have different conv=
entions, and I don&#39;t want to be adopting C&#39;s.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">We also have a lot of shared functionality. O=
ur math libraries, for example, are (though implementation defined) identic=
al except for namespacing, and the errno setting in C prevents constexpr ma=
th. We could either branch off and make the two languages incompatible, or =
unify the approach to allow the communities to work together.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">A unified approach is easier for both=
 to work with, and makes it easier on C++ programmers who want to interface=
 with C. Low latency developers in particular will love that - and that&#39=
;s why SG14 is involved.</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%2B0CCOjkG7WBLCjbLp-TSN6cxP49GpRT3=
%2Bd%3D3p6w27eu5JLuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOj=
kG7WBLCjbLp-TSN6cxP49GpRT3%2Bd%3D3p6w27eu5JLuA%40mail.gmail.com</a>.<br />

--000000000000e14913057312939f--

.

------=_Part_719_536551945.1533899543050
Content-Type: multipart/alternative;
 boundary="----=_Part_720_201459989.1533899543050"

------=_Part_720_201459989.1533899543050
Content-Type: text/plain; charset="UTF-8"

Error handing is not the only problem in C. It has a weak type system, so
maybe try to bring the C++ type system into C? C memory management is all
manual, so maybe bring RAII into C?

Or just stop using C and start using C++. In your example, just start using
a C++ socket library in the first place. There are plenty of them.

On Friday, August 10, 2018 at 12:55:12 PM UTC+2, Jake Arkinstall wrote:
>
> The question is, as far as I'm concerned, Why wouldn't you?
>
> We are both facing a problem with error handling. The C approach doesn't
> scale, and the C++ approach is inefficient. So it is a known problem in
> both languages, for different reasons.
>
> If you have to work with some C library in a C++ setting (e.g. sockets),
> you notice that your code becomes rather messy.
>

--
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/f28d49d4-872f-4c23-bfae-23e1e45e1bca%40isocpp.org.

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

<div dir=3D"ltr"><div>Error handing is not the only problem in C. It has a =
weak type=20
system, so maybe try to bring the C++ type system into C? C memory=20
management is all manual, so maybe bring RAII into C?</div><div><br></div><=
div>Or just stop using C and start using C++. In your example, just start u=
sing a C++ socket library in the first place. There are plenty of them.<br>=
</div><br>On Friday, August 10, 2018 at 12:55:12 PM UTC+2, Jake Arkinstall =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div d=
ir=3D"auto"></div><div dir=3D"auto">The question is, as far as I&#39;m conc=
erned, Why wouldn&#39;t you?</div><div dir=3D"auto"></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">We are both facing a problem with error handli=
ng. The C approach doesn&#39;t scale, and the C++ approach is inefficient. =
So it is a known problem in both languages, for different reasons.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">If you have to work with some C =
library in a C++ setting (e.g. sockets), you notice that your code becomes =
rather messy.</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/f28d49d4-872f-4c23-bfae-23e1e45e1bca%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f28d49d4-872f-4c23-bfae-23e1e45e1bca=
%40isocpp.org</a>.<br />

------=_Part_720_201459989.1533899543050--

------=_Part_719_536551945.1533899543050--

.

------=_Part_661_1625435375.1533899558913
Content-Type: multipart/alternative;
 boundary="----=_Part_662_2097901046.1533899558914"

------=_Part_662_2097901046.1533899558914
Content-Type: text/plain; charset="UTF-8"

Some small comments:

1. The names left and right are not descriptive for their uses. I would
prefer expected and unexpected or value and error or something like that.

2. The abs() example has a few flaws.
   a) The value returned when errno is set is 0 for the original code and
INT_MIN for the rewritten version which is confusing.
   b) The proposed rewrite from a setting of errno + a return statement to
a return _Failure() seems scary as the programmer may insert some other
code between the errno setting and the return statement.
   c) The code that shows the call site for the abs() example is not
equivalent to the original as the function may set errno to 0, which is
taken as no error by the original code but is still not "positive" by the
new means.
       Upon further inspection it may be that this feature is just not
explained clearly enough. I think your intention is that within a
_Fails(errno) marked function errno is a local variable. If it is non-zero
when a return statement is hit the transformation occurs.
       This seems to work better than my initial understanding that it is
the code pattern of setting errno followed by return that is transformed.
   d) It is unclear to me what happens if errno is already != 0 when abs()
is called. To get backwards compatibility it seems logical that the local
errno gets set from the threadlocal errno when abs is entered. If this is
the case, please show how the expression:
       abs(a) + abs(b) is translated (with the problem being that if abs(a)
lazily returns an error then abs(b)'s initing of its errno would use a
stale value).

3. In your last C example it is unclear if the code is the user written
code or the compiler rewrite, and in the latter case if the user had a
errno = 0 statement at all.




Den onsdag 8 augusti 2018 kl. 21:56:47 UTC+2 skrev Niall Douglas:
>
> Please find attached draft 4 of the previous C _Either(A, B) paper, with
> this edition completely rearchitected to meet WG14 feedback. It is very
> different from the C _Either proposal sent here earlier.
>
> Changes since draft 3:
>
>    - Dropped section on Rust for brevity.
>    - Rebased onto _Fails syntax as per advice from the WG14 reflector.
>    - Converted _Either(A, B) from a meta-type into an ordinary sum type
>    as per WG14 reflector suggestion.
>    - Added _Fails(errno) to solve the errno impurity problem as suggested
>    by the WG14 reflector.
>
> I'm hoping that this draft strongly resembles the final paper to be
> submitted for Pittsburgh and San Diego, but we'll see what you make of it.
>
> I'm also going to send this draft to the Austin Working Group for
> feedback, as I promised WG14 that I would do.
>
> Thanks in advance for any comments.
>
> 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/05e6c694-3efe-4caa-8557-0edd07bc0c5f%40isocpp.org.

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

<div dir=3D"ltr">Some small comments:<div><br></div><div>1. The names left =
and right are not descriptive for their uses. I would prefer expected and u=
nexpected or value and error or something like that.</div><div><br></div><d=
iv>2. The abs() example has a few flaws.</div><div>=C2=A0 =C2=A0a) The valu=
e returned when errno is set is 0 for the original code and INT_MIN for the=
 rewritten version which is confusing.</div><div>=C2=A0 =C2=A0b) The propos=
ed rewrite from a setting of errno + a return statement to a return _Failur=
e() seems scary as the programmer may insert some other code between the er=
rno setting and the return statement.</div><div>=C2=A0 =C2=A0c) The code th=
at shows the call site for the abs() example is not equivalent to the origi=
nal as the function may set errno to 0, which is taken as no error by the o=
riginal code but is still not &quot;positive&quot; by the new means.</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0Upon further inspection it may be that this =
feature is just not explained clearly enough. I think your intention is tha=
t within a _Fails(errno) marked function errno is a local variable. If it i=
s non-zero when a return statement is hit the transformation occurs.</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0This seems to work better than my initial un=
derstanding that it is the code pattern of setting errno followed by return=
 that is transformed.</div><div>=C2=A0 =C2=A0d) It is unclear to me what ha=
ppens if errno is already !=3D 0 when abs() is called. To get backwards com=
patibility it seems logical that the local errno gets set from the threadlo=
cal errno when abs is entered. If this is the case, please show how the exp=
ression:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0abs(a) + abs(b) is translated=
 (with the problem being that if abs(a) lazily returns an error then abs(b)=
&#39;s initing of its errno would use a stale value).</div><div><br></div><=
div>3. In your last C example it is unclear if the code is the user written=
 code or the compiler rewrite, and in the latter case if the user had a err=
no =3D 0 statement at all.</div><div><br></div><div><br></div><div><br><br>=
Den onsdag 8 augusti 2018 kl. 21:56:47 UTC+2 skrev Niall Douglas:<blockquot=
e 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>Please find attach=
ed draft 4 of the previous C _Either(A, B) paper, with this edition complet=
ely rearchitected to meet WG14 feedback. It is very different from the C _E=
ither proposal sent here earlier.</div><div><br></div><div>Changes since dr=
aft 3:</div><div><ul><li>Dropped section on Rust for brevity.</li><li>Rebas=
ed onto _Fails syntax as per advice from the WG14 reflector.</li><li>Conver=
ted _Either(A, B) from a meta-type into an ordinary sum type as per WG14 re=
flector suggestion.</li><li>Added _Fails(errno) to solve the errno impurity=
 problem as suggested by the WG14 reflector.</li></ul></div><div>I&#39;m ho=
ping that this draft strongly resembles the final paper to be submitted for=
 Pittsburgh and San Diego, but we&#39;ll see what you make of it.</div><div=
><br></div><div>I&#39;m also going to send this draft to the Austin Working=
 Group for feedback, as I promised WG14 that I would do.</div><div><br></di=
v><div>Thanks in advance for any comments.</div><div><br></div><div>Niall</=
div><div><br></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/05e6c694-3efe-4caa-8557-0edd07bc0c5f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/05e6c694-3efe-4caa-8557-0edd07bc0c5f=
%40isocpp.org</a>.<br />

------=_Part_662_2097901046.1533899558914--

------=_Part_661_1625435375.1533899558913--

.

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

On Fri, 10 Aug 2018, 12:12 Dimitrij Mijoski, <dim.mj.p@gmail.com> wrote:

> Or just stop using C and start using C++. In your example, just start
> using a C++ socket library in the first place. There are plenty of them.
>

And they wrap the C sockets library provided by the operating system. Sure,
the wrappers provide a friendlier interface, but while the error handling
approaches remain inconsistent there is still SOMEONE putting in all the
effort to handle C with C++. If you're in an environment where latency
correlates with financial loss, you are unlikely to use boost::asio
(fantastic as a library as it is).

I'd love it if there was a widely used operating system designed
specifically for C++-like access to low level functionality, but while we
have Unix-like systems and windows, we interface with the OS in C.

(Though I do realise the main gotcha here - those low level C libraries
won't be changing any time soon)

--
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%2B0CCNYrgEdAy42WKUKwaEPeDdewZVexw9Og4X5iK04pmk5UA%40mail.gmail.com.

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

<div dir=3D"auto"><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"l=
tr">On Fri, 10 Aug 2018, 12:12 Dimitrij Mijoski, &lt;<a href=3D"mailto:dim.=
mj.p@gmail.com">dim.mj.p@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>Or just stop using C and start using C=
++. In your example, just start using a C++ socket library in the first pla=
ce. There are plenty of them.<br></div></div></blockquote></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">And they wrap the C sockets library prov=
ided by the operating system. Sure, the wrappers provide a friendlier inter=
face, but while the error handling approaches remain inconsistent there is =
still SOMEONE putting in all the effort to handle C with C++. If you&#39;re=
 in an environment where latency correlates with financial loss, you are un=
likely to use boost::asio (fantastic as a library as it is).</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I&#39;d love it if there was a widely=
 used operating system designed specifically for C++-like access to low lev=
el functionality, but while we have Unix-like systems and windows, we inter=
face with the OS in C.</div><div dir=3D"auto"><br></div><div dir=3D"auto">(=
Though I do realise the main gotcha here - those low level C libraries won&=
#39;t be changing any time soon)</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%2B0CCNYrgEdAy42WKUKwaEPeDdewZVexw=
9Og4X5iK04pmk5UA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYrgEd=
Ay42WKUKwaEPeDdewZVexw9Og4X5iK04pmk5UA%40mail.gmail.com</a>.<br />

--0000000000009d5d6b0573134918--

.

------=_Part_692_2026287803.1533901767503
Content-Type: multipart/alternative;
 boundary="----=_Part_693_1288277781.1533901767503"

------=_Part_693_1288277781.1533901767503
Content-Type: text/plain; charset="UTF-8"



On Friday, August 10, 2018 at 10:34:30 AM UTC+2, Niall Douglas wrote:
>
> Just to keep everybody on WG21 up to date, WG14 likes this proposal a lot,
> and apart from the .left, .right and .positive being replaced with
> _EitherValue(), _EitherError() and _EitherHasValue(), the above is
> essentially the paper to be published.
>
> Obviously if you have any additional feedback, please send it.
>
> Niall
>

If C++ provide some interface for C, then C could start and end C++
exceptions.  This could be useful when C do not want propagate exception in
some cases. Each exception will need its own function that do it. From C++
perspective implementation will be simple: `(*ptr).~T();`

How `std::uncaught_exceptions` will exactly work with value exception? You
mentioned overhead of cold cache, but it will be implemented in this or
this is thing you want avoid?
Maybe give programmers direct access to this? 99% of code could live with
this overhead other probably not.
It would see 3 functions:
std::uncaught_exceptions_inc();
std::uncaught_exceptions_dec();
std::uncaught_exceptions_set_abort(+[]{ std::abort(); });

Each value exception need call `inc` in constructor and `dec` in destructor
of not moved out object. Or you set `set_abort` (per thread) that will
prevent incorrect use of `uncaught_exceptions` in scope guards. With this
allow you to skip `inc` and `dec` in your value exceptions. This could be
done locally. Rest of code will correctly use `uncaught_exceptions` and
some part where performance is required you prevent use of this.
It could work other way around, you disable this globally but enable it
back for some external library calls that use `uncaught_exceptions`
internally.



--
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/ceaef357-0080-4d44-910d-8728fed9c8b8%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, August 10, 2018 at 10:34:30 AM UTC+2, N=
iall 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">Just to keep everybody on WG21 up to date, WG14 likes this proposal a=
 lot, and apart from the .left, .right and .positive being replaced with _E=
itherValue(), _EitherError() and _EitherHasValue(), the above is essentiall=
y the paper to be published.<div><br></div><div>Obviously if you have any a=
dditional feedback, please send it.</div><div><br></div><div>Niall</div></d=
iv></blockquote><div><div><br></div><div>If C++ provide some interface for =
C, then C could=20
start and end C++ exceptions.=C2=A0 This could be useful when C do not want=
=20
propagate exception in some cases. Each exception will need its own=20
function that do it. From C++ perspective implementation will be simple:
 `(*ptr).~T();`</div><div><br></div><div>How `std::uncaught_exceptions`=20
will exactly work with value exception? You mentioned overhead of cold=20
cache, but it will be implemented in this or this is thing you want=20
avoid?</div><div>Maybe give programmers direct access to this? 99% of code =
could live with this overhead other probably not.</div><div>It would see 3 =
functions:</div><div><div style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; ove=
rflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">un=
caught_exceptions_inc</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">uncaugh=
t_exceptions_dec</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">uncaught_exc=
eptions_set_abort</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(+[]{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">abort</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">});</span></div></code></div></di=
v><div><br></div><div>Each value exception need call `inc` in constructor a=
nd `dec` in destructor of not moved out object. Or you set `set_abort` (per=
 thread) that will prevent incorrect use of `uncaught_exceptions` in scope =
guards. With this <br>allow you to skip `inc` and `dec` in your value excep=
tions. This could be done locally. Rest of code will correctly use `uncaugh=
t_exceptions` and some part where performance is required you prevent use o=
f this.</div><div>It could work other way around, you disable this globally=
 but enable it back for some external library calls that use `uncaught_exce=
ptions` internally.<br></div><div><br></div>=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/ceaef357-0080-4d44-910d-8728fed9c8b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ceaef357-0080-4d44-910d-8728fed9c8b8=
%40isocpp.org</a>.<br />

------=_Part_693_1288277781.1533901767503--

------=_Part_692_2026287803.1533901767503--

.

On 08/10/2018 09:34 AM, Niall Douglas wrote:
> Just to keep everybody on WG21 up to date, WG14 likes this proposal a lot, and apart from the .left, .right and .positive being replaced with _EitherValue(), _EitherError() and _EitherHasValue(), the above is essentially the paper to be published.
>
> Obviously if you have any additional feedback, please send it.

I understand you're aiming at absolute minimum to improve chances
of success, but I wonder whether there is any plan to later on add
an stdbool.h-like header that gives these new symbols prettier
non-_Uppercase (non-implementation-reserved) names, like:

 #define fails _Fails
 #define try _Try
 #define catch _Catch
 #define failure _Failure
 #define either _Either
 ...
 etc.

?

It feels like if the proposal succeeds, this new failure mechanism
will be used pervasively, and people will quickly get bored with
typing all that _Uppercasing for such a core feature, and
projects will grow such defines themselves.

With that, for mixed C and C++ codebases, and for ease of
codebase migration from C to C++, it'd be ideal if C code using
the prettified "try" and "catch" could compile with a C++
compiler.  I'm not sure that would be possible.  Seems worth
it to me to aim at making this path down the road possible.
I was a bit surprised to not see this discussed in the paper.

Your example in the paper would read instead:

 #include <stdwhatever.h>

 int some_function(int x) fails(float)
 {
   return (x != 0) ? 5 : failure(2.0);
 }

 const char *some_other_function(int x) fails(float)
 {
   int v = try(some_function(x));
   return (v == 5) ? "Yes" : "No";
 }

 int main(int argc, char *argv[])
 {
   if(argc < 2)
     abort();
   either(const char *, float) v = catch(some_other_function(atoi(argv[1])));
   if(v.positive)
   {
     printf("v is a successful %s\n", v.left);
   }
   else
   {
     printf("v is failure %f\n", v.right);
   }
   return 0;
 }

Thanks,
Pedro Alves

--
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/4b4cdf3c-d7aa-b0d1-6c10-e309e018084c%40palves.net.

.

------=_Part_1253_1258095478.1534099844585
Content-Type: multipart/alternative;
 boundary="----=_Part_1254_349956525.1534099844585"

------=_Part_1254_349956525.1534099844585
Content-Type: text/plain; charset="UTF-8"

On Friday, August 10, 2018 at 11:22:56 AM UTC+1, Dimitrij Mijoski wrote:
>
> From C++ point of view this seems to me like an implementation detail for
> the zero-overhead deterministic exceptions, rather than actual language
> specification. I'd rather see an actual implementation, than a
> specification that we don't know if it works. Only when you try to
> implement something, you will notice all the details you are probably
> missing now.
>
>>
>> A major compiler vendor intends to implement P0709 by early 2019.

The papers forming this discussion is to set the general approach any
prototype should take.

Regarding better type interop between C and C++, well baby steps first.
Let's solve the exception throwing interop problem, and move on from there.
I would also add that there are languages which only speak C, but have much
better interop with C++'s richer type system.

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/e2c2c74f-a9e0-42ae-90f3-606e8d2b9325%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 10, 2018 at 11:22:56 AM UTC+1, Dimitrij =
Mijoski wrote:<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>From C++ point of view this seems to me like an implementation detail=
 for the zero-overhead deterministic exceptions, rather than actual languag=
e specification. I&#39;d rather see an actual implementation, than a specif=
ication that we don&#39;t know if it works. Only when you try to implement =
something, you will notice all the details you are probably missing now.</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>=
</div></blockquote></div></blockquote><div>A major compiler vendor intends =
to implement P0709 by early 2019.</div><div><br></div><div>The papers formi=
ng this discussion is to set the general approach any prototype should take=
..</div><div><br></div><div>Regarding better type interop between C and C++,=
 well baby steps first. Let&#39;s solve the exception throwing interop prob=
lem, and move on from there. I would also add that there are languages whic=
h only speak C, but have much better interop with C++&#39;s richer type sys=
tem.</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/e2c2c74f-a9e0-42ae-90f3-606e8d2b9325%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e2c2c74f-a9e0-42ae-90f3-606e8d2b9325=
%40isocpp.org</a>.<br />

------=_Part_1254_349956525.1534099844585--

------=_Part_1253_1258095478.1534099844585--

.

------=_Part_1238_129812676.1534111960377
Content-Type: multipart/alternative;
 boundary="----=_Part_1239_1512024551.1534111960377"

------=_Part_1239_1512024551.1534111960377
Content-Type: text/plain; charset="UTF-8"


>
>
> 1. The names left and right are not descriptive for their uses. I would
> prefer expected and unexpected or value and error or something like that.
>

Already changed to _EitherValue() and _EitherError().


>    b) The proposed rewrite from a setting of errno + a return statement to
> a return _Failure() seems scary as the programmer may insert some other
> code between the errno setting and the return statement.
>

Optimisation already significantly rewrites the programmer's code.
Everything is "as if" nowadays.


>    c) The code that shows the call site for the abs() example is not
> equivalent to the original as the function may set errno to 0, which is
> taken as no error by the original code but is still not "positive" by the
> new means.
>        Upon further inspection it may be that this feature is just not
> explained clearly enough. I think your intention is that within a
> _Fails(errno) marked function errno is a local variable. If it is non-zero
> when a return statement is hit the transformation occurs.
>        This seems to work better than my initial understanding that it is
> the code pattern of setting errno followed by return that is transformed.
>

Correct, real errno becomes exclusively the compiler's responsibility when
calling a _FailsWithErrno function.


>    d) It is unclear to me what happens if errno is already != 0 when abs()
> is called. To get backwards compatibility it seems logical that the local
> errno gets set from the threadlocal errno when abs is entered. If this is
> the case, please show how the expression:
>        abs(a) + abs(b) is translated (with the problem being that if
> abs(a) lazily returns an error then abs(b)'s initing of its errno would use
> a stale value).
>

If you declare your function _FailsWithErrno, it needs to be ported to the
new system. Specifically, that you can't read errno. Trying to do so fails
the compile.

For code which calls a _FailsWithErrno function, we know such functions
never read errno, but they as-if may set it. The compiler optimises
accordingly.


>
> 3. In your last C example it is unclear if the code is the user written
> code or the compiler rewrite, and in the latter case if the user had a
> errno = 0 statement at all.
>

I will clarify the wording and spell out why and how statements were elided
by the compiler due to having no possible side effect.

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/eba9269f-99e8-4ed5-86ad-c05512e56f9e%40isocpp.org.

------=_Part_1239_1512024551.1534111960377
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>1. The names left and right are not descriptive for=
 their uses. I would prefer expected and unexpected or value and error or s=
omething like that.</div></div></blockquote><div><br></div><div>Already cha=
nged to _EitherValue() and _EitherError().</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;"><div dir=3D"ltr"><div>=C2=A0 =C2=A0b) Th=
e proposed rewrite from a setting of errno + a return statement to a return=
 _Failure() seems scary as the programmer may insert some other code betwee=
n the errno setting and the return statement.<br></div></div></blockquote><=
div><br></div><div>Optimisation already significantly rewrites the programm=
er&#39;s code. Everything is &quot;as if&quot; nowadays.</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></di=
v><div>=C2=A0 =C2=A0c) The code that shows the call site for the abs() exam=
ple is not equivalent to the original as the function may set errno to 0, w=
hich is taken as no error by the original code but is still not &quot;posit=
ive&quot; by the new means.</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0Upon furth=
er inspection it may be that this feature is just not explained clearly eno=
ugh. I think your intention is that within a _Fails(errno) marked function =
errno is a local variable. If it is non-zero when a return statement is hit=
 the transformation occurs.</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0This seems=
 to work better than my initial understanding that it is the code pattern o=
f setting errno followed by return that is transformed.</div></div></blockq=
uote><div><br></div><div>Correct, real errno becomes exclusively the compil=
er&#39;s responsibility when calling a _FailsWithErrno function.</div><div>=
=C2=A0</div><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"><=
div>=C2=A0 =C2=A0d) It is unclear to me what happens if errno is already !=
=3D 0 when abs() is called. To get backwards compatibility it seems logical=
 that the local errno gets set from the threadlocal errno when abs is enter=
ed. If this is the case, please show how the expression:</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0abs(a) + abs(b) is translated (with the problem being t=
hat if abs(a) lazily returns an error then abs(b)&#39;s initing of its errn=
o would use a stale value).</div></div></blockquote><div><br></div><div>If =
you declare your function _FailsWithErrno, it needs to be ported to the new=
 system. Specifically, that you can&#39;t read errno. Trying to do so fails=
 the compile.</div><div><br></div><div>For code which calls a _FailsWithErr=
no function, we know such functions never read errno, but they as-if may se=
t it. The compiler optimises accordingly.</div><div>=C2=A0</div><blockquote=
 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"><div><br></div><div>3. I=
n your last C example it is unclear if the code is the user written code or=
 the compiler rewrite, and in the latter case if the user had a errno =3D 0=
 statement at all.</div></div></blockquote><div><br></div><div>I will clari=
fy the wording and spell out why and how statements were elided by the comp=
iler due to having no possible side effect.</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/eba9269f-99e8-4ed5-86ad-c05512e56f9e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eba9269f-99e8-4ed5-86ad-c05512e56f9e=
%40isocpp.org</a>.<br />

------=_Part_1239_1512024551.1534111960377--

------=_Part_1238_129812676.1534111960377--

.

------=_Part_1315_399442818.1534112356145
Content-Type: multipart/alternative;
 boundary="----=_Part_1316_1255740024.1534112356146"

------=_Part_1316_1255740024.1534112356146
Content-Type: text/plain; charset="UTF-8"


>
>
> How `std::uncaught_exceptions` will exactly work with value exception? You
> mentioned overhead of cold cache, but it will be implemented in this or
> this is thing you want avoid?
>
> Me personally, I'd like std::uncaught_exceptions to apply to type-based
exception throws only, and not drag down all value-based exception throws
with latency just for the 0.01% of users which ever use
std::uncaught_exceptions. It could maybe be enabled with a compiler option.

But assuming WG21 won't go for that, my proposal is that the TLS reference
counting only apply to std::error, it is not available under Freestanding
C++, and can be disabled at the command line.

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/0ecc7780-0359-460f-9ff0-7ab722658790%40isocpp.org.

------=_Part_1316_1255740024.1534112356146
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>How `std::uncaught_exceptions`=20
will exactly work with value exception? You mentioned overhead of cold=20
cache, but it will be implemented in this or this is thing you want=20
avoid?</div><div><br></div></div></blockquote><div>Me personally, I&#39;d l=
ike std::uncaught_exceptions to apply to type-based exception throws only, =
and not drag down all value-based exception throws with latency just for th=
e 0.01% of users which ever use std::uncaught_exceptions. It could maybe be=
 enabled with a compiler option.</div><div><br></div><div>But assuming WG21=
 won&#39;t go for that, my proposal is that the TLS reference counting only=
 apply to std::error, it is not available under Freestanding C++, and can b=
e disabled at the command line.</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/0ecc7780-0359-460f-9ff0-7ab722658790%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ecc7780-0359-460f-9ff0-7ab722658790=
%40isocpp.org</a>.<br />

------=_Part_1316_1255740024.1534112356146--

------=_Part_1315_399442818.1534112356145--

.

------=_Part_1311_1737833532.1534112452184
Content-Type: multipart/alternative;
 boundary="----=_Part_1312_27603283.1534112452184"

------=_Part_1312_27603283.1534112452184
Content-Type: text/plain; charset="UTF-8"


>
> I understand you're aiming at absolute minimum to improve chances
> of success, but I wonder whether there is any plan to later on add
> an stdbool.h-like header that gives these new symbols prettier
> non-_Uppercase (non-implementation-reserved) names, like:
>
> WG14 already has bikeshedded on such a suite of said macros.

So tldr yes that's exactly what would happen, if this proposal gets any
steam. Nobody would be writing underscoreCapital anything.

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/4872a523-c8fa-478b-8c57-30db2836d877%40isocpp.org.

------=_Part_1312_27603283.1534112452184
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;">I understand =
you&#39;re aiming at absolute minimum to improve chances
<br>of success, but I wonder whether there is any plan to later on add
<br>an stdbool.h-like header that gives these new symbols prettier
<br>non-_Uppercase (non-implementation-reserved) names, like:
<br><br></blockquote><div>WG14 already has bikeshedded on such a suite of s=
aid macros.</div><div><br></div><div>So tldr yes that&#39;s exactly what wo=
uld happen, if this proposal gets any steam. Nobody would be writing unders=
coreCapital anything.</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/4872a523-c8fa-478b-8c57-30db2836d877%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4872a523-c8fa-478b-8c57-30db2836d877=
%40isocpp.org</a>.<br />

------=_Part_1312_27603283.1534112452184--

------=_Part_1311_1737833532.1534112452184--

.