Generate Result automatically?

[dpc]

Every single error in my codebase looks like this:

#[derive(Debug, Snafu)]
pub enum XYZError {
    // cases
}
pub type XYZResult<T> = std::result::Result<T, XYZError>;

Could Snafu just generate the Result alias? :D . I know I'm lazy, but isn't that the whole point? :D

[Enet4]

Or better, generate this definition, which is a bit more versatile.

pub type XYZResult<T, E = XYZError> = std::result::Result<T, E>;

Personally I wouldn't be opposed to introducing that as an opt-in, so that it is not a semver breaking change. This would also make an opportunity for the caller to override the resulting type (no pun intended). It'd be used somewhat like this:

#[derive(Debug, Snafu)]
#[snafu(result)] // creates pub type `XYZResult`
pub enum XYZError {
   // ...
}

or this (if we want to support overriding the name):

#[derive(Debug, Snafu)]
#[snafu(result(XYZResult))]
pub enum XYZError {
   // ...
}

I have many places were I just name it Result (mainly when there is only one error for the module), though «Foo»Result is a common pattern as well.

[shepmaster]

This feature has to be opt-in or semver-breaking with an opt-out — it would generate a new type that may conflict with an existing type. In addition, that generated type could potentially be public and that isn't something you'd want to do without the author being aware of it.

I think we could follow a similar pattern to the one we use for context selectors: the result's name would be the error name modified by s/Error$/Result. That way if your error is called FooError, you get FooResult, or if it's just called Error then you get Result. Presumably @Stargateur isn't creating types just called Error with their distaste for a bare Result.

Providing an override to the name is one reasonable configuration knob, but I wonder what others exist — anything to do with visibility? I'd like us to think through these possibilities. We don't have to handle each in the macro (it's for the common cases, after all), but it'd be good to think of them before making the macro syntax.

I agree that the result alias would have the defaulted error type. To my knowledge, there's no downside to allowing it and it helps in the cases where the alias is called Result. Then, if people import io::Result (as an example) without realizing it, usages of Result<X, AnotherError> continue to work.

[shepmaster]

From my user perspective, I've actually recently gone away from having Result aliases. I think this is because I've been experimenting with creating way more error types (often one per function!). This means that the number of times I use a specific error in a Result has been very small, to the point where an alias doesn't really carry any weight.

For one example, the form with the type alias seems more complicated than the one without, especially when it's used just once:

struct FooError;
type FooResult<T> = core::result::Result<T, FooError>;
fn demo() -> FooResult<()> {
    Ok(())
}

struct FooError;
fn demo() -> Result<T, FooError> {
    Ok(())
}

So I'd love to have a discussion about why we use result aliases in today's Rust. I think one place I do use it is when doing a bit of IO that I don't care to describe more granularly:

fn file_stuff() -> io::Result<()> {
    file.thing_1()?;
	file.thing_2()
}

However, I frequently look at that type of code and think "how will I tell if it was thing_1 or thing_2 that failed?

[Enet4]

I have updated my reply above with some more insights. I agree that, as long as snafu(result) works on types named Error, there may not be an immediate need to support overriding the name of the result alias.

Regarding visibility: I'm not sure if anyone envisions the need for this to be different from the error's, but I imagine that the same visibility keywords should flow from the error to the alias by default.

[Stargateur]

specially for newbie I found alias of Result confusing. I like Error cause you write thing::Error or Error is local to your file. For Result it's also remove information fn demo() ->Result<()> is not instantly clear what is the error, fn demo() -> FooResult<()> or fn demo() -> Result<T, FooError> read better.

Source: None it's only my feeling

[dpc]

BTW. (Getting more and more off topic), but IIRC in Golang imported items need to be qualified by the module name. I wish there was a lint to enforce this for certain modules/items in Rust. E.g. if I have a module foo, then if all external uses were using foo::Error and foo::Result than I would find it better than FooError and FooResult, but since there's no way to enforce it, in practice it becomes increasingly confusing which Result is which, so I use FooError at the cost of stuttering (foo::FooError).