Funny upper bound computed with the iterable of a 'for-in' statement

[eernstg]

Consider the following example:

void main() {
  for (var _ in ([] as Object)) {} // Error.
}

This incurs the compile-time error "The type 'Object' used in the 'for' loop must implement 'Iterable'". That's fine. However consider this variant:

void main() {
  final List<int>? list = [];
  for (var v in list ?? {}) {
    v.expectStaticType<Exactly<Object?>>();
    v.argleBargle; // Error shows `v` does not have type `dynamic`.
    var w = list ?? {};
    bool b = w; // Error message says `w` has type 'Object'.
  }
}

typedef Exactly<X> = X Function(X);
extension<X> on X { X expectStaticType<Y extends Exactly<X>>() => this; }

If v does indeed have the inferred declared type Object? then the iterable list ?? {} should be inferred to a type that implements Iterable<Object?>. However, I'd expect the standard upper bound of List<int> and Set<T> where T is any type except int to be Object, not Iterable<Object?>. So I'd expect an error in the for statement, just like the one we got in the first example.

I know the inference of ?? is tricky, so I may well have gotten something wrong, but other than that I do think it looks like a bug.

[eernstg]

I added one more element to the code:

void main() {
  final List<int>? list = [];
  for (var v in (list ?? {})..expectStaticType<Exactly<Iterable<Object?>>>()) { // OK.
    // ...
  }
}

This illustrates that list ?? {} is indeed inferred (with context type Iterable<_>) to have type Iterable<Object?>. This is still surprising because I'd expect {} to be inferred as <T>{} where T is a top type, with type Set<T> (it should be Set<Object?>, but it might still be Set<dynamic>), and that should still yield the upper bound Object rather than Iterable<Object?>, so we should still get that error.

Another double check: I can't find any updates about the type of an expression e of the form e1 ?? e2 in any feature specification, so it's presumably still the rule in the language specification that applies:

The static type of e is the least upper bound (20.10.2) of the static type of e1 and the static type of e2.

Again, the confusing part here is that this least upper bound is Object, but it is treated as if it were Iterable<Object?> such that the elements get the type Object?.

[FMorschel]

Consider:

void main() {
  final List<int>? list = [];
  for (var v in list ?? []) {
    // ...
  }
}

This results in v being dynamic, not Object?, so Iterable<Object?> is still weird because {} in the context of your example above is inferred as Set<dynamic>. So it should be at least Iterable<dynamic>.

[eernstg]

This results in v being dynamic,

I think this can be explained: With list ?? [] with context type schema Iterable<_>, the right operand will have that context. [] is then inferred as <dynamic>[] (this should be <Object?>[], but that's not fully implemented). The ?? expression will then have type StandardUpperBound(List<int>, List<dynamic>) which is List<dynamic>, and hence v gets the type dynamic.

[lrhn]

The list ?? {} does an UP of List<int> and Set<dynamic> with a context type of Iterable<_>. It correctly infers {}`.

For the UP of List<int> and List<dynamic>, that's List<dynamic> directly in the UP rules - same generic type, UP of type parameters sees that they are related and uses the one that is a supertype of the other. We never reach the LUB algorithm.

For List<int> and Set<dynamic> we do reach LUB, and it gives Object. However, both are assignable to the context Iterable<_>, so we use @stereotype441's context-aware upper bound instead.

That use the greatest closure of the context type scheme. The greatest closure of Iterable<_> is Iterable<Object?>.
From the implementation of that upper bound:

  /// Finds the nearest type that doesn't involve the unknown type (`_`).
  ///
  /// If [covariant] is `true`, a supertype will be returned (replacing `_` with
  /// `Object?`); otherwise a subtype will be returned (replacing `_` with
  /// `Never`).
  Type? closureWithRespectToUnknown({required bool covariant});

and the implementation of that method for UnknownType does just that.

That is, it uses Object? to fill in covariant blanks instead of instantiating to bounds. The instantiate to bounds algorithm is the one that introduces dynamic as default for type parameters with no bound.

(Also, nice! No need to introduce new dynamics in new inference rules if we can just use Object? from the start.)

On the other hand, if the context type had been SomeType<_> where SomeType's type parameter had a bound, maybe it should have instantiated to that.

class A<T extends num> {}
class B1 extends A<int> {}
class B2 extends A<double> {}
void foo<T extends num>(A<T> _) {
  print(T);
}
void main() {
  var b = DateTime.now().millisecondsSinceEpoch > 0;
  foo(b ? B1() : B2()); // Error: The argument type 'A<dynamic>' can't be assigned to the parameter type 'A<num>'.
}

Here the greatest closure of the context type becomes A<dynamic> (not A<Object?>?), but the actual context is limited by A<num>.
I don't know why we can't see that. I guess if the context type scheme is A<_>, we don't have the information when we reach _. If the context type scheme is A<T>, but we're not solving for T, only removing _s, then it also doesn't work

It's not unique to this case, just doing:

  foo(expr(B1()));
}
T expr<T>([Object? v]) => v as T;

gives the error

Error: The argument type 'A<Object?>' can't be assigned to the parameter type 'A<num>'.

That is, given a context type of A<T> where T extends num, the function T expr<T>(...){} infers A<Object?>, the "greatest closure" of the context type scheme, suggesting that the context type scheme is actually A<_> with no bounds information.

Could we not throw away bounds information when finding the greatest closure of a generic type?
(Or at least not unless they're F-bounded or something else that makes us have to give up on a well-bounded result. Like what instantiate-to-bounds does, only with variance where the contravariant version inserts Never.)

And another example where we throw away information (but probably harder to solve):

void foo<T extends num>(void Function<S extends T>()? _) {}

T id<T>([Object? v]) {
  print("id<$T>");
  return v as T;
}

void main() {
  foo(id());
}

gives

main.dart:9:7: Error: The argument type 'void Function<S>()?' can't be assigned to the parameter type 'void Function<S extends num>()?'.
  foo(id());
      ^

We solve void Function<S extends T>() by choosing T = dynamic, even if T has a bound.
If we had chosen the bound of T, void Functioon<S extends num>(), then we could also have solved
for T in the call to foo as foo<num>(id<void Function<S extends num>()?>()).