proposal: deprecate (and remove?) lints for 3.0

[pq]

3.0 would be a good time to deprecate a host of lints that don't make sense in a null-safe world, are backed by stale advice or a have poor user experience (e.g., too many false positives).

• ✅ deprecate: always_require_non_null_named_parameters [recommended]
• ✅ deprecate: avoid_returning_null_for_future
• ✅ deprecate: avoid_returning_null
• ✅ deprecate prefer_equal_for_default_values [recommended] (analyzer now produces a diagnostic)
• Deprecate iterable_contains_unrelated_type and list_remove_unrelated_type #58958 [core] (DELAYED)
• 🤔 deprecate avoid_annotating_with_dynamic
• deprecate: null_closures [recommended] (DECISION: still valuable)

We might also take this opportunity to deprecate lints that we no longer want to support.

[srawlins]

null_closures is still necessary in Dart 3.0. For example, Iterable.firstWhere's orElse parameter is nullable.

[pq]

Good catch @srawlins! We should also update the docs (and implementation) to reflect SDK API changes?

null_closures docs:

This rule only catches null literals being passed where closures are expected in the following locations:

Constructors
From dart:async
Future at the 0th positional parameter
Future.microtask at the 0th positional parameter
Future.sync at the 0th positional parameter
Timer at the 0th positional parameter
Timer.periodic at the 1st positional parameter
From dart:core
List.generate at the 1st positional parameter
Static functions
From dart:async
scheduleMicrotask at the 0th positional parameter
Future.doWhile at the 0th positional parameter
Future.forEach at the 0th positional parameter
Future.wait at the named parameter cleanup
Timer.run at the 0th positional parameter
Instance methods
From dart:async
Future.then at the 0th positional parameter
Future.complete at the 0th positional parameter
From dart:collection
Queue.removeWhere at the 0th positional parameter
`Queue.retain
Iterable.firstWhere at the 0th positional parameter, and the named parameter orElse
Iterable.forEach at the 0th positional parameter
Iterable.fold at the 1st positional parameter
Iterable.lastWhere at the 0th positional parameter, and the named parameter orElse
Iterable.map at the 0th positional parameter
Iterable.reduce at the 0th positional parameter
Iterable.singleWhere at the 0th positional parameter, and the named parameter orElse
Iterable.skipWhile at the 0th positional parameter
Iterable.takeWhile at the 0th positional parameter
Iterable.where at the 0th positional parameter
List.removeWhere at the 0th positional parameter
List.retainWhere at the 0th positional parameter
String.replaceAllMapped at the 1st positional parameter
String.replaceFirstMapped at the 1st positional parameter
String.splitMapJoin at the named parameters onMatch and onNonMatch

[srawlins]

Thanks for the idea, @pq ! I audited the rule and found it could be dramatically simplified for null safety. dart-archive/linter#3918

[srawlins]

Can we just delete these for 3.0?

[bwilkerson]

My understanding is that users would only see deprecation notices if they use one of the 3.0-dev releases. I don't know how common that will be, but that's the only reason I can think of to go through a deprecation period.

[srawlins]

I don't know why it would be meaningful to provide a deprecation period. The action-to-take is the same for a deprecated linter rule as a deleted one (remove the reference). And the consequence of using a deprecated linter rule is the same as the consequence of using a deleted one (a Hint in your analysis_options.yaml file).

I think they can just be deleted.

[pq]

And the consequence of using a deprecated linter rule is the same as the consequence of using a deleted one (a Hint in your analysis_options.yaml file).

This is true for lints that don't have behavior (for example ones that are short-circuited in the presence of null-safety or language version like prefer_equal_for_default_values) but not otherwise. A deprecate lint can still fire ...

[srawlins]

That's true.

[pq]

#58988 suggests we might consider deprecating avoid_annotating_with_dynamic too.

/fyi @munificent

[pq]

Remaining work is picked up in dart-lang/core#789. Closing out.