Dart-Code
Different `semantic token type` for a function as a parameter/getter
Is it possible to add different semantic token type for a function as a parameter than other parameters?
In the following screenshot, you can clearly see that I have set red color for the function declarations and calls, but if I look for only red color in the code for spotting functions, I can easily miss to see the declaration and call of the function which is passed as a parameter.
@DanTup I am anxiously waiting for this feature. It almost feels like a bug as it's color should be the one set for functions.
@shujaatak sorry for the delay in responding. We can only set a single type on a semantic token and parameter here is consistent with what we do elsewhere (for example in final foo = () {}, foo is categorised as a local variable).
We have the ability to add additional modifiers to the token, which we often to do support further customisation of colours. It might be possible to add a function (or similar) modifier to allow customisation here (although it would be opt-in - you'd need to use your VS Code settings to apply the colour).
Swapping it around is also a possibility, although I'm not sure if that's what most people would expect. I think I'd be surprised to see my variables and parameters coloured differently based on their types, although I can also see value in having things that are callable being coloured differently.
@bwilkerson any thoughts/opinions on this?
I wonder if there may be grey areas/edge cases here too. For example, if a local variable is an instance of a callable class, should that be treated as a function type?
I wonder if there may be grey areas/edge cases here too.
Yes, there definitely are.
I think the question is whether we color identifiers based on the kind of declaration used to declare the identifier or whether to color them based on the type of the identifier (or, more specifically, whether to treat function-valued identifiers differently). I think the answer is that we color them based on the kind of declaration used to declare the identifier.
Another edge case is around local functions. For example, consider f1 and f2:
void example() {
void f1() {}
void f2 = (){};
}
f1 is a local function. It can be invoked, and it can be torn off, but it can't be assigned. f2 is a local variable. It too can be invoked, and it can be both accessed and assigned. But because it can be assigned a non-function value later in the code it would seem odd to mark it as a function.
And what about nullable function-typed variables? I think it might be useful for them to not be highlighted as functions because they might in fact not be invocable.
If we want to have modifiers for some special cases, such as function-valued identifiers, or Future-valued identifiers, I have no objection.
We have the ability to add additional modifiers to the token, which we often to do support further customisation of colours. It might be possible to add a function (or similar) modifier to allow customisation here (although it would be opt-in - you'd need to use your VS Code settings to apply the colour).
Adding a function modifier will be enough for achieving the required results.