Type annotations: Order of T and E

[dbrgn]

In Rust, the Result type is defined as Result<T, E> (success case first). In Haskell, it's Either ConnError a and in Elm it's Result error value (error case first). On the other hand OCaml and F# also put the success case first.

When #4 was merged, I did not notice that the type annotation chosen was Generic[E, T]. In general I'm fine with the other order, but since we clearly state that the library is inspired by Rust, I wonder if we should switch the order while we still can. Version 0.3.0 is already released so it might break some people's code, but we're not yet at 1.0, so I think it might be fine.

It's a trivial difference, but I fear that people might get confused with [E, T] when expecting an API similar to Rust and will mix up the order of the type parameters. What do you think, @tyehle?

[tyehle]

I agree. Changing the order seems like the right thing to do. When I wrote that I wasn't aware the order was different in Rust than Haskell.

[snorfalorpagus]

Does this have any implication for existing code that has been written one way or another? I had assumed the order was [T, E] and mypy has never complained.

[dbrgn]

It only matters if you actually do something with the success or error case that does not comply with the type.

If your result type is Result<str, List[int]> and you call len(...) on the value then that will work with both the success and the error case without mypy complaining.

[dbrgn]

#8 is merged, testing the version on master is welcome.