Analyzer and CFE disagree on inferred Future.value type with nullable argument

[srawlins]

Take this code:

Object? f(int? x) { return Future.value(x)..foo; }

void main() {
  print(f(null));
}

• Analyzer says: "The getter 'foo' isn't defined for the type 'Future<int>'."
• CFE says: "Error: The getter 'foo' isn't defined for the class 'Future<int?>'."

Who is correct? It would be less breaking to change analyzer's behavior 😁

This is a blocker for implementing dart-lang/sdk#53253. As things stand, the analyzer would report a new Warning, claiming that a nullable value, x should not be passed to Future<int>.value, but there is actually no error thrown at runtime, so it should always be OK to pass this nullable value.

[srawlins]

CC @dart-lang/language-team

[natebosch]

Who is correct?

Both are - The getter isn't defined for either of those types 😉

I don't see a reason that it should be inferred as Future<int> though - the CFE error makes more sense to me.

Edit: I forgot about the nullable argument to Future.value so it's not clear to me that CFE is more correct.
Is this an example of #3269 ?

[srawlins]

Is this an example of #3269 ?

I don't think this is tightly related, because downward inference gives no info in this case. However, as @eernstg says over there:

we could choose to say that X must be a subtype of T, or that X must be a subtype of T?.

This might be the same choice? I think it's essentially:

• The Future.value constructor has a return type of Future<T>.
• The context type is Object? (same issue if context type is Object).
• It has a FutureOr<T>? parameter.
• The argument for that parameter has type int?.

Luckily for me, I'm not looking for a language change. I'm just looking to figure out which implementation is not spec-compliant :D.

[lrhn]

The "Who is right" should be answered by the inference specification. In particular which, if I read it correctly, means that the only introduced constraint is _ <: T <: int.
Then, when we solve that for T, the result becomes int.

So, analyzer is correct, as I read it.

[leafpetersen]

I agree with @lrhn - the analyzer is correct here.

[eernstg]

@natebosch wrote:

Is this an example of #3269 ?

#3269 refers to the same inference rule, here, and it would be applicable during downward inference as well as upward inference. It seems fair to say that the two issues are at least closely related.

[srawlins]

Resolved.