Description
The language specification was updated in dart-lang/language@290b9a6 to specify the signature of the function prefix.loadLibrary which is implicitly induced when prefix is the import prefix of a deferred library. The signature is specified to be Future<void> loadLibrary().
However, the VM and dart2js currently report the signature Future<dynamic> loadLibrary() (and they have had this behavior for years).
The function types of the two signatures are mutual subtypes, so in that sense it doesn't matter. However, void and dynamic are treated differently during static analysis.
The return type Future<void> indicates that it's meaningful to await the completion of the computation performed by loadLibrary (which is true), and that the future is completed with an object that has no meaningful usages—that object should just be ignored (which is also true).
The return type Future<dynamic> indicates that the future is completed with an object whose usage is completely unspecified. That is, you can call any method on it whatsoever, and it might work (which is misleading).
For this reason it seems useful to keep the specification unchanged, and change all tools to use the signature Future<void> loadLibrary(). Currently, as of 09a9a89, the VM and dart2js report Future<dynamic> at run time, and the CFE and the analyzer both use this return type.
@natebosch, @jakemac53, @lrhn, @kallentu, @leafpetersen, @munificent, @stereotype441, WDYT? Do we want to change the tools to get the "nice" signature? If so, does this change require a breaking change procedure? Or do we just change the specification to say dynamic and keep the current behavior?