Generics lost in extension after cast type about language

[eernstg]

issues such as #620 could be resolved using extensions.

Good point, @rrousselGit!

Actually, an 'existential open' operation would suffice, so we wouldn't have to make huge breaking changes to the semantics of extension declarations:

class Unary<A> {}

void doSomething<T extends Unary<Object?>>(T unary) {
  unary._doSomething();
}

extension on Unary<Object?> {
  void _doSomething() {
    final self = this; // We need this until we get promotion of `this`.
    if (self is Unary<final X>) {
      // In this scope we have access to the actual value of the type
      // argument `X` where `self` has run-time type `Unary<X>`.
      X x = ...; // We can use `X` as a type.
      print('use $X'); // Of course, we can also obtain a `Type` from it.
    }
  }
}

The construct self is Unary<final X> is the existential open. It is not intended to be an entire type pattern matching feature, it's just a simple mechanism which is able to look up the value of a type variable in the type of an object.

This is not surprising, I just think it's worth mentioning that we won't have to make radical changes to the semantics of existing mechanisms in order to provide access to this kind of functionality.

[eernstg]

Here is some background information about the situation, and about related discussions that we already had in this area:

This is a rather fundamental design choice. Extension methods are resolved at compile time, and this implies that the value of T during the execution of extensionGetTType is determined by the static type of the receiver. The receiver is test, and the static type of test is obtained from the initializing expression t as TestObject, and TestObject means TestObject<Object> (it's a raw type, and the value of a raw type is obtained by a process called instantiation to bound, so the missing type argument is inferred to be the bound, which is Object). This means that the returned value is Object.

This means that it is not likely that Dart can accommodate a redesign of extension declarations such that they will use the dynamic value of type parameters: It's going to be a massively breaking change. Also, it will make extension methods less performant, and it may also eliminate some optimization opportunities.

However, we've had a number of discussions about doing things of this nature, provided via different mechanisms. For example #170 proposed a general mechanism which could be used to "look up" the value of a type argument (at compile time or at run time), and #177 proposed a variant of the extension feature which would allow for dynamic dispatch as well as dynamically bound type parameters.

[rrousselGit]

It's maybe worth noting that if generics were resolved at runtime rather than compile time, then issues such as #620 could be resolved using extensions.

We would be able to do:

class Unary<A> {}

void doSomething<T extends Unary<Object?>>(T unary) {
  unary._doSomething();
}

extension<A> on Unary<A> {
  void _doSomething() {
    print('use $A');
  }
}

This wouldn't work for all cases though.

[rrousselGit]

To be fair, relying on extensions for such a thing is probably undesirable. It would mainly work with functions do not use the generic in either return value or parameters.

So we probably can't avoid #620.