Conceptually it's "just" the ability to take one existing concept, generics, and apply it to another existing concept, associated types. Under the hood there's a lot going on to make that work with the type system, and there's some advanced things that this now enables, but as far as a beginner is concerned this is less "a new feature" than "lifting a restriction on an existing feature".

By analogy, imagine a version of C where you can't use a struct as a member of a union. Then, a new version of C comes along letting you use structs in unions. We could call that a new feature, "struct-in-unions"... or we could just call it lifting a restriction on an existing feature. It's entirely natural to want to use structs with unions, and it's probably what a learner of the language intuitively expects should be possible. Likewise, a learner of Rust probably expects that any type can be used as an associated type, and before today that wasn't true, and after today that is true.

I second this as a recent learner.

I have been learning Rust by writing some toy code over the weekends, and 9 out of 10 times when I hit a roadblock and went to my local Rust Users Group, the answer was "just wait for GAT". Turns out these patterns occur organically out of fairly mundane needs of abstraction (e.g. the now-infamous `LendingIterator`), and especially for me as a C++17/20 daily driver, _arbitrary_ limitations on expressivity.

Don't get me wrong --- Rust feels a lot more expressive than C++17/20 in the vast majority of areas, but for the rest maybe 10%, it's pothole land for stable Rust. Eliminating some of these potholes is a big win for Rust's adoption story.

Generics being a form of a compiler only dependently typed lambda axis is still infinitely more complex than chaining product & coproduct (sum) data types.

Please elaborate? Keep in mind that Rust isn't about making the simplest or most expressive language possible. Rather, it's about pushing the envelope on what sort of expressiveness we can soundly get away with while still benefiting from mechanical sympathy given the current state-of-the-art of optimizing compilers (and, also, while not being so foreign as to cause C-style language programmers to run away screaming).

It's labeled "stable", but this seems to require a bit more understanding by implementers than simple composition to safely use, specifically the part about "where clauses [being] required when those bounds can be proven in the methods that construct the GAT or other associated types that use the GAT in the trait".

> Conceptually it's "just" the ability to take one existing concept, X, and apply it to another existing concept, Y.

Yes, precisely. This is the literally what parent was talking about, "programming language abstractions [...] stacking on top of each other"

As opposed to creating completely different ways of doing things from the existing patterns?

The parent was echoing the common complaint (exclusively from people who don't actually use rust, in my experience) that rust is getting "too many features."

But as others in this thread has pointed out, features like GATs actually make the language simpler, because they're removing weird (and to a new user, unexpected) restrictions on existing features. This will then unblock removing other surprising restrictions, like the inability to use async functions in traits.

Rust takes the philosophy that it's better to do hard work in the compiler in order to make the language simpler and easier for users. That's what's happening here.

I thought it was doing hard work in the compiler to make the binary safe for processors.

Try thinking of it less as a new abstraction and more of removing a restriction from a previous abstraction. It is pretty easy to run into a situation where you want them without even knowing what the concept of a GAT is.

Rust gets a lot of unfair criticism of "adding new stuff" when a lot of what is "added" is actually removing restrictions and making it where a developer has less to learn.

I recently refactored some traits that had a lot of repetitive noise in the generic type parameters (which end up being reflected in function signatures etc). I went about this without really being overly aware of GATs and their status, but the code that I naturally ended up with required enabling them.

So from my point of view, I didn't really need to understand what GATs were bringing - it's a lifting of restrictions that would have previously felt arbitrary.

GATs are a really straightforward extension of what the language already has. All this means is that now a generic type can take a value as a parameter, for example there could be a generic fixed-length array, which took a length as a parameter. In the past libraries had to hack their way around this by having huge tables of types named like, "N1, N2... N16... N1003", which were passed to generic signatures to indicate to the type system how big something had to be.

I don't think this makes the language more confusing, because putting an integer inside of the generics brackets is something that previously you might try to do, if you didn't know it wasn't allowed. In fact, I would go so far as to say that this is a compiler feature, rather than a language feature, because it fills in a semantic hole that already existed in the way Rust programmers thought about Rust types. :-)

The feature you're referring to is const generics which is different than generic associated types (GATs) which is the feature being stabilized.

min_const_generics have been on stable for while

Note however broader Const Generics, allowing you to use your enumerated Hat type as a constant parameter to a type, producing PigInAHat<Hat::StrawBoater> as a distinct type from PigInAHat<Hat::Top> are not yet in stable Rust and aren't on the near horizon.

The idea is that any types which Rust can see for itself can be trivially compared for equality will eventually qualify for this purpose, so your Hat enumeration, or a structure with four integers and a boolean in it, or anything that Rust says "Yeah, I'll just memcmp that for equality" would qualify. No floating point numbers, no strings, nothing actually crazy. But this is in some undefined future, for now we just have min_const_generics which is basically the fundamental integral types as constants in generics.

Sure.

It seems like a pattern for languages that try to be more pragmatic. Instead of a Big Idea, turtles-upon-turtles approach that would take years to finalize in a form that doesn’t invalidate everything that came before it, one goes for an initially good enough approach and then release more and more features which to the insider might seem very holistic but to an outsider (like me) just sound like Static Runtime-Bounded Polyhydral Lambda Cube Type Capabilities and Associates.

In this case it is the lack of this ability which, when you meet it, is unexpected and unintuitive. Think of this as a design-level bug-fix.

This isn't so much the introduction of a new concept or abstraction as the removal of what feels like an artificial limitation. You should be able to use a generic in a trait in a type defined in that trait, and when you can't it feels broken.

Well you don't have to use it just because it is added, but it will allow library writers to provide more ergonomic interfaces. This specific type system feature allows for stuff that weren't possible before but make sense and you'd expect to be valid code that compiles:

the most common example is the lending iterator. Have a struct that owns a vector of data. Can you implement an iterator that can return a reference of each item when you call next()? Not without GATs, because each time you return from next() you're creating a new lifetime that doesn't exist in your trait definition.

That's why current standard library iterators are basically structs that own a reference to what you iterate. See the GAT RFC which explains this concept much better than I can:

https://github.com/rust-lang/rfcs/blob/master/text/1598-gene...

TL;DR it's not a "new" feature per se but something that could have been present from the beginning without making the language different.