In a theoretical sense, sure, but in a practical sense, my understanding is that GATs already exist in chalk, and so it's still a matter of putting in the work, not a question of "is this possible or not."

You would know better of course, but it was my impression that there is no firm commitment to stabilizing GAT, even once the compiler fully switches to Chalk, due the potential disruptiveness and complication of the language.

(For those unaware: Chalk is a rewrite of the trait logic in rustc, based on logic programming [1] )

[1] https://github.com/rust-lang/chalk

Certainly, but not in the sense of being uncertain about whether or not GAT are worthwhile, only in the sense of not wanting to make promises that may not be able to be kept. The Rust developers want GAT--or something analogous to GAT--and much work has been put in towards that goal (work that will have been useful even without GAT), and at this juncture there's no foreseen theoretical impediments; however, that's not to say that some unforeseen impediment won't yet arise. Such a thing happened with specialization, which has been in the works for much longer (current status: https://github.com/rust-lang/rust/pull/68970), and the lesson has been to not incite expectation until you are extremely certain the promise will be able to be kept. As a mere half-informed bystander it seems that GAT not encountering the problems that specialization did, but don't take this as any sort of promise. :)

Rust is already a complicated language. Those two features would increase the complexity of the type system quite significantly.

Possibly beyond what is healthy for Rust adoption.

I think async trait methods could be stabilized without exposing GAT to the user.

Of course I would very, very much like to have them either way, they would make certain abstractions much easier to build.