Adjust documentation of prefer_void_to_null

[eernstg]

The lint prefer_void_to_null has a very concise motivation section. #58906 raised the issue that it isn't helpful to recommend that a local variable of type Null is changed such that the type is void. An extended motivation section could clarify more broadly in which situations the lint is useful.

Another part of the documentation that needs an update is at the end:

empty literals which are safe to pass into read-only locations for any type of map or list

Today, with null safety, such collection literals should have the actual type argument Never (like const <Never>[]). The type argument could also be Null, but the collection would then only be usable when the required type has a nullable type argument.

Note that a type variable is never a nullable type, which means that <Null>[] could never be passed when the required type is List<X> where X is a type variable; this seems to make <Null>[] nearly useless as a "universal empty list", so we probably don't even want to mention <Null>[] in the documentation for this lint.

[pq]

This is great. Thank you! (A PR would be more than welcome too! 😉)

[eernstg]

I can see that the lint was created by @MichaelRFairhurst.

@MichaelRFairhurst, I know you've moved on, but it would be great if you could comment a little bit on important situations flagged by this lint!

I think Future<Null> that ought to be Future<void> is a good example, and perhaps T<... Null ...> that ought to be T<... void ...> for any T, but even in those cases it isn't obvious to me how it is possible to detect that the use of Null is actually not a good choice. For example:

class OperationThatMayFail {
  Future<Object?> doit() async {...} // The result is an error specification, null means 'no issues'.
}

class OperationThatWillNeverFail extends OperationThatMayFail {
  Future<Null> doit() async {...} // No need to check whether there are any issues.
}