Re:Async and Await in Rust: a full proposal
by kibwen on Sunday July 15, 2018 @08:31PM
(#17537906)
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 .
[ Parent
| on HN ]
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)