Question: What is the purpose of this cast?

[nshahan]

I noticed simply tearing off a field that contains a function from a generic class produces an AsExpression node when the function uses the generic type argument in the contravariant position. The evaluation of TypeEnvironment.isSubtypeOf(from, to, SubtypeCheckMode.withNullabilities) evaluates to true but since the cast is marked with the TypeError and CovarianceCheck flags ddc will emit a cast that always seems to pass.

Is this cast necessary and is there an example that would cause this cast to fail?

class GenericType<T> {
  var genericFunction = (T t) => null;
}

main() {
  var generic = GenericType<int>();
  var tearOff = generic.genericFunction;
}

main = tes::main;
library from "org-dartlang-app:/test_02.dart" as tes {

  class GenericType<T extends core::Object? = dynamic> extends core::Object {
    field (tes::GenericType::T%) → core::Null? genericFunction = (tes::GenericType::T% t) → core::Null? => null;
    synthetic constructor •() → tes::GenericType<tes::GenericType::T%>
      : super core::Object::•()
      ;
  }
  static method main() → dynamic {
    tes::GenericType<core::int> generic = new tes::GenericType::•<core::int>();
    (core::int) → core::Null? tearOff = generic.{tes::GenericType::genericFunction} as{TypeError,CovarianceCheck,ForNonNullableByDefault} (core::int) → core::Null?;
  }
}

@johnniwinther @eernstg

[nshahan]

The cast does not appear if the same function is written as a regular class method and you tear it off.

class GenericType<T> {
  Null genericFunction(T t) => null;
}

main() {
  var generic = GenericType<int>();
  var tearOff = generic.genericFunction;
}

main = tes::main;
library from "org-dartlang-app:/test_02.dart" as tes {

  class GenericType<T extends core::Object? = dynamic> extends core::Object {
    synthetic constructor •() → tes::GenericType<tes::GenericType::T%>
      : super core::Object::•()
      ;
    method genericFunction(generic-covariant-impl tes::GenericType::T% t) → core::Null?
      return null;
  }
  static method main() → dynamic {
    tes::GenericType<core::int> generic = new tes::GenericType::•<core::int>();
    (core::int) → core::Null? tearOff = generic.{tes::GenericType::genericFunction};
  }
}

[eernstg]

In the example there is an implicit cast because genericFunction is evaluated, and the type of that variable is contravariant in the type parameter T. It is actually possible to violate soundness if that cast is omitted.

class GenericType<T> {
  var genericFunction = (T t) => null; // Inferred type `Null Function(T)`.
}

main() {
  GenericType<num> generic = GenericType<int>();
  var tearOff = generic.genericFunction; // Subject to a dynamic type check.
  void Function(num) f = tearOff; // Same static type.
  f(3.15);
}

I've changed the example to have an explicitly declared type on the local variablegeneric, and also to make it GenericType<num> rather than the inferred type GenericType<int>.

Dart uses dynamically checked covariance, so C<T1> is a subtype of C<T2> if T1 is a subtype of T2, for any generic class C, and in particular: GenericType<int> is a subtype of GenericType<num>. So the initialization of generic is accepted because the initializing expression has a type which is a subtype of the type of the variable. No problems so far.

However, tearOff gets the inferred type Null Function(num) based on the static type of generic, and that is not a subtype of the dynamic type Null Function(int). Even though we can't see the type of tearOff because it's inferred, we must ensure that it never gets a value which is a violation of its type, so tearOff can't hold a value of type Null Function(int). We can make the type explicit, e.g., with a declaration like f. The initialization of f is accepted because the initializing expression has the same static type as the variable, and the invocation f(3.15) is accepted because f claims to accept any num as an argument.

There are several ways to handle this. The approach taken in Dart is to insert a caller side type check at the point where generic.genericFunction is evaluated, which is the AsExpression mentioned here.

The real solution is to introduce sound variance (declaration site, use site), and using that feature to ensure that GenericType<num> and GenericType<int> are unrelated types rather than subtypes, thus preventing the situation where a variable has the former type and refers to an instance of the latter type.

The situation is similar but not identical if we change the example such that genericFunction is a method:

class GenericType<T> {
  Null genericFunction(T t) => null;
}

main() {
  GenericType<num> generic = GenericType<int>();
  var tearOff = generic.genericFunction;
}

In this case the trade-off needed because of dynamically checked covariance is handled by giving the torn-off method a different type: Null Function(Object). (That's Null Function(Object?) with null safety, but I'm assuming pre-null-safety code everywhere here).

So the function object obtained by tearing off a method whose signature has a type parameter in a contravariant position will have a type that claims that it will accept any object as an argument. The static type of generic.genericFunction is Null Function(num). A dynamic type check will occur when the function is called, but that was also true when the method is called directly (without being torn off first).

The approaches used for the two cases (1: returning function objects whose type is contravariant in a type parameter, and 2: tearing off methods whose signature has a type parameter in a contravariant position) cannot be used for the "opposite" case: 1: It would be a massively breaking change to perform a dynamic type check during a tear-off operation for every method with such a signature (and require it to have the naive static type where covariance is ignored), and given that regular invocations of the method will perform the same dynamic type check as the torn off function object, the amount of dynamic checking is unchanged. 2: An instance variable can hold any function object, so in the case where that instance variable has a type which is contravariant in a type parameter it would require a wrapper function if we were to treat it the same as methods (the wrapper would give the function object the "erased" run-time type that torn-off methods get, and it would perform the dynamic type checks on actual arguments). Creating and invoking wrappers is costly in terms of performance, and it creates delicate problems with object identity and equality.

Again, we can eliminate the erasure on the dynamic type of torn-off methods when the relevant type parameters have been annotated with variance markers (with some extra constraints, e.g., the method can't be inherited from a superinterface using dynamically checked covariance), so sound variance is again the real solution.

[nshahan]

Thanks for the detailed explanation! I think I keep reforming the same question in different ways and the answer is consistently that dart needs sound variance for generic type arguments to avoid it. I appreciated your presentation on use site variance when you were last in Seattle. Hopefully we can find a way to fit it into the language. I'm closing this issue since the check is clearly needed still.