Possibility of adopting Rust's Error Handling?

[IGotD-]

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:
> Rust's error handling is pretty good, I think they've proved 
> the use of Result!(T, E). I was just always getting informative 
> messages from the get go. I think there's a @nogc exception DIP 
> in the works but I think this way of handling errors is better.
>
> I won't go too much into detail of rust as this website does a 
> good job of going over it.
>
> https://doc.rust-lang.org/book/ch09-00-error-handling.html
>
> Anyways this could be adopted instead of trying to get @nogc 
> exceptions working. Rust uses exceptions but only for panic!() 
> Which terminates the application. All it does is rewind the 
> stack to see all the function calls for debugging pretty much.
>
> I also think it works with chaining functions as that's what 
> Rust does a lot too. They have a `?` operator that does 
> basically this boiler plate code.
>
> ```d
> auto result = expr;
> if (result.isErr())
>     return result;
> ```
>
> D could implement this fairly easily and without much 
> intrusion, but it would add a lot of value to be able to do 
> something like:
>
> ```rust
> auto value = chain()?.funcs()?;
> ```
>
> While being @nogc and without using exceptions. Other than for 
> panics.

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. Exceptions in D use TypeInfo (or 
RTTI in C++) in order to determine the error type. An advantage 
is that it uses polymorphism so that you can selectively choose 
the level which errors you want to catch. 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.