'unwrap envy' and exceptions

[Paulo Pinto]

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.