Skip to content

Unexpected type error when using a typedef #32641

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zanderso opened this issue Mar 22, 2018 · 3 comments
Closed

Unexpected type error when using a typedef #32641

zanderso opened this issue Mar 22, 2018 · 3 comments
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. os-fuchsia

Comments

@zanderso
Copy link
Member

When running the following program there is a type error in the assert().

test.dart:

typedef T DoSpecialThing<T>(T thing);

String specialStringThing(String thing) => thing;
double specialDoubleThing(double thing) => thing;

class Property<T> {
  Property(this._operation);
  T doThing(T thing) => thing;
  DoSpecialThing<T> get doSpecialThing => _operation;
  DoSpecialThing<T> _operation;
}

Property<String> stringProperty = new Property<String>(specialStringThing);
Property<double> doubleProperty = new Property<double>(specialDoubleThing);

void main() {
  List<Property> properties = [ stringProperty, doubleProperty ];
  List values = [ "String value", 0.0 ];

  for (int i = 0; i < properties.length; ++i) {
    assert(properties[i].doSpecialThing(values[i]) == values[i]);
  }
}
$ dart --enable-asserts --preview-dart-2 test.dart 
Unhandled exception:
type '(String) => String' is not a subtype of type '(dynamic) => dynamic'
#0      main (file:///usr/local/google/home/zra/dart/dart2tests/test.dart)
#1      _startIsolate.<anonymous closure> (dart:isolate/runtime/libisolate_patch.dart:279:19)
#2      _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:165:12)

However, if doSpecialThing is replaced with doThing, which should have the same type(?), there is no type error.

/cc @crelier @leafpetersen

@zanderso zanderso added area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). os-fuchsia labels Mar 22, 2018
@lrhn
Copy link
Member

lrhn commented Mar 22, 2018

This looks reasonable.

The properties[i].doSpecialThing (with static type dynamic Function(dynamic)) invokes a getter of a generic class where T occurs contravariantly. Such a getter is not soundly compatible with covariant generics.

To ensure runtime type soundness, we insert a dynamic check to decide whether the value returned by that getter actually satisfies the static type of the expressions ... and it doesn't. It's String Function(String) which isn't assignable to dynamic Function(dynamic), and the runtime check throws as it's intended to.

If you replace doSpecialThing with doThing, you are not longer accessing a getter, but are instead tearing off a method with a generic-based covariant parameter type. That method tear-off does satisfy the static type because its runtime type has Object as parameter type (it throws dynamically on non-T arguments, but the static type is right).

We can make the method tear-off sound because we compile the method in a position where we are aware of the co-/contra-variance issues. The stored _operation can be any function with the correct type, so we cannot adapt it to be compatible with this particular usage.

All in all this is working as intended.

@zanderso
Copy link
Member Author

Okay, so replacing:

DoSpecialThing<T> get doSpecialThing => _operation;

with:

T doSpecialThing(T thing) => _operation(thing);

does the trick by shifting the runtime type check from the callsite into the callee. Thanks!

@leafpetersen
Copy link
Member

Yeah, this is a known pain point, tracked here: #31391 . Covariant generics + contravariant getters just don't play all that well together. It's really confusing when the check fails, and we'd like to make it better at some point in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. os-fuchsia
Projects
None yet
Development

No branches or pull requests

3 participants