So that means borrows across statements in do notation are just out of the picture. That's extremely limiting.
Conversation
Rust's imperative control flow statements like `return` and `break` inside of do notation also doesn't make sense, because we do not have TCP preserving closures.
3
4
21
So we only know how to have do notation without early return or borrowing. People say this is an open research question, but IMO its just not possible within our runtime constraints.
2
4
19
Getting beyond that, this is assuming that "future" implements "monad," so if we could just add HKT to have a Monad trait, everything would be hunkydory. That's not true!
1
6
21
the signature of >>= is `m a -> (a -> m b) -> m b`
the signature of Future::and_then is roughly `m a -> (a -> m b) -> AndThen (m a) b`
1
3
27
That is, in order to reify the state machine of their control flow for optimization, both Future and Iterator return a new type from their >>= op, not "Self<U>"
2
3
21
Also, our functions are not a `->` type constructor; they come in 3 different flavors, and many of our monads use different ones (FnOnce vs FnMut vs Fn).
1
3
26
Okay, so Monad can't abstract over Future, but still let's have Monad. Problem: we don't have higher kinded polymorphism, and probably never will.
1
3
23
The problem is that without currying at the type level, higher kinded polymorphism makes type inference trivially undecidable. We have no currying.
2
5
26
Does that actually matter? Trait inhabitation is already undecidable in Rust, which is a more serious theoretical problem, and supporting global type inference is nongoal anyway IIRC.
2
1
Yeah, can't stuff like bidirectional inference help in this case? I mean, Rust doesn't have global inference anyway. Or is this more a problem with trait inhabitation?