Consider a lint warning on uses of the null check operator on variables of type T?

[leafpetersen]

Given a generic type parameter T which has a nullable bound (e.g. the default bound of Object?), it is very easy to introduce erroneous null checks when working with a variable of type T?. Specifically, it is not uncommon to have T? x; and want to assert that x has been set to a valid value of type T. A common mistake is to do so using x!. This is almost always incorrect, since if T is a nullable type, x may validly hold null as a value of type T. Example:

T run<T>(T callback()) {
  T? result;
   (() { result = callback(); })();
  return result!;
}

void test() {
   assert(run<int?>(() => null) == null);  // Erroneously throws an error
}

A recommended pattern for writing this code is to instead to cast to T:

T run<T>(T callback()) {
  T? result;
   (() { result = callback(); })();
  return result as T;
}

void test() {
   assert(run<int?>(() => null) == null);  // succeeds
}

I think the conditions under which the lint would fire would be:

• If the null check operator is applied to something of type T?
• And T is a generic type parameter
• And the bound of T is potentially nullable

cc @Hixie @matanlurey @lrhn @munificent @eernstg @natebosch @jakemac53 for any thoughts on this.

[leafpetersen]

cc @bwilkerson

[eernstg]

And the bound of T is potentially nullable

This might be a bit too inclusive: If a non-ending ! is used to enable a member access then it is actually a null test:

bool run<T extends int?>(T callback()) {
  T? result;
   (() { result = callback(); })();
  return result!.isEven;
}

Maybe it's sufficient to say that the lint only applies when there is no member access after !?

[justinmc]

I ran into a sort of false positive of this warning on this line: https://github.com/flutter/flutter/blob/d6c841d47cbd7e45e2a997385236ed935f5a5bee/packages/flutter/lib/src/widgets/autocomplete.dart#L449

I was pretty confused about what the warning meant overall, but after having nullable type params explained to me I think it makes sense, and I shouldn't have trouble with it in the future. If there are any docs/articles about nullable type params though, maybe we should consider linking to them.