Wrapped function causes runtime error.

[modulovalue]

dartpad

I'm not sure how to describe this issue.

abstract class Interface {}

class Model implements Interface {}

class Lens<A> {
  final A Function(A) get;
  const Lens(this.get);
}

void main() {
  Lens<Interface> a = Lens<Model>((a) => a);  
  print(a.get); /// Script error / type '(Model) => Model' is not a subtype of type '(Interface) => Interface'
}

I'm trying to chain lenses (functional references) and this problem comes up when I'm dealing with inheritance hierarchies.
Implicit-casts are set to false so I'm expecting some kind of safety there, but I'm not sure if this scenario is just something that I have to somehow be careful about?
I'd at least expect that that program would not compile, but instead, it crashes on the print call.

Is there a way to deal with this?

[eernstg]

The problem is that you are specifying that you want a Lens<Model>. The current Dart rules for variance only have one form: Covariance for every type parameter of a generic class, with dynamic checks at all occasions where there is no static guarantee that the requirement is satisfied. This allows you to initialize a with a value of type Lens<Model>.

When you assign Lens<Model> to the variable of type Lens<Interface> you rely on the ability of a Lens<Model> to work in every situation where a Lens<Interface> is expected. But that isn't true, because this kind of variance relies on dynamic checks (when a type variable occurs in a non-covariant position in a member signature, for instance with the second A in the type of the instance variable get).

So when you evaluate a.get the expression is known to be unsound (there is no guarantee that the returned value has the static type), so there is a dynamic check, and it fails: The actual value is a function object of type Model Function(Model), the static type is Interface Function(Interface), and the former is not a subtype of the latter.

We have plans to add support for statically safe variance (covariance, contravariance, invariance) to Dart, so you will (if we proceed to do this, which is quite likely) be able to specify the variance on each type parameter, and then there will be static checks that the rules necessary for soundness are respected.

In particular, if you were to declare as covariant with class Lens<out A> { ... } then you would not be able to have the instance variable named get, because it has a non-covariant occurrence of the type variable A. So you would have to use the more strict invariant mode, using class Lens<inout A> {...}, and this would imply that there is no subtype relationship between Lens<Model> and Lens<Interface>.

So you would still not be able to have Lens<Interface> a = Lens<Model>(...);, but now it would be a compile-time error rather than a run-time error.

So what you can do now is to treat Lens as if its type parameter were invariant; you won't get the static checks to enforce that, yet, but you can do it manually.

You can actually create a discipline which is similar to declaring the type variable invariant, and this may or may not work in practice for you: If you declare separate nominal subtypes for each actual type argument that you wish to use then you can express the exact type argument today:

abstract class Interface {}

class Model implements Interface {}

class Lens<A> {
  final A Function(A) get;
  const Lens(this.get);
}

class InterfaceLens extends Lens<Interface> {
  InterfaceLens(Interface Function(Interface) f): super(f);
}
class ModelLens extends Lens<Model> {
  ModelLens(Model Function(Model) f): super(f);
}

void main() {
  InterfaceLens a = ModelLens((a) => a); // Compile-time error!
  ...
}

This allows you to create types where the type argument is statically known (if you know that you have an instance of ModelLens then it is guaranteed to be an instance of Lens<T> where T is equal to Model, not just any subtype of Model).

If you are working in terms of ModelLens etc. you won't have the ability to abstract over Lens<T> for different T, which may not be acceptable in terms of the reusability and generality of your code. You would still be able to use Lens<T> for other purposes (for members that aren't using the type variable in a non-covariant position). But, of course, it will be a clear improvement when and if we add sound variance as a built-in mechanism.

[modulovalue]

Thank you very much for the workaround and the clear explanation.