4 ms·
> I think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type. Having ad-hoc error union Resul
by ww520 10y ago
> I think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type.
Having ad-hoc error union Result per function make it lightweight, and less friction in writing code. I would go one step further, let the compiler build the error union automatically.
fn func1() -> Result<MyStruct, _> {
let foo = foo()?; // might return Error1
let bar = bar()?; // might return Error2
...
}
The compiler infers the list of possible error types returning from the functions. Func1() would automatically have the return signature of Result<MyStruct, Error1 | Error2>.
Make the type inference to good use.
- JoshTriplett 10y agoThat kind of automatic sum-typing seems like an interesting idea. You might consider bringing it to the Rust internals forum, posting it as a pre-RFC, and discussing it as compared to some of the alternatives. That might lead to either a change in the direction you hope for, or the unearthing of other ergonomic approaches.
- eddyb 10y agoThis idea has been waved around a bit, but in the form of `impl Error` where `_` is. That is, inside the function the `E1 | E2 | ...` type is being built, and if you have automatic dispatch for `Error`'s methods then it will work with `impl Error`. Actual global inference has never been on the table and still isn't.
- masklinn 10y agoI believe there are conversations of being able to promote enum variants to full-blown types, though I don't know if there's any project for lightweight enums of types.
- dbaupp 10y agoI believe inferring sum types like that would make the inference system far more sensitive and complicated and possibly even slower. For one, it would likely mean mistakes like, say, assigning two different types to a variable may result in weird error messages, and may also limit how often coercions trigger.