What everyone is talking about isn't "not having to write `and_then` over and over" but rather that there is a common interface to "things that are monads", i.e. `>>=`, `map` and `apply`. `do`-notation is nice syntactic sugar on top of that common interface, but it's not the actual thing itself.

I think you misunderstand. I mean that merely by implementing the Monad typeclass, you get a ton of methods (mapM_, join, etc.) for free. You can't do that in Rust right now.

I wonder if these could be written against the Carrier trait.

It is not. do notation is just syntactic sugar. The feature that enables re-use are the type-classes and the structure of the standard library. Interestingly, you do have traits in rust, but I think there is no monad trait yet in the std lib.

There is not a monad trait because we do not have higher kinded types, which is a requirement.

Beyond that, it's not clear that a monad trait would work, even if we did. It may, but it also may not. We'll see (or not) I guess.

Why wouldn't a Monad trait work?

You mean you couldn't express it in Rust, even with HKTs? Or you mean that it wouldn't be useful?

Both. See here for more https://twitter.com/withoutboats/status/1027702538563477505

There have been some people working on these problems, take https://varkor.github.io/blog/2018/11/10/monadic-do-notation... for example. This is why I say "not clear" and not "impossible" or something. We just don't know.

It's basically a research-level problem given the other constraints of Rust. (Which is fine. Trade-offs and all that.)