On Thursday, 24 February 2022 at 08:08:49 UTC, Paulo Pinto wrote:
>
> They aren't going anywhere, most of Herb's latest papers seem like ideas how the language could be improved upon, but beyond the original paper, presentation at CppCon and eventually some prototype available on Compiler Explorer, little more has happened.
>
> I might be wrong here, but from C++ mailings it is clear nothing is happening with those papers.
>
> Also in regards to exceptions, Bjarne has a paper where he criticizes the current compiler implementations for leaving performance improvements on the table by not wanting to break existing ABIs, while arguing against Herb's approach.
>
> "C++ exceptions and alternatives"
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf

That's a problem for D because I suggest that we copy whatever C++ decides to implement. The reason is that the solution is probably going to be good enough for D. Using the C++ solution also ensures FFI compatibility. Associated with the new C++ error handling is going to be an ABI change (for every CPU architecture) and that the D project would create its own bespoke ABI is a lot of work which might not play well with C++ or other SW.

On Thursday, 24 February 2022 at 00:19:44 UTC, meta wrote:
>> Support struct based exceptions (value type), passed on stack (and hence RC support) as part of the return value of a function.
>
>
> Who will allocates that (the RC part)?
>
> I personally disagree with the idea of exceptions altogether..
>
>
> The answer is in solutions like in Zig/Go, errors, multiple return values, if changing the way error handling works in D, better make it good, for good!

oh god, go code is so stupid to read b/c theres error handling everywhere mixed with code logic. i'm all for adding multiple return values, aka tuples, but exceptions are by far the best error handling method by readability. also you are forced to catch them and you got stack traces, which is super useful.


Zot

On Thursday, 24 February 2022 at 10:06:24 UTC, IGotD- wrote:
> On Thursday, 24 February 2022 at 08:08:49 UTC, Paulo Pinto wrote:
>>
>> They aren't going anywhere, most of Herb's latest papers seem like ideas how the language could be improved upon, but beyond the original paper, presentation at CppCon and eventually some prototype available on Compiler Explorer, little more has happened.
>>
>> I might be wrong here, but from C++ mailings it is clear nothing is happening with those papers.
>>
>> Also in regards to exceptions, Bjarne has a paper where he criticizes the current compiler implementations for leaving performance improvements on the table by not wanting to break existing ABIs, while arguing against Herb's approach.
>>
>> "C++ exceptions and alternatives"
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf
>
> That's a problem for D because I suggest that we copy whatever C++ decides to implement. The reason is that the solution is probably going to be good enough for D. Using the C++ solution also ensures FFI compatibility. Associated with the new C++ error handling is going to be an ABI change (for every CPU architecture) and that the D project would create its own bespoke ABI is a lot of work which might not play well with C++ or other SW.

Until ISO C++26, ISO C++ is definitly not deciding anything related to Herb's proposal, and it remains to be seen if there will be anything in a form of a proper ISO C++ feature proposal paper for post ISO C++26.

Waiting for C++ to decide anything is only detrimental for D.

On 24/02/2022 9:42 PM, Alexandru Ermicioi wrote:
> So why not have this implemented as underlying mechanism for existing try catch syntax, with option to choose which one to use?
> 
> If done so, there shouldn't be any usability downgrade, when selecting either existing or new exception mechanism, only distribution of performance overhead will change.

My concern is that there will be situations which no one can predict; exceptions are very hairy (after all, they can go up the chain of functions not written in D).

This is why I'm not suggesting that we should replace exception handling in the general case. Only where the compiler can see that it can be done (plus this can be improved over time).

On Thursday, 24 February 2022 at 11:07:31 UTC, rikki cattermole wrote:
>
> My concern is that there will be situations which no one can predict; exceptions are very hairy (after all, they can go up the chain of functions not written in D).
>
> This is why I'm not suggesting that we should replace exception handling in the general case. Only where the compiler can see that it can be done (plus this can be improved over time).

I think that exceptions work kind of well in a code cleanness kind of way. The proposal from Herb Sutter looks like exceptions but it is return values under the hood.

D also has the ingenious scope guards (scope(exit) and such) which work very well with exceptions. It would be bad if this would be thrown away with a new error handling mechanism. Therefore I think return values should also have the exception syntax.

On 25/02/2022 12:22 AM, IGotD- wrote:
> D also has the ingenious scope guards (scope(exit) and such) which work very well with exceptions. It would be bad if this would be thrown away with a new error handling mechanism. Therefore I think return values should also have the exception syntax.

Agreed, I didn't write it in my proposal earlier because nothing syntax wise would change for how you would use it.

The only difference is the @throws attribute as far as users are concerned and that has benefits by itself.