Is there a particular reason that
Task is typed
Task err value instead of
Task value? Just kind of seems like it makes it more complicated and introduces more concepts when it doesn’t need to.
Ways this appears to complicate things:
Task Never valuewhen an error is impossible rather than requiring
Task (Result err value)when an error can occur. This requires at least some understanding of the
- Requires re-implementing functions that already exist for the
- Requires both
Task (Result err value)would only require
Maybe it’s a performance or implementation detail? Or maybe it really is simpler the current way for new users?
Edit: Seems to be a bit of confusion about what I meant. As a real-world example from another community, Rust recently incorporated Futures into its standard library. The implementation was based on Tokio futures, which are the de-facto community standard and have the type Future<E, T> mirroring the Elm
Task err value type. They typically represent futures that have no failure state by making E the unit type. However, in the interest of making the standard library as small and simple as possible, they opted to use the signature Future<T> instead, and represent futures that can fail with Future<Result<E, T>>. This is the same basic idea that I’m taking about.
Just to be clear I’m not claiming Elm should implement something just because Rust did. I’m just curious if there are any specific reasons for using
Task err value rather than
Task value when (subjectively I guess)
Task value is simpler and requires fewer ideas.