prefer_void_to_null shouldn't lint for local variables.

[asashour]

Describe the issue
prefer_void_to_null should not be triggered for local variable.

The reason is: local variable can not be void.

To Reproduce

void f() {
  Null a; 
  a.toString();
}

Expected behavior
There is no lint.

[eernstg]

Agreed. However, note that a variable can actually have the type void:

void global;

void main() {
  void local = "Whatever!"; // OK.
  var other = local; // OK, and `other` has type `void` as well.
  local.toString(); // Compile-time error, can't use a value of type `void`.
  print(global); // Same error.
  print(global as Object?); // OK.
}

Apart from casting away the type void, we basically can't use a variable of type void for anything at all. This means that such variables are basically useless (the fact that you have a variable says "I want to store this value", and the type void says "I'm never going to use this value", which is a contradiction).

However, a variable of type Null is also almost useless (when the type is Null, the only possible value is null, so the information provided by storing and retrieving it is zero).

However, void and Null are completely different types: void is a top type with special static treatment ("discard this object"), and Null is a near-bottom singleton type. The type Null is threaded through the type system just like any other type, but the special static treatment of void is limited to first-order cases (so print(global) is an error, but print([global]) is OK, because there is nothing special about using a value of type List<void>, and the body of List doesn't care that the actual type argument might be void).

The lint was probably motivated by some very specific usages (in particular, using Future<Null> in a situation where a computation could reasonably be awaited, but the result would not be of any interest; in that situation it makes sense to use Future<void> rather than Future<Null>, but until Dart 2.0, void was not a full-fledged type and Future<void> was a syntax error).

I'd recommend that this lint should tentatively be disabled for any situation where we're unable to explain how the advice given by this lint is useful. In particular, there's no need to lint Null a;, and there may be any number of other "false positives" over time.

Does anyone know how to characterize a substantial set of situations where this lint is helpful? Are there any other cases than replacing Future<Null> by Future<void>?