Possibility of adopting Rust's Error Handling?

[mee6]

On Thursday, 31 March 2022 at 21:46:53 UTC, IGotD- wrote:
> On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:
>> [...]
>
> There is a lot of influences from Rust right now but I think we 
> should be cautious adopting its features because I see more and 
> more that many of the features don't age well.
>
> What is Rust error handling? Rust error handling is basically a 
> tagged enum return type. Essentially it is a return value with 
> some extra language built in features (like the ? mentioned).
>
> Problem with the Rust error handling is that you must use the 
> same type for the entire call chain for it to work. Otherwise 
> you must convert the error type or use a generic trait which 
> dynamically allocated. Essentially you have the same problems 
> as you would with return values. Its just an inferior error 
> handling method compared to exceptions other than it might have 
> better for performance. Versatility always comes at a cost.
>
> If you compare this with exceptions, they are much more 
> versatile and the types can be infinitely expanded without even 
> converting or alter an existing interface.

Personally I think that's one of the reasons to not use it. 
Errors that are recoverable are finite. There's no good way to 
see exactly what it will throw. With return value handlingly you 
know exactly what you are getting. You could make it more generic 
or at multiple types. Errors shouldn't happen often and yes that 
would have to heap allocate but those are tradeoffs that can be 
looked over.


>  D has made exceptions even more convenient by adding scope 
> guard so it is really a part of the language.
>
> I think that exceptions are superior to return values for the 
> programmer. However there are performance bottlenecks. Instead 
> D should focus on how to improve its exceptions, like looking 
> if value exceptions could be beneficial, unnecessary locking, 
> if they can be stored temporarily on stack instead of heap, how 
> they can better work with the optimizer, include TypeInfo in 
> better C so that exceptions work there.

Both can exist together, you can have a library implementation of 
Result. The feature for it is aldo a small convince but 
ultimately isn't required to get the benefits of result value 
error handling.