Odd behaviour with async method declaration: bad colorization

[DoctorKrolic]

Version Used:
VS 2022 v.17.2 Preview 2.1

Steps to Reproduce:
Start code:

class Test
{
    public async
}

Expected Behavior:
async is colorized as a keyword

Actual Behavior:

[CyrusNajmabadi]

At this point, we don't know if async is going to be a keyword, or is just a return type for a member that it's in the middle of being written. We could colorize as keyword in that case, but it's very minor.

[CyrusNajmabadi]

It's called a 'contextual' keyword. Meaning we allow it to be an identifier as well for compat reasons. e.g. it's entirely legal (and has happened) for someone to write: class async { } ... public async GetAsync() { ... }.

Note that while rare, we do support this as this code existed prior to us adding async as an actual language feature.

[DoctorKrolic]

Yeah, I know about contextual keywords, but in this case it doesn't seem reasonable for me. You can't do every new keyword in language contextual (or you can, but it will complicate compiler and IDE and in the end result in many developer's hours wasted to support backward compatability for 0.00...01% of users, who followed bad naming practices). value contextual keyword is reasonable, because it is a very common name for local names and method parameters and it has a very limited scope, in which it is legal to use it. async is just a method modifier, like public, abstract etc. and scope of usage for it as a lot bigger. There is list of breaking changes for every realese of .NET, which contains several times more than 2 or 3 items. Having a breaking change "async is no longer a valid type name" will apply to 0.0000...01% of users, but in the end will result in simplification of compiler and IDE code.

[CyrusNajmabadi]

You can't do every new keyword in language contextual (or you can, but it will complicate compiler and IDE and in the end result in many developer's hours wasted to support backward compatability for 0.00...01% of users, who followed bad naming practices)

We don't want to break people. So we take that burden to keep that compat bar. And we have done that for every single lang version we have :)

but in the end will result in simplification of compiler and IDE code.

Here's the thing though. It's not that complex for us to support it, and we're totally fine with taking that pain ourselves instead of causing pain to customers. We may change things in the future, but we're not going to do it haphazardly.

[CyrusNajmabadi]

who followed bad naming practices)

This is not true fwiw. And developers have many reasons they may end up here. Notably because they were mapping an existing API from some other system, or even auto-generating code based on schemas and whatnot. People do this and their code works and continues to work. We do make the determination at times to break things, but only when it's really really critical and the break is worth it. That's not the case here. It's not a big problem to just support this, and it means no pain for customers. Our objective is not to avoid pain on our side by pushing onto customers.