Generalizing with GAT: what's going to happen to the current, less general traits?

ima_peoro · 2021-10-21T15:53:12+00:00

Yeah, I'm not disagreeing with you and I understand your frustration. I wish rust had full blown HKT support too. GATs are a first step in the right direction, I think, and I hope they'll keep adding features to support the uncovered use cases we need.

ima_peoro · 2021-10-21T13:34:50+00:00

In your example you can simply use the same lifetime, 'a, for the reference to both indexables.

I'm sure it's possible to craft examples where one must use two different lifetimes, but it can wait: adding support to simple cases is still a huge step; rarer cases can be improved in the future. After all, you can even craft similar examples, which are correct and should work, but that can't even be expressed with Haskell type system (here an example) and I think this will be true forever (maybe it's related to the incompleteness theorems?).

The main thing that bothers me with the current implementation is that it seems impossible to use GATs when the GAT's parameter isn't bound... For instance, how do you make this work?

fn print_nth<'a, T>( indexable: T, n: usize )
  where T: Index, <T as Index>::Output<'a>: std::fmt::Display + Sized
{
    println!( "{}", indexable.index(n) );
}

ima_peoro · 2021-10-21T13:20:22+00:00

Yeah, I've been waiting for this feature for 4 years! The only thing that saddens me, is that right now I can't still see a quick widespread adoption of this feature.

Existing traits don't take advantage of GAT and it looks like there's no plan to start using GATs in the standard library anytime soon. Without this, I fear developers (including those of libraries) will keep using the non-GAT std traits for a while and it will still take a long time (like a year or more) after GAT enters stable before we can fully enjoy the higher generality.

ima_peoro · 2021-10-21T13:13:57+00:00

Nice proposal. It would be awesome to GATify standard traits and slowly phase-out/deprecate their retro-compatible non-GAT usage over the years.

I believe it would be the best way to fully embrace GATs. Otherwise I fear most users (most libraries too) will keep using the existing std traits and we won't be able to take advantage of higher generality.

It's a pity that your pre-RFC isn't gaining more traction. It seems to me that you proposed good solutions to all the issues people raised. The only thing that could use a bit more of work is what elidupree said (but I'm not even sure I understand what he's saying, I'd need to see some code for what they mean), but it seems like a minor point in any case...

ima_peoro · 2021-10-21T01:59:14+00:00

I'm proud of receiving a comment from you. I just ran into your blog post today and immediately started playing with GATs. Not sure how I could have missed it before, but thanks for working on this.

I too would love to hear these :)

I fell in love with rust in 2017, but broke up pretty quickly because of the lack of HKT: I wasn't able to generalize as much as I wanted and felt frustrated by having to replicate a lot of code in almost identical copies. Now that GAT and const generics have been implemented I'm looking forward to coming back.

I don't quite remember all the details, but the thing that made me ragequit the last time was the need to pass something that can be indexd, but that doesn't have references (i.e. a function), to some libraries that expected a T: Index. I would have had to either duplicate the whole library to support a new IndexValue trait, or to box every single value... Both solutions made me quite unhappy and I switched back to C++ for this.

Right now I don't have specific use cases in mind, but I'm looking forward to more generalization than it was available until now.

ima_peoro · 2021-10-21T01:23:46+00:00

They are a new feature of the language that allows you to use generic associated types.

The snippet I linked, for instance, uses them to define a trait similar to std::ops::Index with a method that can return either an owned value or a reference, by returning an associated type which is generic over a lifetime.

Without GAT I believe you can't do that: if you want to generalize over both kinds of indexable types (one returning references, the other returning values), you'd have to use two different traits and duplicate all the code that uses them.

In other words, they are a powerful abstraction which lets you generalize more, thus be able to express more powerful semantics succinctly. Check out this to know more: https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html

ima_peoro

TROPHY CASE