As klodolph says, there's no axis for fallibility because the language doesn't offer different choices of fallibility strategy. There's just one: exceptions.

You can catch exceptions. If an iterator throws, you can catch that by surrounding the for loop in a try catch block.

Futures are sort of like Result types in that a Future can complete with either a value or an error. Exceptions inside asynchronous functions are automatically caught and wrapped into error futures, which then propagate out through the returned future object. When you await a future, if the future completes with an error, that then gets unwrapped back into a thrown exception.

> Futures are sort of like Result types in that a Future can complete with either a value or an error.

Incidentally, for curious readers, the first version of the Future trait in Rust always returned a Result<T, E> from its poll method. The second version decided to instead return T directly, since T could be Result<T, E> too, making things a bit more general, but also leading to a tiny bit of type tetris.

Doesn't mean that I'm saying anything about whatever Dart does here, just that I also think there's a connection here :)

> It doesn't seem like you can get around needing fallibility.

There’s no axis for fallability because all operations are fallible. Yes, you can catch exceptions when iterating, awaiting, or iteratively awaiting. You have fallibility. What you don’t have is a way of marking operations as non-fallible.

If you use something like fpdart, you have the more functional Either type (called Result in Rust).

https://pub.dev/packages/fpdart#eitherlibsrceitherdart