Hacker News new | past | comments | ask | show | jobs | submit login

I did see that. This is a common pattern in many functional languages, and (for example) Scala has the same issue with Either. It's a common enough complaint that there are numerous right-biased utility versions in the wild that make it more ergonomic.

Having a type that is right biased doesn't mean it can't also implement the more generic interface. If your needs change you can always go back to using the less opinionated version with little breakage.

Rust's is notable in that they have both Either and Result. I think there's value in that, even if it is mainly for ergonomics and communication.

Also, aliases are fine, I could just see them being duplicated a lot. Probably not my first choice.




> Rust's is notable in that they have both Either and Result. I think there's value in that, even if it is mainly for ergonomics and communication.

either isn't in std though, it's a third party crate. Personally, I think the core data structure should be as generic as possible. The reality is that if the Result type was named appropriately, the Either crate would be redundant.


Rust's "generic as possible" type is an enum. Result is a specialization meant for common error handling.


> Rust's "generic as possible" type is an enum

What enum? We're talking about a specific data type, it doesn't make any sense to say 'an enum' is the generic version of Result.

I understand why they chose Result instead of Either. I just disagree with it; what you end up with is 2 data structures with the exact same structure and implementations but that represent different things. If you have Either in std, then Result is redundant, but not the other way around.


What Result? Result is a generic not a specific type. It's essentially a shorthand instead of manually writing out the enum yourself.

More fundamentally I disagree that Either makes Result redundant. Result has semantic meaning that's lost with Either.


> What Result? Result is a generic not a specific type. It's essentially a shorthand instead of manually writing out the enum yourself.

No, it's not 'a generic', but it has generic type parameters. An enum can be any number of variants with any number of type parameters.

A result is: data Result a b = Err a | Ok b (or in Rust) enum Result<T, E> { Err(E), Ok(T) }

> It's essentially a shorthand instead of manually writing out the enum yourself.

I'm not sure which enum you're referring to. You do realise an enum can have any number of variants, not just 2? I could define a sum type with 16 variants. 'enum' is just Rusts keyword for defining sum types.

> Result has semantic meaning that's lost with Either.

Which is what?


> You do realise an enum can have any number of variants, not just 2?

Yes, that's what makes it more generic than Result. Indeed that's the only practical difference except for a few helper functions and a #[must_use] (which only makes sense for Result, not for a more general Either type).

>> Result has semantic meaning that's lost with Either.

>Which is what?

Seriously? Error checking! That's the whole point of it. One side has meaning over the other; it has weight. The "left" is the result you want. The "right" is when something gone wrong.


> Yes, that's what makes it more generic than Result. Indeed that's the only practical difference except for a few helper functions and a #[must_use]

I think you have some fundamental misconceptions about sum types. Note that enums also don't even need to have any variants.

enum Never {}

Either way, this discussion is no longer fruitful. I encourage you to read about sum & product types.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: