[flohofwoe]

> How would you like Rust to describe such Types?

If I knew the answer I would design programming languages ;) Replacing `Either<this, that>` with something like `this | that` like in Typescript might be going into the right direction though. Zig has similar syntax sugar for Rust's Result<> and Option<>. Such things are so fundamental that they should be part of the language instead of the stdlib IMHO.

> Don't see how this is a Typing issue, sounds more like API issue

Designing an API is a typing issue, because an API is essentially nothing more than a list of types.

[lifthrasiir]

Here `Result` is very likely not the standard library type, because `std::result::Result` has two generic types for Ok and Err. It will be a partial alias to `Result<T, Error>` where `Error` is used throughout the entire code base to simplify the error handling. (The same pattern occurs in `std::io::{Result, Error}` in the standard library.)

Making `Result` a built-in syntax will disallow such freedom, and Zig has whole dedicated features to tackle problems solved by having `Result` just a normal type. Everything here is just a trade-off and both Rust and Zig have reasonable solutions for their use cases.

[still_grokking]

> Replacing `Either<this, that>` with something like `this | that`

That's not the same.

The first one is an ADT instance with exactly two cases, whereas the other is an arbitrary union type.

The difference is when you pattern match on them. In the first case the compiler can statically verify that you handled all (two) cases. In the second case you can deconstruct the union, but you're not forced to handle all cases, simply because there are no know "all cases"; you could have arbitrary unions of any amount of things. (Of course the compiler could create for any usage of an union type some synthetic ADTs behind the scenes and check exhaustivity on them, but this would explode pretty quickly, I think, because of code bloat and compile times. Also that's not the expected behavior of union types in general).

> Designing an API is a typing issue, because an API is essentially nothing more than a list of types.

It's more a list of signatures, and some interaction protocol on top of that. (Frankly not expressed in types usually. We don't have simple ways to use things like session types still).

The types used in your signatures can be as specific or general as you want. It's the choice of the API designer. There is no issue with typing as such. You could just declare everything being a function from `Any => Any`… That's of course as bad as having so specific types that there can be more or less only one object shape that fits it. Classical over-typing, and that's imho just bad API design…

[tcfhgj]

If you need a certain object shape, best require it in the API.

You can't be too specific there, because being as specific as possible has advantages: https://news.ycombinator.com/item?id=41409475