'unwrap envy' and exceptions

[rikki cattermole]

On 13/09/2021 3:53 AM, 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.

I recently posted a similar design here: 
https://forum.dlang.org/post/she82k$g31$1@digitalmars.com

A big difference between the one you linked and mine is the throws 
keyword takes the types that can be thrown. So an empty set of 
throwables, is the same as none being thrown.

The other difference is to recognize that it is not a return value, 
rather it is an out parameter instead that is hidden like this is. This 
allows for the purpose of playing nicely with existing code.