Allow generic metadata annotations

[ghost]

Feature specification: https://github.com/dart-lang/language/blob/master/accepted/2.14/small-features-21Q1/feature-specification.md

---

Annotations (metadata) aren't allowed to use type arguments, but it is allowed to make annotations using a const of a type that takes a type argument:

class MyAnnotation<T> {
  const MyAnnotation();
}

const MA = MyAnnotation<String Function(int)>();

@MA  // <- Works.
random(int weather) => '7';

@MyAnnotation<String Function(int)>()  // <- Fails.
alsoRandom(int lucky) => '7';

main() => random(0) + alsoRandom(13);

Gives:

../../annotation_type_generic.dart:10:14: Error: An annotation (metadata) can't use type arguments.
@MyAnnotation<String Function(int)>()
             ^

See also: dart-lang/sdk#44120

[ghost]

+CC: @mkustermann, @lrhn

[eernstg]

This would certainly make sense, and we've discussed it already a long time ago. I'll move this issue to the language repository where it fits better.

[mkustermann]

@eernstg @lrhn It might be really helpful if we could get this soon due to a use case in the VM. The constant evaluator is now in the CFE and shared across backends, so it might not be very hard to support this.

[eernstg]

Maybe you could say a bit more about that use case in the VM and why it is important?

[mkustermann]

Maybe you could say a bit more about that use case in the VM and why it is important?

Sure. We currently have VM-specific syntax in Dart files for specifying natives. That looks e.g. like this:

double sqrt(double arg) native "Math_sqrt";

This uses our old, heavy weight runtime call mechanism.

Now we would like to make it possible to use the new Dart FFI for such natives instead. Possibly even replacing all of our old native calls with faster FFI natives.

Ideally we would do this in a declarative way, just as our natives before.

Though we will need to have a way to specify not only the name of the C function (as above) but also it's signature in C code. One option would be to make them look like this:

import 'dart:ffi';

@Native<Float Function(Float)>("Math_sqrt")
extern double sqrt(double arg);

That would remove the VM-specific native "foo"-syntax as well as allowing us to use declaratively specific FFI natives with the corresponding C function signature.

[eernstg]

OK, thanks! It would still be possible to use

const native431 = Native<Float Function(Float)>("Math_sqrt");
@native431
extern double sqrt(double arg);

but it is obviously more convenient to avoid the intermediate constant variable, and the need to invent a name for it.

[johnniwinther]

From the CFE point of view it seems we can support this by just not emitting the error, i.e. by removing one 3-line if-statement. This would also remove the error from the analyzer, but I don't know if more work is needed on the analyzer side. @scheglov Do you if more work is needed on the analyzer side?

[scheglov]

Yes, it will require some work in the analyzer. The class Annotation does not have typeArguments yet, only arguments that does not have type arguments in it (in contrast to kernel's Arguments). Then evaluation will require some changes. Nothing hard though.

[mkustermann]

@leafpetersen @munificent @lrhn Could you discuss this in next language meeting? Making this small change would get us unblocked.

[leafpetersen]

This seems fine by me. I think this would be a good candidate for the small and useful features release - it would be good to have it guarded by a language version to avoid breaking on old SDKs.

[ghost]

What kind of timeline are we roughly looking at for this to land?

[mit-mit]

@cskau-g @mkustermann is the workaround Erik described sufficient to get you started?

[mkustermann]

Is the workaround Erik described sufficient to get you started?

We knew about the workaround even before filing the issue and of course it works for prototyping. Though I think we should not go ahead start mass migrating dart:* libraries using this hack.

@mit-mit Is there any concrete reason for not just going ahead with this little change: putting it into the spec and getting it implemented?

[mit-mit]

No, we're going to try and build a tentative plan for this. I was just checking.

[leafpetersen]

This is available in beta, and will be in the next stable.

[hellohuanlin]

For some reason I am still seeing this issue when building flutter engine:

$  ninja -C out/host_debug_unopt

../../flutter/third_party/tonic/tests/fixtures/tonic_test.dart:152:13: Error: An annotation can't use type arguments.
  @FfiNative<Handle Function(Pointer<Void>, Int64)>(

I have tried both --prebuilt-dart-sdk and --no-prebuilt-dart-sdk and neither worked 😦

[munificent]

I can't repro the problem with a local build of the Dart SDK. My guess is that this is something specific to how the Flutter engine is setup or which version of the Dart SDK it has (though I'm fairly certain it should have this feature by now). I think you'll probably have better luck asking on the Flutter team if they've seen this problem, and I suspect they won't see the comment on this issue.