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.

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:

auto value = chain()?.funcs()?;

While being @nogc and without using exceptions. Other than for panics.

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:

auto result = expr;
if (result.isErr())
    return result;

auto value = chain()?.funcs()?;

yikes, I'd prefer if D could use ? for safe navigation.

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:

auto result = expr;
if (result.isErr())
    return result;

auto value = chain()?.funcs()?;

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.

On Thursday, 31 March 2022 at 21:35:00 UTC, user1234 wrote:

auto result = expr;
if (result.isErr())
    return result;

auto value = chain()?.funcs()?;

Why not for both? .? and ?? could be overloadable operators like opDot, which when applied to pointers and class references will behave like they do in other languages, while structs could overload them to implement behavior like Rust's Result type.

On Thursday, 31 March 2022 at 21:35:00 UTC, user1234 wrote:

auto result = expr;
if (result.isErr())
    return result;

auto value = chain()?.funcs()?;

That is Rust's equivalent.

https://en.m.wikipedia.org/wiki/Safe_navigation_operator#Rust

On Thursday, 31 March 2022 at 21:46:53 UTC, IGotD- wrote:

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.

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.

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:

It has some warts still, that is why packages like these exist,

https://docs.rs/thiserror/latest/thiserror/

https://docs.rs/anyhow/latest/anyhow/

To work around the boilerplate and lack of support in standard library when combining errors from different libraries.

Rust still suffers from a npm like approach to stuff that should be part of the standard library for basic stuff, error definition, async runtimes, serialization,...

On Friday, 1 April 2022 at 06:17:53 UTC, Paulo Pinto wrote:

Yes it seems they don't want to commit on those extensions. They seem to not want to define what an error is which leads to that problem. It can be avoided by including those things in the implementation details. C++ has an expect struct in the pipeline but it doesn't define what an error is either, nor how to handle multiple error types. That would need to be worked on as well.