[nrc]

No, they're not. GATs are used internally in the compiler to implement async methods, but there is absolutely no need for them to be in the language for that (just like generators are used to implement await but are not part of the (stable) language). GATs may or may not be useful, but IMO the actual real-world use cases are pretty weak.

[kibwen]

Yes, I've read the stabilization thread and I'm aware of your stance. :P Whether or not it's exposed, the mechanism still needs to exist in the compiler, and enough library authors are clamoring to use it that I think the argument in favor of exposing them is stronger than you're giving it credit for.

You mention generators, but a lot of people are clamoring for those as well, and I fully expect them to be exposed to end-users someday.

[nrc]

My point is that there or may or may not be reasonable justification for adding GATs, reasonable people can disagree on that. But async methods are not part of that justification. Similarly, generators may or may not be good for the language (IMO they would be good to add, if they can be made to work etc.) but they didn't need to be part of the language to add await.

[josephcsible]

Even if the use cases outside the standard library were weak, given that the work needs to be done anyway for the standard library, why wouldn't you expose them?

[nrc]

To be clear, there are not use cases in the std lib. The use case is as an intermediate representation for the compiler, and that is no motivation for inclusion in the language (in the same way that we don't have vtables or register allocation in the surface syntax)

[wtetzner]

Being able to have a generic "Mappable" trait seems like a good use case for the standard library. It's something I've wanted in the past, and was disappointed that it didn't exist.