Open srawlins opened 3 years ago
@scheglov if the analyzer should not be reporting that return statement in f1
, I can fix in ReturnTypeVerifier; I'm poking around there now.
It is a bit odd, but it does follow the specification, here: Only void
, dynamic
and Null
allow for return;
. We have some null safety related updates about returns here, but the return;
rule is unchanged.
So it's currently not a bug, it is working as intended. If you wish to make it a bug then it should be handled as a language proposal.
Note that the type FutureOr<void>
is inherently questionable: FutureOr
is an untagged union (like Future<void> | void
), but the void
type admits any object whatsoever, including futures. This means that there is no safe way to determine which case we have for a value of type FutureOr<void>
: If it is not a future then it's the case void
(so we should ignore and discard the value), but if it is a Future<T>
for some T
then it could be intended to be used as a future, or it could be intended as a void
value that the caller should discard.
For anyone who wishes to make a distinction between a value of no interest and a future (so the future "may or may not be there"), the type Future<T>?
is a much better match: It can be detected whether the given object is null or a future.
Thanks so much for the explanation, @eernstg !
Still not reported.
See these two functions, each in null safe code:
A bit odd. I assume the
return_without_value
report is erroneous.