On Sunday, 12 September 2021 at 15:53:16 UTC, IGotD- wrote:
> On Sunday, 12 September 2021 at 01:50:37 UTC, H. S. Teoh wrote:
>>
>> Whatever replaces exceptions better be darned good, otherwise I will be very unhappy.  Explicit exception handling has its place, but in other cases it just uglifies code for no good reason.  I don't really buy the performance argument: if your profiler pinpoints try/catch blocks as the bottleneck, it's not hard to refactor it to use error codes instead. Anything else is premature optimization.  We should not uglify code just for some idealism that exceptions are somehow "bad".
>>
>>
>> T
>
> What about the C++ approach, return values that look like exceptions.
>
> You probably have already seen it.
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf
>
> We are allowed to "steal" from C++ if it is any good. Also it can be good for interoperability.

That will probably never happen.

First, a prototype has been requested to prove the design, before going forward, so C++26 might be the next time they will actually look at it.

Secondly, Bjarne has written a rebutall that the biggest issue with exceptions is that compiler vendors just don't care to optimize the implementation, because of the usual ABI discussions,

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf

So I really don't expect this to ever be voted in into ISO C++, just like the reflection prototype and metaclasses proposals before it.

On Monday, 13 September 2021 at 06:05:47 UTC, Paulo Pinto wrote:
>
> That will probably never happen.
>
> First, a prototype has been requested to prove the design, before going forward, so C++26 might be the next time they will actually look at it.
>
> Secondly, Bjarne has written a rebutall that the biggest issue with exceptions is that compiler vendors just don't care to optimize the implementation, because of the usual ABI discussions,
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf
>
> So I really don't expect this to ever be voted in into ISO C++, just like the reflection prototype and metaclasses proposals before it.

That still doesn't prevent D from implementing the design. D can actually introduce it before C++.

Implementation wise it could be complicated for D. Usage wise it fits D quite well as you can still use the exception syntax with the convenient scope guards.

On Monday, 13 September 2021 at 05:56:18 UTC, Paulo Pinto wrote:
> Java throws statement was based on CLU, Modula-3 and C++, actually.
>
> Herb's idea is based on how Swift does exceptions, and ironically brings exception specifications back into C++, after their removal on C++17, just written in a different form.

Sorry, for confusion, I didn't refer to throws statement in body of a method, but rather throws statement in method declaration, used to list checked exceptions thrown by the method. I think they also can be called an exception specification.

They enforce the caller of method to handle those cases, while in C++ spec, the purpose is performance, and unification of error reporting format.