type '(int) => void' is not a subtype of type '(Object) => void'

[tolotrasamuel]

I checked all my generics are all OK. Inheritance seems ok. Type inference seems ok. No compiler error. I don't have any hard type casting. Everything is seems strongly typed.

class ModelField {}

class DropdownField<V> extends ModelField {
  final void Function(V value) setValue;

  final List<V> options;

  DropdownField({
    required this.setValue,
    required this.options,
  });
}

void _buildDropdownField<V>(DropdownField<V> field) {
  final options = field.options;
  final data = options.first;

  field.setValue(data); // error Here
}

void _renderField(ModelField field) {
  /// from server
  // if field is StringField, else if field is DateField, ... else
  if (field is DropdownField<Object>) {
    // same thing occurs with  DropdownField<dynamic>
    _buildDropdownField(field);
  }
}

void main() {
  final field =
      DropdownField<int>(setValue: (value) => print(value), options: [1, 2, 3]);

  _renderField(field);
}

But when I run:

Unhandled exception:
type '(int) => void' is not a subtype of type '(Object) => void'
#0      _buildDropdownField (package:shared_core/weird_dart/generic_promotion.dart:18:9)
dart-lang/sdk#57147      _renderField (package:shared_core/weird_dart/generic_promotion.dart:26:5)
dart-lang/sdk#57148      main (package:shared_core/weird_dart/generic_promotion.dart:34:3)
dart-lang/sdk#57149      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:297:19)
dart-lang/sdk#57150      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:184:12)

How can int not be a subtype of Object???

I am so confused (or Dart is) I hope it's me. But this error occurs only at run time.

[dart-github-bot]

Summary: The user is encountering a runtime error where a function accepting an int argument is not considered a subtype of a function accepting an Object argument. This occurs despite the user's expectation that int should be a subtype of Object.

[eernstg]

The error message is correct: void Function(int) is indeed not a subtype of void Function(Object). Just think about substitutability: We can only say that T is a subtype of S when an entity of type T can be used in a context where an S is expected.

So assume that we expect to use a function f of type void Function(Object), but we are actually working with a function of type void Function(int). Based on the expected type, we can call it as f(true) because true has a type which is assignable to Object. In reality, we can't do this because the actual function insists that its actual argument must have type int.

In general, this is what it means when it is stated that "function parameter types are contravariant": In order to obtain a subtype, we must replace the parameter type by a supertype (in particular, void Function(int) is a subtype of void Function(Object), not the other way around).

The culprit here is that you have declared a "non-covariant member".

class DropdownField<V> extends ModelField {
  final void Function(V value) setValue; // <-- Non-covariant, that is, dangerous!
  DropdownField({required this.setValue});
}

This member is non-covariant in the sense that its type contains a type parameter declared by the enclosing class in a contravariant (that is, non-covariant) position, namely as the function type's parameter type.

We could emit a warning when this occurs (see #59050), but this hasn't yet been implemented. (You can vote for that issue in order to support that it gets implemented.)

One step you could take in order to reduce the danger is to make sure that the non-covariant member is never used from a client, it must always be used as a member of this. You can't directly enforce this, but we can make it private and call it via a method:

class DropdownField<V> extends ModelField {
  final void Function(V value) _setValue;
  void setValue(V value) => this._setValue(value);
  DropdownField({required void Function(V) setValue}): _setValue = setValue;
}

This is sufficient to make your example run without run-time failures:

class ModelField {}

class DropdownField<V> extends ModelField {
  final void Function(V value) _setValue;
  void setValue(V value) => this._setValue(value);

  final List<V> options;

  DropdownField({
    required setValue,
    required this.options,
  }) : _setValue = setValue;
}

void _buildDropdownField<V>(DropdownField<V> field) {
  final options = field.options;
  final data = options.first;

  field.setValue(data); // error Here
}

void _renderField(ModelField field) {
  /// from server
  // if field is StringField, else if field is DateField, ... else
  if (field is DropdownField<Object>) {
    // same thing occurs with  DropdownField<dynamic>
    _buildDropdownField(field);
  }
}

void main() {
  final field =
      DropdownField<int>(setValue: (value) => print(value), options: [1, 2, 3]);
  _renderField(field);
}

The reason why this helps is that the non-covariant member is never accessed under an unsafe type (like void Function(Object) when it's actually a void Function(int)), and hence there's no failing type check at run time. It is accessed using the type void Function(V) at a location where V is in scope, which is a precise and safe typing. The crucial point is that we're working with a function object, and this will cause a run-time failure if the given function object doesn't have the statically known type.

In contrast, clients will now call the method setValue, which is done directly; that is, we will just call the method, we will not tear off the method in order to get a function object, and then call that function object.

It will be checked that the actual argument has the required type (int, or whatever it is), but this is a requirement that the given code does satisfy.

I'll close this issue because it's all working as specified. (But I'd very much like to have the lint that warns developers against declaring non-covariant members in the first place ;-).

[tolotrasamuel]

Thank you!
The Static check would be so useful if implemented.
Without your clear explanation, I would never guess that the solution is to make a private method wrapping the setValue.

[tolotrasamuel]

Sorry to bump into this again, but the prescribed solutions feels like a workaround.

Since in reality I have several method belonging to the dropdown such as selectedItemBuilder and I find myself wrapping them all in private methods.

Is there an actual proper solution to this issue? Is there a best practice that I did not follow ?
Is it that my code was badly written overall and needs deeper refactoring or this is an actual Dart limitation without any proper solution ?
@eernstg

[tolotrasamuel]

I found that simply adding the experimental flag inout fixes the issue.

keyword inout Thus: class DropdownField .

What are the potential issue of this keyword ? Would I lose type safety in some edge cases ?