Avoid implicit dynamic typing.

[knaeckeKami]

When using this library in a project with stronger static type settings, like

strict-inference: true or

implicit:dynamic: false

the code generated by this library produces analysis errors.

Generated methods like this:

  static m5(howMany) => "${Intl.plural(howMany, one: '...', other: '${howMany} ...')}";

Cause the following analysis error:

argument_type_not_assignable: The argument type 'dynamic' cannot be assigned to the parameter type 'num'.

Also the line:

 final messages = _notInlinedMessages(_notInlinedMessages);

causes:

invalid_assignment: A value of type 'dynamic' cannot be assigned to a variable of type Map<String, dynamic>.

Since we cannot exclude the generated files in the analyzer: (https://github.com/dart-lang/sdk/issues/25551 ), this causes annoying error messages.

Either fixing the generated code to user stronger typing or adding

// ignore_for_file: invalid_assignment
// ignore_for_file: argument_type_not_assignable

Should make these errors go away.

[jackyq2015]

seems this only suppress the error for analysis. The build will still fail.

It happens when I tried to migrate my flutter app to flutter web by running:

flutter build web

[awhitford]

pedantic rules complain about this signature:

  static _notInlinedMessages(_) => <String, Function> {
...
  };

because:

The method _notInlinedMessages should have a return type but doesn't.

See always_declare_return_types.

Please update the code generator to include a return type for this method so that I can avoid an analyze issue.

[familan]

I ran into this issue today that knaeckeKami explained concisely four years ago. Strict type checking and less use of 'dynamic' has become a flutter norm nowadays (2024). If the "howMany" argument in Intl.plural() is a required 'int' (or 'num' in some versions), then the generated signature should include the explicit type, so "static String m1(count) => "${Intl.plural(count, ...)}" that is generated now, would become "static String m1(int count) => "${Intl.plural(count, ...)}".

[mosuem]

I also strongly prefer typed interfaced, and am happy to accept PRs. This would be a breaking change, though.