Leaf Petersen
Leaf Petersen
> How about treating non-virtual methods as static methods with a parameter for `this`? This is the underlying semantic model of the proposal above. Whether we choose to "inherit" the...
I see that @sigmundch had already filed an issue on this idea [here](https://github.com/dart-lang/language/issues/2400).
I have no problem not allowing it. The main use case I can imagine is for some tool that wants to generate or rewrite Dart code based on markers in...
I'm curious about what the analyzer is currently doing for function types. Given the following example: ``` void foo({@deprecated int x = 3}) {} void main() { foo(x : 3);...
> In your example the annotation is being handled because it's on a function declaration's parameter. But when the annotation is on the parameter of a function type, it isn't...
> I just don't know what it means to have an annotation on a field (or parameter, for that matter) of a structural type. I don't think it means anything....
> Extrapolating from this, I would (naively) expect the following behavior: > > ```dart > ({@deprecated int z}) baz() => (z : 3); > > void main() { > {...
> If that's not the desired behavior, then we have a bug. Stepping back, I think I would say that it's up to you to decide whether or not you...
I guess one (unfortunate) option is to disambiguate based on space. `@foo(...)` is an annotation constructor call, `@foo (...)` is an annotated record type. We'd want to be sure that...