consider adding `strict_top_level_inference`

[devoncarew]

We should consider adding a strict_top_level_inference lint, as described here: dart-lang/sdk#59562. Note that this lint does not yet exist.

This lint would warn about every omitted return type, parameter type, and variable type of a top-level declaration or class-like-namespace-level declaration (static or instance member- or constructor declaration), which is not given a type by inference, and which therefore defaults to dynamic.

[goderbauer]

I am in favor of this to get rid of more (implicit) dynamics.

[devoncarew]

Some details:

• originally landed in Dec 2024; it shipped in 3.7 stable
• it’s been used in the dart_flutter_team_lints set; most feedback was around wildcards
• it does have a quick fix?

cc @srawlins to keep me honest for the above

@natebosch, @lrhn, @chunhtai - can you review this lint? This was one we'd requested, so I'd guess mostly we'd be considering if there are any open issues to address, timing of landing it, which lint set, ... But feel free to do a general review.

[lrhn]

I like it. It's a way to avoid accidental dynamic in top-level declarations.

The wildcard parameters should probably be exempt. Then 👍.

[chunhtai]

yeah I am also onboard with this, dynamic can be dangerous in some cases.

[natebosch]

I am in favor of including this lint in the recommended set as it is currently implemented.

The wildcard parameters should probably be exempt. Then 👍.

I initially leaned towards exempting wildcard parameters too, but I was convinced by you that it was better not to make them exempt 😄

dart-lang/sdk#59562 (comment)

Can a wildcard parameter have an omitted type?

I'd say no. This is not about having a type inside the function, so whether the parameter can be referenced or not doesn't matter. It's about making sure that the parameter has a type in the API, and doesn't default to dynamic.

[natebosch]

Oh, but we also changed course on that and wildcards are exempt now?

dart-lang/sdk@d5981ad

That's also fine and I'm happy to still include the lint as it is currently implemented 😄

[srawlins]

Yes, the lint rule does have a quick fix. The lint rule shipped in Dart 3.7.

[devoncarew]

After discussion we do want to add this to our lint sets, and into the core set (so, this will affect a package's pub score).

We also do want a bit more user feedback on this one (anything unexpected in the implementation?), so will likely ask the community to try it out.

[parlough]

I'm all for this inclusion! However:

We also do want a bit more user feedback on this one (anything unexpected in the implementation?), so will likely ask the community to try it out.

Perhaps it should be in the recommended set for a cycle alongside an announcement of its eventual graduation to core?