4 ms·
I hope that std::prelude::Result becomes anyhow::Result, including the default generic argument (i.e. Result<u32> just works, no need to write Result<u32, Unnec
by codeflo 6y ago
I hope that std::prelude::Result becomes anyhow::Result, including the default generic argument (i.e. Result<u32> just works, no need to write Result<u32, UnnecessarilySpecificErrorType> unless you have a reason to). That would encourage examples and simple scripts to use Results and ? instead of calling unwrap and panicking. Not only would this teach better practices earlier, it would also address many of the complaints that Rust’s error handling is harder than exceptions in common usecases.
- danieldk 6y agoI hope that std::prelude::Result becomes anyhow::Result, including the default generic argument (i.e. Result<u32> just works But that's basically giving up on informative library-specific error types. It may a valid solution, but it is quite a big leap. Another tack may be to have the functionality of thiserror in the standard library, to make it less of a hassle to define errors.
- masklinn 6y ago> But that's basically giving up on informative library-specific error types. It may a valid solution, but it is quite a big leap. Technically the stdlib could probably define Result<T, E=Box<dyn Error>> That way there wouldn't strictly be any loss, you'd just get a more convenient "application-level" Result OOTB. I don't know if that would be incompatible with the existing though.
- steveklabnik 6y agoOne serious issue there is that this would no longer be in libcore.
- masklinn 6y agoCouldn't libcore export the current version and std re-export the aliased version with a default? The prelude lives in and uses std, and I don't see people who want exceptions using no_std anyway.
- steveklabnik 6y agoI was thinking no, but I guess you could do something like https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7c19e5e077d082eaf56061675cc4d887 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- masklinn 6y agoYou'd probably need to use the "default type parameter" feature for the alias otherwise std's Result is a breaking change and you have to use core's result to provide a custom error type, which I think would be a step back. It's what anyhow does: pub type Result<T, E = Error> = core::result::Result<T, E>; That way you can still use `Result<i32, MyCustomError>`. I don't know if there are limitations or issues with this approach though.
- codeflo 6y agoI’m not suggesting making this impossible - anyhow::Result has an optional second type parameter, after all. But not all code you write is “library code“, and for applications, simplified error handling is very often exactly what you want.