VSCode Semantic Tokenization

[RohitSaily]

In VSCode void is semantically tokenized as a keyword. dynamic is tokenized as a type but dart.dev states it is a keyword. dynamic should be interpreted as a keyword for consistency, it is a specially treated standard type like void

[lrhn]

There are multiple kinds of keywords in Dart.

• void is a reserved word, the most restrictive kind. You can't use it for anything, it's not an identifier at all.
• dynamic is a built-in identifier, which means you can use it as an identifier, but not as a user-declared type name or import prefix.

I don't know where the categorization comes from, but it likely matches this distinction.

Reserved words are Keywords! This keyword is always a type, because that's the only meaning it can have.

Built-in identifiers may depend on where they occur. If you write dynamic x; it's a type. If you write int dynamic(int x) => x;, it's a function name.

[RohitSaily]

Interesting, that distinction wasn't obvious to me because I always treated them the same like any other types but you are indeed correct that dynamic is an actual usable identifier. I thought it was an actual keyword because of its special treatment. Personally, I would like it tokenized like one because it represents a different/atypical behaviour in the program

[bwilkerson]

... I would like it tokenized like one ...

That feels to me like the tools would then be lying about the semantics of the code, and I don't think we want to make them lie.

[RohitSaily]

... I would like it tokenized like one ...

That feels to me like the tools would then be lying about the semantics of the code, and I don't think we want to make them lie.

That is true, it would be technically different than how things are actually defined. I am just speaking from the perspective of how these are normally used and perceived. I would guess there are a lot of developers who do not dive into such details because they are using Dart just to build apps and services. Its ultimately conceptually reduced to a type with special behavior, as I see it

I do not understand the design decision for dynamic to not be a keyword like void given its use and deviation from regular type expectations/behavior

[RohitSaily]

typedef dynamic=void;

yields the following errors

dart(expected_identifier_but_got_keyword): 'dynamic' can't be used as an identifier because it's a keyword.
Try renaming this to be an identifier that isn't a keyword.

and

dart(built_in_identifier_in_declaration): The built-in identifier 'dynamic' can't be used as a typedef name. 
Try choosing a different name for the typedef.

The latter is consistent with dynamic being treated as just another type identifier, but the first makes me think it should be categorized as keyword. I think either the difference in these definitions needs to be made clear to the end-user or they should appear to be treated the same (even though they technically are not)

[bwilkerson]

... the first makes me think it should be categorized as keyword.

That's a problem with the wording of the message, and something that should be fixed.

I think either the difference in these definitions needs to be made clear to the end-user or they should appear to be treated the same (even though they technically are not)

Agreed. I don't think the second is an option without changes to the language specification, because they aren't the same and in some circumstances that difference will become apparent to users. Which leaves us with the first option, and highlighting them differently is part of how we're trying to make it clear. 🙂

[RohitSaily]

... the first makes me think it should be categorized as keyword.

That's a problem with the wording of the message, and something that should be fixed.

I think either the difference in these definitions needs to be made clear to the end-user or they should appear to be treated the same (even though they technically are not)

Agreed. I don't think the second is an option without changes to the language specification, because they aren't the same and in some circumstances that difference will become apparent to users. Which leaves us with the first option, and highlighting them differently is part of how we're trying to make it clear. 🙂

Makes sense, I'm on board with different messaging. As I understand it now the taxonomy is keyword which can be a reserved word or built-in identifier. According to this the errors are technically correct but the first one could be improved by clarifying that it can't be used as an identifier specifically there (as a type name) because there are cases where it can be used as an identifier as @lrhn pointed out eg a method name