Description
In #45319 @simolus3 introduced an analyzer Warning that reported when a null
value is (implicitly or explicitly) given as an argument to Future.value()
or Completer.complete()
and the type argument on the Future constructor or Completer instance is non-nullable.
At the end of the conversation he wrote:
I can change it to handle "nullable argument, non-nullable type" too but I'm not sure if it should be a default diagnostic if it can have false positives? In particular, it would warn about
Future.value(x as dynamic)
then.
I think your decision is sound. Later on, we can trigger on nullable arguments either in the same Hint, or with a new Hint (with a different message).
Thinking about this again, 2 years later, I think we should still report the "nullable argument" case (like int? x; Future<int>.value(x);
), and I think we should report it as a default enabled Warning. With the following semantics, I think there are no false positives that diverge from the standard assignability rules, acting as if the parameter was typed FutureOr<T>
rather than FutureOr<T>?
:
- Given a call to
Future<T>.value
(constructor) orCompleter<T>.complete
(method), whereT
is non-nullable:- If the argument type is dynamic, do not report anything.
- If the argument type is potentially nullable, report a Warning.