dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.31k stars 1.59k forks source link

always_specify_types forces to redundancy when lists/maps #58062

Open dvorapa opened 5 years ago

dvorapa commented 5 years ago

Describe the issue always_specify_types reports also lines like: List<String> listOfStr = [];

But if I fix it, I feel the fixed version contains redundant code and makes code more cluttered: List<String> listOfStr = <String>[];

There is no way to have something like:

List<String> listOfStr = <int>[];
List<int> listOfStr = <String>[];

To Reproduce List<String> listOfStr = [];

$ flutter analyze
   info • Specify type annotations • lib/main.dart:1441:23 • always_specify_types

Expected behavior Perhaps this is dart specification issue as well, as this redundant typing seems wrong to me. I will ignore this rule and continue to use: List<String> = []; But maybe better option would be: List = <String>[]; Or perhaps a completely different syntax (because semantically this still seems not complete), like (just a proposal): List = []<String>;

Additional context Latest stable Flutter v1.9.1+h6 with Dart 2.5.0

corcoran commented 4 years ago

Seconded, this is incredibly irritating and clutters up the code with unnecessary redundancy

dvorapa commented 4 years ago

Perhaps this is a issue of https://github.com/dart-lang/language?

dvorapa commented 4 years ago

Perhaps this is a issue of https://github.com/dart-lang/language?

It seems it does not as in https://dart.dev/guides/language/sound-problems#invalid-casts it specifically says List<String> listOfStr = []; is correct.

bwilkerson commented 4 years ago

The rule should not produce a lint for a line of code of the form

List<String> listOfStr = [];

As you noted, the line of code above is equivalent to

List<String> listOfStr = <String>[];

Perhaps this is dart specification issue as well, as this redundant typing seems wrong to me.

The language specification doesn't say anything about needing type argument as part of the list literal. The problem is that the lint rule was written before type inference was able to infer the element type of the list. It used to be necessary to include the type argument, but no longer is, and the rule just needs to be updated.

One additional comment about an alternative you proposed:

List listOfStr = <String>[];

That won't do what you want it to do. The language specification currently defines that to be equivalent to

List<dynamic> listOfStr = <String>[];

However, the following code will also produce the same semantics as what you currently have:

var listOfStr = <String>[];

The type of listOfStr will be List<String>.

DanMossa commented 3 years ago

Has there been any update on this? I created a stackoverflow question and then I found this.

m-terlinde commented 3 years ago

Hey guys,

is there anything new on this? This linting rule just created like 500 FP issues in our project :D.

But we fell bad to deactivate this rule entirely.

Thanks, Matthias

srawlins commented 3 years ago

There are other rules that might be better than always_specify_types if you're hitting this issue. There is the strict-raw-types mode, the strict-inference mode, type_annotate_public_apis lint rule, and always_declare_return_types lint rule.

walkerford commented 3 years ago

There are other rules that might be better than always_specify_types if you're hitting this issue. There is the strict-raw-types mode, the strict-inference mode, type_annotate_public_apis lint rule, and always_declare_return_types lint rule.

Thank you for sharing this insight. strict-inference mode produced the warning that I was looking for, which is to warn when a generic type has not been specified.

srawlins commented 2 years ago

Also, this rule only exists for the flutter repository. The text in the style guide for the flutter repo has also drifted from the quote in the always_specify_types docs. 🤷 I don't see this rule changing unless the flutter team requests this fix.