nrc

Many of the features of such crates are making their way to the standard library, so things will definitely improve. Figuring out what is best has taken some time and Rust has not wanted to prematurely commit.

Nope, try blocks are a new (unstable) feature

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.

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)

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.

We'd like anyone who is interested in Rust to fill out the survey, even if you've stopped using Rust or have never used Rust (and of course if you're a Rust user, however much or little you use it).

I'm sorry you've had that experience. We are working hard to be better open source citizens in many ways, including better communication on issues, etc.

This should work (it's my goto test case). You have to put the cursor in the erroring code to see the possible fix icon in the margin. If you don't see it please file an issue with the project you're trying this in and I'll investigate.

We're literally hacking on this right now. It should be part of the early June stable release.

It should yes, if it doesn't then its a bug that I should fix...

Syntax highlighting is (usually) done by the editor, not the server in the LS protocol. The changes sent from editor to server are pretty minimal, and so the whole thing is pretty quick. The overhead, never caused us any problems.