_italics = `compiler_errors`'s comments_

# GATs stabilization concerns

## Complexity

[nrc][1]: From last year's annual survey, 33% of users said their biggest worry for the future of Rust was that it would become "too complex" (the second highest ranked answer).

_Specifically, burden of having to teach new syntax_
* [nrc][1]: They introduce new syntax and new semantics to the type system. [...] mostly GATs are useful for expressing new abstractions which are inherently difficult for many programmers to understand.

_Specifically, the argument that GATs' complexity can't be hidden in the API_
* [nrc][1]: GATs will primarily be used by library authors and are part of the API, thus programmers will not get a choice to avoid them. [...] (compare to unsafe coding features, which can be completely encapsulated) [...] (compare to async, where if a programmer is not doing async programming, they don't need to know about async or await))
* _Counter_: `serde` has a short explanation of HRTBs right in (their docs)[https://github.com/rust-lang/rust/pull/96709#issuecomment-1118456580].

## Not useful

[nrc][1]: There are use cases for GATs, but very few of them have been proved out. I don't know of any use cases which have been implemented and demonstrated to be significantly useful.

_Counter_:
* [chumsky](https://github.com/zesterer/chumsky/pull/82) - Zero-copy parsing with GATs, more detailed description of how the [parser uses GATs](https://github.com/rust-lang/rust/pull/96709#issuecomment-1118409546)
*

[nrc][1]: However, there is no requirement that GATs need to be exposed to the user to facilitate this usage. I think using GATs as a principled internal representation is fantastic, but that does not require exposing them to users.

[burntsushi][3]: That GATs make the language more consistent in some corners does not really hold much sway with me in terms of "complexity" here.
* _Essentially, the fixing symmetry (i.e. assocs being the only item-like w/o generics) =/= compelling enough to implement something like this_

## Not Rust

[nrc][1]: Finally, GATs increase expressivity but in a way which takes Rust in a new direction. GATs and HKTs more generally are a fine way of building abstractions, but they are not the Rust way. [...] There is probably a fine language which is something like Rust with abstractions built around HKTs and similar type system ideas, but that language is not Rust. It would require a different standard library, different ergonomics, and different programming idioms.

## Error papercuts

* Sabrina's post [TODO: summarize?]

* Errors discourage the most compelling usages e.g. [Filter adapter for `LendingIterator` requires Polonius](https://github.com/rust-lang/rust/issues/92985).

[burntsushi][2]: Namely, if I can't write a filter adaptor in safe straight-forward code, then... what else can't I do? Add on to that the lack of dyn traits and the inability to implement other types of adaptors like a `WindowsMut`, and it feels like there is just too much that can't be done. What's worse, I don't even know how to articulate in a sentence or two what GATs can or can't be used for if they're stabilized as-is.

_Specifically, difficult to enumerate GATs' current limitations_
* [burntsushi][3]: The issue I have with GAT's incompleteness is actually about the user experience. The const analogy is a good one, because it demonstrates just how different things are here. In my understanding, it is very easy to articulate and apply the limitations of what is allowed in a const context.

_Specifically, lack of diagnostics that describe what GATs are missing_
* [nrc][3]: ? Do you think I'm going to immediately give up and understand that GATs just aren't complete yet? Heck no I'm not. I'm going to keep trying to re-arrange the code because I'm pretty sure what I'm trying to do is legal. So maybe there's a contortion I can make to the code to make it work. All in all, it's an extremely frustrating experience.
* _Especially problematic because GATs are easily discoverable, so people aren't going to be searching for tracking compiler issues._
* [consts can clearly tell you that X is not allowed](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6a686bcdb7a749e5a2695d6a33f69766)

_Specifically, GATs make existing bad interactions of language features more likely_
* [burntsushi][4]: know it's a pre-existing issue. Namely, if GATs make that borrow checker limitation more common than it already is, that isn't good. My argument is not one of mere existence. It's about the overall user experience.

## Process concerns

[nrc][5]: This is partly a process failure, but also this is exceptional work both in scope, and in time between RFC and implementation (it's been 6 years since the RFC was proposed and 5 years since it was accepted).

[nrc][5]: The project has changed a lot since the RFC was proposed, both technically (the type system has got more complex in other ways) and non-technically (the language is much more mature now, we have many more users, and are attracting new users at a much higher rate).

[1]: https://github.com/rust-lang/rust/pull/96709#issuecomment-1118275010
[2]: https://github.com/rust-lang/rust/pull/96709#issuecomment-1118627760
[3]: https://github.com/rust-lang/rust/pull/96709#issuecomment-1118835484
[4]: https://github.com/rust-lang/rust/pull/96709#issuecomment-1118853235

-----

To summarize (counter-argument posts):
* https://github.com/rust-lang/rust/pull/96709#issuecomment-1118630905
*