5 ms·

I have been waiting for this feature for forever! I am so excited to have it stabilize (hopefully doesn’t get reverted). This will cut down on so much boiler pl

I have been waiting for this feature for forever! I am so excited to have it stabilize (hopefully doesn’t get reverted). This will cut down on so much boiler plate in traits and enable new design patterns. This moves us one step closer to true HKT’s.

cercatrova 4y ago
I remember a Rust team member (perhaps several) saying that they don't want full higher kinded types in Rust, as GATs (I'm paraphrasing here) should give most of the functionality for a smaller footprint. I'm not sure how true that is though. What are some use cases in your view for HKTs?
- lmm 4y ago
  Not the person you replied to but: Writing combinators that work generically over Fn/FnMut/FnOnce (for a very simple case, try writing the "compose" function - currently you have to write all three implementations separately even though they're identical). Writing code that works polymorphically between sync and async - this solves the "function colouring" problem without having to give up precise control of where yields happen. Writing data structure traversals (e.g. a tree walker/visitor) that can handle some kind of extra "context" in a generic way (e.g. updating a state, or making a database call, or indeed making an async call).
  - cercatrova 4y ago
    Do you think the keyword generics initiative will solve these issues? https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...
    - lmm 4y ago
      If they take the time and effort to build a consistent underlying model, yes (though I think the only proven way to do that would be to implement proper higher-kinded types and then turn keywords like async into syntax sugar for those). If they just add a bunch of ad-hoc cases for the keywords that are visibly causing problems then they'll probably make the issue worse rather than better. Given Rust's history of missed opportunities with this kind of thing (NLL, try/?, async), I'm not particularly hopeful.
      - cercatrova 4y ago
        > Given Rust's history of missed opportunities with this kind of thing (NLL, try/?, async) What happened with these? I'm out of the loop.
        lmm 4y ago
        They're all addressing problems that would be solved elegantly with full higher-kinded types, but Rust has opted for narrow ad-hoc approaches instead.
        cercatrova 4y ago
        You should write about this somewhere, or even on their GitHub RFCs, as it seems from what I've read that they don't want to have HKTs due to how it interacts with the borrow system (poorly, apparently) as it's not as easy as with Haskell or OCaml which are garbage collected.
        lmm 4y ago
        They're aware, plenty of people have tried to convince them that full HKTs are what they need and they're wasting their time doing dozens of partial implementaions instead of biting the bullet and doing it properly. They've made their decision that they'd rather do partial incremental work, and I'm not even sure they're wrong (it could be that they'll need the experience of all these different partial approaches in order to figure out how to make their borrow system handle HKT safely). I just hope they'll find a way to migrate all this stuff onto a coherent foundation when they finally do implement full HKT.
        cercatrova 4y ago
        Well I'll be glad to see it when HKTs come out.
- zozbot234 4y ago
  HKT's ought to be relatively easy to implement as a pattern on top of GAT's, so in that sense the functionality is available. The only immediate drawback is a slightly more complex syntax than what most languages support for HKT's, i.e. you have to express what would be type families in other languages as associated type constructors in Rust. But this is for good reasons as Rust devs have found that associated types seem more idiomatic in the context of a somewhat lower-level language. Other than that, the features are really quite similar. (This 2020 blogpost https://www.fpcomplete.com/blog/monads-gats-nightly-rust/ https://www.fpcomplete.com/blog/monads-gats-nightly-rust/ does a nice job of describing one such pattern, though their choice of Unwrapped and Wrapped<> as identifiers is overly obscure.)
kibwen 4y ago
I'm under the impression that "true" HKTs are incompatible with monomorphization, which means they wouldn't ever happen with Rust. (However, I also don't quite understand why these two concepts are incompatible.)
Gwypaas 4y ago
Here is some history of GATs, from the original author of the RFC and how their sole purpose is to not have to add HKTs. From the collapsed discussion in the OP. https://github.com/rust-lang/rust/pull/96709#issuecomment-1148852889 https://github.com/rust-lang/rust/pull/96709#issuecomment-11...

cercatrova 4y ago

I remember a Rust team member (perhaps several) saying that they don't want full higher kinded types in Rust, as GATs (I'm paraphrasing here) should give most of the functionality for a smaller footprint. I'm not sure how true that is though. What are some use cases in your view for HKTs?

lmm 4y ago
Not the person you replied to but: Writing combinators that work generically over Fn/FnMut/FnOnce (for a very simple case, try writing the "compose" function - currently you have to write all three implementations separately even though they're identical). Writing code that works polymorphically between sync and async - this solves the "function colouring" problem without having to give up precise control of where yields happen. Writing data structure traversals (e.g. a tree walker/visitor) that can handle some kind of extra "context" in a generic way (e.g. updating a state, or making a database call, or indeed making an async call).
- cercatrova 4y ago
  Do you think the keyword generics initiative will solve these issues? https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...
  - lmm 4y ago
    If they take the time and effort to build a consistent underlying model, yes (though I think the only proven way to do that would be to implement proper higher-kinded types and then turn keywords like async into syntax sugar for those). If they just add a bunch of ad-hoc cases for the keywords that are visibly causing problems then they'll probably make the issue worse rather than better. Given Rust's history of missed opportunities with this kind of thing (NLL, try/?, async), I'm not particularly hopeful.
    - cercatrova 4y ago
      > Given Rust's history of missed opportunities with this kind of thing (NLL, try/?, async) What happened with these? I'm out of the loop.
      - lmm 4y ago
        They're all addressing problems that would be solved elegantly with full higher-kinded types, but Rust has opted for narrow ad-hoc approaches instead.
        cercatrova 4y ago
        You should write about this somewhere, or even on their GitHub RFCs, as it seems from what I've read that they don't want to have HKTs due to how it interacts with the borrow system (poorly, apparently) as it's not as easy as with Haskell or OCaml which are garbage collected.
        lmm 4y ago
        They're aware, plenty of people have tried to convince them that full HKTs are what they need and they're wasting their time doing dozens of partial implementaions instead of biting the bullet and doing it properly. They've made their decision that they'd rather do partial incremental work, and I'm not even sure they're wrong (it could be that they'll need the experience of all these different partial approaches in order to figure out how to make their borrow system handle HKT safely). I just hope they'll find a way to migrate all this stuff onto a coherent foundation when they finally do implement full HKT.
        cercatrova 4y ago
        Well I'll be glad to see it when HKTs come out.
zozbot234 4y ago
HKT's ought to be relatively easy to implement as a pattern on top of GAT's, so in that sense the functionality is available. The only immediate drawback is a slightly more complex syntax than what most languages support for HKT's, i.e. you have to express what would be type families in other languages as associated type constructors in Rust. But this is for good reasons as Rust devs have found that associated types seem more idiomatic in the context of a somewhat lower-level language. Other than that, the features are really quite similar. (This 2020 blogpost https://www.fpcomplete.com/blog/monads-gats-nightly-rust/ https://www.fpcomplete.com/blog/monads-gats-nightly-rust/ does a nice job of describing one such pattern, though their choice of Unwrapped and Wrapped<> as identifiers is overly obscure.)

kibwen 4y ago

I'm under the impression that "true" HKTs are incompatible with monomorphization, which means they wouldn't ever happen with Rust. (However, I also don't quite understand why these two concepts are incompatible.)

Gwypaas 4y ago

Here is some history of GATs, from the original author of the RFC and how their sole purpose is to not have to add HKTs. From the collapsed discussion in the OP. https://github.com/rust-lang/rust/pull/96709#issuecomment-1148852889 https://github.com/rust-lang/rust/pull/96709#issuecomment-11...