import 'package:intl/intl.dart';
import 'package:intl/message_lookup_by_library.dart';
import 'en_short_messages.dart' deferred as en_short;
import 'es_messages.dart' deferred as es;
import 'es_short_messages.dart' deferred as es_short;
import 'fr_messages.dart' deferred as fr;
import 'ja_messages.dart' deferred as ja;
import 'zh_CN_messages.dart' deferred as zh_cn;
import 'zh_messages.dart' deferred as zh;
//typedef Future<dynamic> LoadLibrary();
typedef dynamic LoadLibrary();
Map<String, LoadLibrary> _deferredLibraries = {
'en_short': en_short.loadLibrary,
'es': es.loadLibrary,
'es_short': es_short.loadLibrary,
'fr': fr.loadLibrary,
'ja': ja.loadLibrary,
'zh_CN': zh_cn.loadLibrary,
'zh': zh.loadLibrary
};
[ ] compiler message: file:///Users/zoechi/dart/customers/lookatyou/lookatmybaby/timeago.dart/lib/src/i18/messages_all.dart:21:12: Error: The top level function has type '() → dynamic' that isn't of expected type '() → dart.async::Future<dynamic>'.
[ ] compiler message: Change the type of the function or the context in which it is used.
[ ] compiler message: 'es': es.loadLibrary,
md5-10c852930b4af33b2b8c9a1b1cca8e28
Flutter 0.2.2-pre.4 • channel dev • https://github.com/flutter/flutter.git
Framework • revision ce75b44760 (4 hours ago) • 2018-03-20 07:48:43 +0100
Engine • revision e61bb9ac3a
Tools • Dart 2.0.0-dev.35.flutter-290c576264
Is this intentional or a bug?
It's unlikely to be intentional at the language level.
The Dart 1 spec says:
loadLibrary. This method returns a future
f.
It does not say what the static type of loadLibrary is or what the static type of the invocation is.
However, since it does say that the method returns a Future, it is reasonable to assume that it is typed as such. I'd say that this is a bug, and the static and dynamic type of the loadLibrary method should be Future<void> Function() (or Future<dynamic> if the void is too breaking).
I'm not sure when exactly that behavior changed.
I switched to --preview-dart-2 a week ago or so, and it didn't cause an issue until today, but it was not flutter upgrade that caused it, but flutter clean.
So it might be that I had got this error a week ago already if I had run flutter clean back then.
(I run flutter clean today because some code changes didn't reflect in the running app)
I'm not seeing an issue with that in bleeding edge running the Intl code standalone. It's possible that it's already been fixed, or that there's something different happening with Flutter.
@alan-knight thanks. Todays Flutter dev update ships with Dart 2.0.0-dev.39.0.flutter-06949dc985 and doesn't reproduce anymore.
It's still the same with
Flutter 0.2.2-pre.5 • channel dev • https://github.com/flutter/flutter.git
Framework • revision 0608a7a2cc (2 hours ago) • 2018-03-23 11:10:37 +0100
Engine • revision 6280adbfb1
Tools • Dart 2.0.0-dev.39.0.flutter-06949dc985
I'll keep watching if it works with newer Dart versions.
The app still runs fine so far, so this doesn't cause real troubles currently.
It's still the same with
Flutter 0.2.2-pre.6 • channel dev • https://github.com/flutter/flutter.git
Framework • revision 972ff23c4c (19 hours ago) • 2018-03-30 18:15:04 +0200
Engine • revision 9af82c5a1a
Tools • Dart 2.0.0-dev.43.0.flutter-e305117519
but I get these errors only once after flutter clean (was the same before, just forgot to mention it)
OK, we dug a little deeper and think we know the issue.
Just send a possible fix to the FE team here: https://dart-review.googlesource.com/c/sdk/+/49042
This error is now gone with
Flutter 0.2.12-pre.34 • channel master • https://github.com/flutter/flutter.git
Framework • revision 6c049ec286 (12 hours ago) • 2018-04-15 19:24:49 -0700
Engine • revision 76cb311d9c
Tools • Dart 2.0.0-dev.47.0.flutter-f76dad0adc
Thanks!