+CC: @mkustermann, @lrhn

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.

@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.

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

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.

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.

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?

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.

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

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.

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

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