Function signature interface

[mosuem]

In Dart, we can tell other users of a library that they should create a class with certain methods by providing an interface. We can't tell users to create a function with certain arguments.

A use case is something like Cloud Functions, where we know the top-level function must have a certain signature (in that case accepting an HttpRequest), but have no good way of expressing that so far in our type system or through language features.

Basically, a solution to this would be

typedef CloudFunction = void Function(HttpRequest);

void foo(HttpRequest request) implements CloudFunction {
 ...
}

As this is probably quite complex, a smaller step or help would be to add a signature to TargetKind, as proposed in https://dart-review.googlesource.com/c/sdk/+/442740.

This is not as good, as it only shows what is going wrong, not providing much info as to what would be right as class interfaces do with giving users a quick fix to add missing methods, but would still be better than failing at runtime.

cc @srawlins

[lrhn]

If the goal is to give the user a signature that they can add to their declaration to ensure that their declaration is correct (for some purpose), then it's true that there is no way to do that for a top-level function declaration.
A top-level declaration is a stand-alone declaration, there are no inherited constraints on it from the context, and there is no way to write constraints on a single declaration in general.

Or rather, you could, but it's non-idiomatic to write:

final CloudFunction foo = (HttpRequest) { ... };

so we probably don't want to force users to do that.

This feels like a very specialized need. You require some kind of code-generation or reflection to have an indirect use of the function indirectly, which isn't in the program itself where the use would be type-checked.
If user code is passing the function to an API as a value, that API will have a function signature, and you'll get an error if the function doesn't satisfy that.

Code generation is extra code that runs anyway, so it can also check that the function's signature is acceptable.

Reflection isn't typed to begin with, so not much we can do with that.

I think an annotation with a check on the side is much more viable than any language feature would ever be.

[FMorschel]

Maybe this language suggestion is what you were looking for? Or similar ones.

• Allow Function getters to be overriden as actual functions #4159