You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today the colouring for geters and methods is different. See the following code:
classClass {
voidFunction() get getter => () {};
voidmethod() {}
}
voidfoo() {
var instance =Class();
instance.getter;
instance.method;
}
This differenciates both in declaration and on usage even tough both of the above work the same*.
Today we have patterns that allow us to deconstruct a variable:
classClass {
int myField =0;
}
voidfoo() {
var instance =Class();
if (instance caseClass(myField:var myFieldValue)) {}
}
We also can get** a method as a FunctionType:
classClass {
intfoo(int x) => x;
}
voidbar() {
var instance =Class();
if (instance caseClass(foo:var fooFn)) {
fooFn(3);
}
}
I'd like to request the same colouring to be applied here inside pattern destruction - at least when we have the name before : but I'd be fine with it also being applied to the new variable here if it has the same name.
Yeah, I feel like both foos here should be highlighted the same (in the yellow colour). I'd have to do some debugging to figure out why it's not - the colours for semantic tokens are mapped from the servers Highlight kinds. Methods are usually handled around here:
I'd like to wait to see whether method tear-offs are allowed in patterns before we fix this issue. But I agree that if tear-offs are allowed it would be good to color them in such a way that it's more obvious when it's happening.
Today the colouring for
get
ers andmethod
s is different. See the following code:This differenciates both in declaration and on usage even tough both of the above work the same*.
Today we have patterns that allow us to deconstruct a variable:
We also can get** a method as a
FunctionType
:I'd like to request the same colouring to be applied here inside pattern destruction - at least when we have the name before
:
but I'd be fine with it also being applied to the new variable here if it has the same name.*I've opened dart-lang/language#4159 related to this propriety.
**1. I've opened dart-lang/language#4234 related to this functionality.
**2. @lrhn has commented the following:
The text was updated successfully, but these errors were encountered: