Re:Async and Await in Rust: a full proposal
by steveklabnik on Sunday July 15, 2018 @08:22PM
(#17537878)
There's multiple issues. The biggest ones that I can recall, off the top of my head:
First off, do notation desugars to closures. But Rust has three different kinds of closures. How does that work?
Furthermore, Rust has imperative control structures. How does all of this interact with each other? Are you now no longer allowed to use those constructs inside of do notation? That feels inconsistent.
I don't know of any languages that have something like do notation but don't have everything boxed. It makes everything easier, but that's not generally acceptable in Rust. For example, we can use async/await with no dynamic allocation. Could we with do notation?
"Open question" doesn't mean "impossible", mind you. But nobody has ever come up with a design. In the meantime, we have users to support...
Thanks, that's interesting, i should dive a bit more into how async is implemented. On "which closure kind to choose" i feel like that's not the worst part (closure syntax already infers which trait to implement), but the fact that it is a closure and how it fares with allocation seems not trivial.
For the moment, you can see the progress on empowering the type system in the RFC for generic associated types, which is intended both to be the simplest extension to the type system that allows for some important patterns (e.g. streaming iterators and collection traits) and to be forward-compatible with any additional extensions in the direction of HKT. Importantly, it's also intended to be intuitive for users who have no prior experience with higher-kindedness and usable without (hopefully) requiring anyone to learn anything about type theory. The RFC text can be read at https://github.com/rust-lang/rfcs/blob/master/text/1598-gene... and comments can be left on the tracking issue at https://github.com/rust-lang/rust/issues/44265 .
Re:Async and Await in Rust: a full proposal
by steveklabnik on Sunday July 15, 2018 @08:37PM
(#17537932)
Note also that HKT and do notation are their own separate things; you can have HKT without do notation. That's all HKT stuff, not do notation stuff.
If you have HKT then isn't do notation a piece of cake? It just desugars into monadic bind and return operators. Or is there something specific to rust that would mess with that?
Re:Async and Await in Rust: a full proposal
by pcwalton on Sunday July 15, 2018 @08:55PM
(#17538003)
Imperative control flow, for one. Think about how you would implement "break" that can break out of multiple nested loops in do-notation…
Re:Async and Await in Rust: a full proposal
by steveklabnik on Sunday July 15, 2018 @08:56PM
(#17538006)
Please see my comment here: https://news.ycombinator.com/item?id=17537878
I thought I had read at some point that generic associated types we're equivalent to HKTs in terms of what they can express. Or maybe that they were theorized to be so. Is that not the case? (Not critical, just curious)
Like what is the real road-blocker, since we're talking here about abstractions that are gonna be monomorphised (at most into lifetime-polymorphic function, which anyway get erased) and known statically, right? Is it only a problem of getting the typing rules consistent and robust?