clarify semantics of unspecified bounds under nnbd

[sigmundch]

Pre null-safety, missing a type bound meant that the bound was treated as dynamic. With NNBD, we weren't sure whether this is the semantics we want. We are worried that doing so might be more breaking than intended. Instead, we were hoping that we could update the semantics to say that the default bound is Object in opt-out code and Object? in opt-in code.

In particular, consider these four functions:

// from an opted-out library:
T fo1<T>(T t);
T fo2<T extends Object>(T t); // bound is Object*

// from an opted-in library:
T fi3<T>(T t);
T fi4<T extends Object?>(T t);

Pre-nnbd, fo1.runtimeType == fo2.runtimeType, post-nnbd this would be false if we continue to use dynamic as the default bound. It would however mean that fo1.runtimeType == fi3.runtimeType

With the semantics suggested above we'd preserve that fo1.runtimeType == fo2.runtimeType and have also that fi3.runtimeType == fi4.runtimeType. Here we no longer get fo1.runtimeType == fi3.runtimeType, which we think it's ok.

@leafpetersen @eernstg @lrhn @munificent - WDYT?

/cc @nshahan @Markzipan @fishythefish

[eernstg]

We have actually specified (pre-nnbd) that a type variable bound 'is considered to be the built-in class \code{Object} if no bound is specified.'

If we had said dynamic it would change the treatment of the body of the generic declaration, for instance:

// Thought experiment, where pre-nnbd bounds would be `dynamic` by default.
class C<X extends dynamic> { // So a missing bound would work like this.
  void foo(X x) {
    x.whatever(); // OK, but it would be an error with `X extends Object`.
  }
}

The instantiation to bound algorithm would choose dynamic when it encountered an omitted bound, so clients would see it. This hasn't changed.

The nnbd spec specifies that the bound of a type variable declaration with no bound in opted-in code is Object?.

In opted-out code, it must be Object* (again: it is treated as if we had written Object): I see no language in the nnbd spec about changes, so we use the current language specification and interpret the old rule (that it is Object) in an nnbd context.

With that, the declarations fo1 and fo2 from here are equivalent, and so are the declarations fi3 and fi4. The function type would be T* Function<T extends Object*>(T*) and T Function<T extends Object?>(T), respectively.

With respect to the result returned from operator == of reified types, we have new rules as well:

Consider the underlying type, normalize it, erase *, then compare syntactically (of course, for instance, we must consider p.C and C to be syntactically equal if and only if they denote the same class declaration, so 'syntactically' can't be taken completely literally).

In the concrete case, the fact that fo1.runtimeType == fo2.runtimeType evaluates to true follows directly, and so does fi3.runtimeType == fi4.runtimeType.

For fo1.runtimeType == fi3.runtimeType the result is false, as you mention.

This could actually be a problem: There is no nnbd type whose behavior matches T* Function<T extends Object*>(T*) better than T Function<T extends Object?>(T), and still we claim that they are different. Conversely, the behavior of T* Function<T extends Object*>(T*) is actually not the same as that of T Function<T extends Object>(T), and still operator == claims that those two types are the same.

I suspect that it would be pragmatically better to use mutual subtyping (which is by the way what the language specification currently says): t1 == t2 evaluates to true, when t1 as well as t2 are instances of Type obtained as a reification of a type, iff the underlying types are T1 and T2, and T1 <: T2 as well as T2 <: T1.

[eernstg]

Cf. #821.

[sigmundch]

Thanks for the detailed response! We'll move ahead under the assumption that we use Object* and Object? for the default bounds on opted-out and opt-in libraries, respectively, then.

I have some concerns about using mutual subtyping for equating type objects, I'll comment more on #821 shortly.

[leafpetersen]

I landed the change here making the type equality used for generic function bound subtyping use mutual subtyping. In Dart 3, we should be able to change this to use normalization.

I agree with the choice of using Object* and Object? for the default bounds.

[lrhn]

I don't particularly worry about people checking the .runtimeType of functions for equality. It's more likely that they'll print it for debugging.

I do not think anyone has implemented mutual subtype based equality.

import"dart:async";
void foo<T extends FutureOr<Object>>(T x){}
void bar<T extends Object>(T x){}
void baz<T>(T x){}
main() {
  print(foo.runtimeType);
  print(bar.runtimeType);
  print(baz.runtimeType);
  print(foo.runtimeType == bar.runtimeType);  // false in VM and dart2js
  print(foo.runtimeType == baz.runtimeType);  // false in VM and dar2js
  print(bar.runtimeType == baz.runtimeType);  // false in VM, true in dart2js
}

As usual, an equality based on mutual subtyping will have a hard time computing a compatible hash code, so I'll also not expect anyone to implement it.

The "same type" requirement for type variable bounds in Dart 2 was always underspecified. Using normalization everywhere, even in pre-null safety code, would probably be an overall improvement.

[leafpetersen]

@lrhn You example doesn't actually exercise the mutual subtyping part of subtyping. Runtime type object equality is not defined using mutual subtyping, it's defined using normalization + legacy erasure.

Subtyping is defined using mutual subtyping (though I think we could choose to define it using normalization + legacy erasure instead). To test this, use

typedef F = void Function<T extends Object>(T);

....

print(foo is F);
print(bar is F);
print(baz is F);

instead. DDC seems to implement this correctly, as does the analyzer if I build the corresponding static check (assign foo, bar, baz to something of type F).

[leafpetersen]

I believe this is resolved.