Here's a collection of comments from the same PR from users arguing for stabilization:
"I work on chumsky, a parser combinator crate. I've recently been experimenting with GATs internally as a way to control exactly what code Rust generates. Instead of praying to the LLVM gods that the compiler might optimise things, I use a GAT to project a particular parsing 'strategy' into the implementation of parsers. I've found that I can significantly improve the performance of the library by an order of magnitude, even beating out hand-written parsers, nom, and serde_json (with several caveats) without harming the library's expressivity (and, in fact, improving it). This all happens without the GATs themselves being exposed to library users at all."
"The first time I realized the Iterator trait was insufficient for what I wanted was before Rust 1.0 in 2014 when I wrote one of the first versions of the csv crate. All I wanted to do was write an iterator that lent out a borrow of an internal buffer in order to avoid allocating a new record on each iteration."
"I've been using GATs on nightly for a little less than a year for various experimental proc-macro crates. I can only say that GATs simplify a lot of things for me! I'm not doing things like LendingIterator, my interest is more in "DSL"s. Things like e.g. generate a struct that temporarily stores all the parameters to some function (where some of those parameters will be non-static references). The main concern will often be how much code can I avoid autogenerating i.e. is it possible to write abstractions as libraries over these things. GATs allow me to do that with ease. [...] The one I'm currently working on is unimock. The GAT stuff is only in the gat-mock branch, not released on crates.io yet. That GATified trait is MockFn."
"There is no way to use async traits in an embedded context (no_std) without GAT's or pulling in the alloc crate (to use async-trait). Pulling in alloc for most embedded platforms is not feasible, therefore we are currently locked to nightly for the embedded-hal-async crate."
"Issue #95 on the RustAudio crate for example says, "The first [solution] would be to make PortType generic over a 'a lifetime...however, this has a cascading effect, which would force all downstream users of port types to specify their lifetimes". Pythonesque made a simpler point here, "Without GATs, I ended up having to make an Hkt trait that had to be implemented for every type, define its projections, and then make everything heavily parametric and generic over the various conversions.""
Here's a collection of comments from the same PR from users arguing for stabilization:
"I work on chumsky, a parser combinator crate. I've recently been experimenting with GATs internally as a way to control exactly what code Rust generates. Instead of praying to the LLVM gods that the compiler might optimise things, I use a GAT to project a particular parsing 'strategy' into the implementation of parsers. I've found that I can significantly improve the performance of the library by an order of magnitude, even beating out hand-written parsers, nom, and serde_json (with several caveats) without harming the library's expressivity (and, in fact, improving it). This all happens without the GATs themselves being exposed to library users at all."
https://github.com/rust-lang/rust/pull/96709#issuecomment-11...
"The first time I realized the Iterator trait was insufficient for what I wanted was before Rust 1.0 in 2014 when I wrote one of the first versions of the csv crate. All I wanted to do was write an iterator that lent out a borrow of an internal buffer in order to avoid allocating a new record on each iteration."
https://github.com/rust-lang/rust/pull/96709#issuecomment-11...
"I've been using GATs on nightly for a little less than a year for various experimental proc-macro crates. I can only say that GATs simplify a lot of things for me! I'm not doing things like LendingIterator, my interest is more in "DSL"s. Things like e.g. generate a struct that temporarily stores all the parameters to some function (where some of those parameters will be non-static references). The main concern will often be how much code can I avoid autogenerating i.e. is it possible to write abstractions as libraries over these things. GATs allow me to do that with ease. [...] The one I'm currently working on is unimock. The GAT stuff is only in the gat-mock branch, not released on crates.io yet. That GATified trait is MockFn."
https://github.com/rust-lang/rust/pull/96709#issuecomment-11...
"There is no way to use async traits in an embedded context (no_std) without GAT's or pulling in the alloc crate (to use async-trait). Pulling in alloc for most embedded platforms is not feasible, therefore we are currently locked to nightly for the embedded-hal-async crate."
https://github.com/rust-lang/rust/pull/96709#issuecomment-11...
"Issue #95 on the RustAudio crate for example says, "The first [solution] would be to make PortType generic over a 'a lifetime...however, this has a cascading effect, which would force all downstream users of port types to specify their lifetimes". Pythonesque made a simpler point here, "Without GATs, I ended up having to make an Hkt trait that had to be implemented for every type, define its projections, and then make everything heavily parametric and generic over the various conversions.""
https://github.com/rust-lang/rust/pull/96709#issuecomment-11...