Missing function parameter type detection.

[Xekin97]

Why does a function not check the type of a passed parameter when it is not assigned to any variable?

This prevented many of my utility functions from getting accurate type error warnings when used by dart developers, but they still reported errors at runtime.

[Xekin97]

I hope that in both cases ide correctly alerts to the type error.

[simphotonics]

Could you please edit your post and add the code as properly formatted text.

[rubenferreira97]

This behavior is due to a combination of type inference and variance rules in Dart. I will do my best to explain both of these concepts. I am almost certain that @eernstg is one of the best people to correct me, so I’m tagging him to review this 😉.

Inference

When you call test(arr, 123);, Dart infers the type parameter T. To determine T, it looks for a type that satisfies the constraints imposed by the arguments:

• T must be a supertype of both String (from arr) and int (from 123).
• The only type that satisfies this is Object, so the call is inferred as test<Object>(arr, 123);.

Variance

Dart collections like List<T> are covariant, meaning you can assign a List<String> to a List<Object> because String is a subtype of Object. However, covariance is unsound (on write) because it allows runtime type violations, as seen in this example:

List<String> arr = ['a', 'b', 'c'];
test<Object>(arr, 123); // This inserts an `int` into a `List<String>`, violating type safety.

At runtime, the program crashes when trying to insert an int into arr because arr is actually a List<String>, not a List<Object>.

Why there’s no compile-time error without assignment?

In the call test(arr, 123);, there’s no context that forces Dart to validate the inferred type against String. Without additional constraints, Dart infers Object for T and assumes the operation is valid. It only produces a runtime error because the assignment arr[0] = value violates the actual runtime type of the list.

In contrast, when you write:

a = test(arr, 123);

You explicitly constrain T because a is of type String. Dart now tries to find a type for T that:

• Is a supertype of both String and int (resulting in Object).
• Is also a subtype of String (because of a’s type).

These constraints are contradictory, so Dart reports a compile-time error.

Simplified Example

If we simplify your program to remove inference:

void main() {
  Object test(List<Object> arr, Object value) {
    arr[0] = value; // Runtime error: cannot insert `int` into `List<String>`.
    return value;
  }

  List<String> arr = ['a', 'b', 'c'];
  test(arr, 'd'); // No error: `arr` can hold a `String`.
  test(arr, 123); // Runtime error: tries to insert `int` into a `List<String>`.
}

This demonstrates the problem: Dart allows the covariant assignment of List<String> to List<Object>, but it’s unsound and can lead to runtime errors.

What can you do?

While this behavior is "working as expected" according to Dart’s current type system, it can be surprising and problematic for developers. This stems from Dart’s unsound variance (#213). If Dart had sound variance, such issues would be caught at compile-time.

So please upvote the following issues to make the Dart Team prioritize this problem: #213, #524, #753

I think it infers "dynamic", not "Object". Not sure.
To fix it, specify the type parameter explicitly
test<String>(arr, 123); // Compiler will complain

[rubenferreira97]

Dart 3.6.1 seems to infer as Object.

As @tatumizer mentioned, you can also explicitly give <String> to constrain T, which will result in a compile-time error.

---

Today I learned, Dart infers scoped functions T test<T>(List<T> arr, T value) vs dynamic test<T>(List<T> arr, T value).

(Off-topic: Do you know what setting controls the appearance of <Object>, arr: and value: in my text? I can't edit anything because of this. Or if you know where I can take a course of editing in this new fashion, please provide a link)

[eernstg]

That's a great explanation, @rubenferreira97!

@tatumizer wrote:

I think it infers "dynamic", not "Object". Not sure.

This is actually a murky corner of Dart type inference as currently it is implemented. The specification in inference.md says that the greatest closure of a type variable is Object? (not dynamic), and that is the solution to a constraint set that doesn't constrain the type variable at all.

This means that we'd get Object? from type inference in the cases where nothing is known about the given type parameter. However, for historic reasons we do get dynamic in some cases. This is not easy to change because it breaks existing code. This is being considered, but there's no specific date or version where this work will be finished.

Right now we just have to live with the fact that some occurrences of dynamic could have been created during type inference because it doesn't (yet) dare to use Object? consistently. ;-)

Also, of course, instantiation to bound is specified to use dynamic as a fallback type. This implies that List xs = [1, 2, 3]; means List<dynamic> xs = [1, 2, 3]; which is in turn inferred as List<dynamic> xs = <dynamic>[1, 2, 3];. Note that it doesn't even help that the list exclusively contains elements of type int, the context type always weighs more heavily than the subexpressions.

You can use analyzer settings like strict-raw-types to avoid using the type dynamic by accident in this kind of situation.

In the given example the inferred type argument is Object because this is the least upper bound (better terminology: standard upper bound, because it ain't least) of String and int. So we don't even have a situation where the discussion about Object? or dynamic can get started, we just have a case where we compute the upper bound of two types and get a result which happens to be Object.

@rubenferreira97 wrote:

As @tatumizer mentioned, you can also explicitly give <String> to constrain T, which will result in a compile-time error.

This is true, but not very practical. We wouldn't want to remember every single case where we need to provide the actual type arguments explicitly in a function call, because it is unsafe otherwise.

Also, it's still unsafe with some actual type arguments that aren't dynamic:

void foo<X>(List<X> xs, X x) => xs.add(x);

void main() {
  // Let's say we got `xs` from somewhere, and we have forgotten that it's a `List<int>`.
  List<num> xs = <int>[1, 2, 3];

  foo(xs, 1.5); // No compile-time error. Throws.
  foo<num>(xs, 1.5); // No compile-time error. Throws.
}

Issue #524 is a proposal to add support for statically checked variance to Dart. If this feature had been available in Dart today, and if List had been declared to have an invariant type parameter, as in ..

class List<inout E> implements Iterable<E> { // OK, the real thing has more stuff.
  ...
}

.. then List<int> would simply not be a subtype of List<Object>, and the invocation of test would always be safe (if it compiles).

There's a price to pay for this, though, which is that a lot of usages which are actually safe in current Dart are now compile-time errors. Roughly, any usage of a list that only reads elements and doesn't insert new ones is safe, even when the typing is covariant (that is, for example, a list with static type List<Object> actually has run-time type List<int>).

It's getting late, so I'll go home now. But I'll write more about how to avoid this kind of type error tomorrow. ;-)

[rubenferreira97]

(Off-topic: Do you know what setting controls the appearance of <Object>, arr: and value: in my text? I can't edit anything because of this. Or if you know where I can take a course of editing in this new fashion, please provide a link)

(Sorry for going off-topic. Maybe GitHub will implement DMs someday.)

@tatumizer These are called Inlay Hints. If you’re using VSCode, you can press Ctrl+Alt (Windows) or Ctrl+Option (macOS) to toggle them while holding the keys. To enable or disable them permanently, you can configure your VSCode Workspace/User settings using the following options (off, on, offUnlessPressed, onUnlessPressed):

{
    "[dart]": {
        "editor.inlayHints.enabled": "offUnlessPressed"
    }
}

Note: There’s an annoying bug (Dart-Code/Dart-Code#5313), but closing and reopening the file resolves it.

---

@eernstg

This is being considered, but there's no specific date or version where this work will be finished.

Nice! Every change that removes implicit dynamic is a win in my book.

There's a price to pay for this, though, which is that a lot of usages which are actually safe in current Dart are now compile-time errors. Roughly, any usage of a list that only reads elements and doesn't insert new ones is safe, even when the typing is covariant (that is, for example, a list with static type List<Object> actually has run-time type List<int>).

This is one of the reasons I filed this issue.

Kotlin addresses this at the interface level by making immutable lists covariant and mutable lists invariant:

expect interface MutableList<E> : List<E>, MutableCollection<E>
expect interface List<out E> : Collection<E>

[Xekin97]

This behavior is due to a combination of type inference and variance rules in Dart. I will do my best to explain both of these concepts. I am almost certain that @eernstg is one of the best people to correct me, so I’m tagging him to review this 😉.
......

---

@rubenferreira97 Thanks for your kind answer, but you know I mean that no runtime error should be happen if I never declare dynamic type actively or inferred by dart self.

I dont know how can I extract the parameter's type in a function, but using a class can do what they call "type mirror" for this.

Look this:

class MyClass<T> {
  List<T> value;

  testFunc(T val) { 
    value[0] = val;
    return val;
  }

  MyClass(this.value);
}

void main () {
  testFunc <T> (List<T> list, T value) {
    list[0] = value;
    return value;
  }
  List<String> abc = ['a', 'b', 'c'];

  final inClass = MyClass(abc);

  inClass.testFunc('abc'); // ok
  inClass.testFunc(123); // compile-time error
  String a = 'abc';
  a = inClass.testFunc('abc'); // ok
  a = inClass.testFunc(123); // compile-time error

  testFunc(abc, 'abc'); // ok
  testFunc(abc, 123); // runtime error
  a = testFunc(abc, 'abc'); // ok
  a = testFunc(abc, 123); // compile-time error

  print(a);
}

[Xekin97]

I have used typescript before. It is a compile-time error without doubt when writing:

function testFunc<T>(list: T[], value: T) {
   list[0] = value
   return value
}

testFunc(['a','b', 'c'], 123);

[eernstg]

@rubenferreira97 wrote:

Kotlin addresses this at the interface level by making immutable lists covariant and mutable lists invariant:

Yes, that's extremely tempting if starting from scratch. However, the discussion in your issue about this subtyping structure shows that it gets harder when existing code hasn't been written to work well with that design.

By the way, the alignment isn't perfect: A method like clear can be a member of a covariant collection type just fine, in spite of the fact that it will (usually) mutate the receiver.

So do you optimize for "cleanly non-mutating", or do you optimize for "greatest possible interface which is soundly covariant"?

Conversely, consider a method like Iterable<E>.firstWhere that performs a search and accepts a callback E orElse() which is invoked in order to have something to return if the search failed. This method does not have any need to mutate the receiver, but it still can't be (safely) included in the interface of a covariant immutable list type.

Of course, firstWhere could be modified to take a type parameter with a lower bound, but that would again be a breaking change.

[eernstg]

@Xekin97 wrote:

no runtime error should be happen if I never declare dynamic type actively or inferred by dart self.

That's not quite true. All programming languages (except perhaps Coq's language Gallina, and a few other theorem proving languages) are striking a balance between checking programs statically and raising errors at run time. Out of memory is obviously undecidable in most languages, so it occurs at run time. Nobody is trying to handle division by zero statically, so that's a run-time error, too. Lots of languages (not including Dart) can have null pointer errors because the type system considers the null object to have all types.

Kotlin null-safety can be violated via Java code, but also based on pure Kotlin mechanisms (see this paper).

When the initial version of Dart was designed (years before I joined), a very controversial decision was taken with respect to the handling of variance: Every type variable in Dart is covariant, and every construct which is not statically guaranteed to satisfy the typing constraints is subject to a type check at run time.

The motivation for this design was mainly simplicity. Java wildcards had been introduced a few years earlier (which is a sound approach to variance, of the kind known as use-site variance), but they were considered complex to read and write. Hence, Dart took this other path which is a lot simpler, but relies on run-time checks at locations like arr[0] = value in your example.

Note that Java and C# have chosen the exact same approach with arrays, and they use ArrayStoreException respectively ArrayTypeMismatchException to handle run-time type mismatches.

Anyway, as an amazing surprise to me, Dart hasn't given rise to many run-time type errors caused by the dynamically checked covariance, as far as we can see from the issues reported here. So I have to conclude that it works surprisingly well (that is, safely) in Dart code as it is written by this community.

Nevertheless, I'd very much like to introduce support for statically checked variance in Dart, so I created #524 (yes, upvotes are very welcome! ;-). Similarly, #753 and #229 are proposals about use-site (in)variance, which can be used to treat existing classes with covariant type parameters invariantly, without changing those classes.

For example:

// Assuming use-site invariance, i.e., `exactly` modifiers on type arguments.

T testFunc<T> (List<exactly T> list, T value) {
  list[0] = value;
  return value;
}

void main() {
  List<exactly String> abc = ['a', 'b', 'c'];
  testFunc(abc, 123); // Compile-time error.
}

If you use the type List<String> rather than List<exactly String> as the declared type of abc then we have already forgotten (according to the type checker) that abc is actually initialized to a List of exactly String, it could just as well have been <Never>[]. Nevertheless, we can use these types consistently, and obtain a compile-time guarantee that any given list has exactly a specific type argument, and then you can modify it safely.

OK, that's enough about nice statically checked mechanisms that we could have (if they get enough support).

[eernstg]

Next, I'd describe a few ways to make the code safer using Dart of today. Here's the original example again (moving test out to the top level because there's no particular point in having an inferred return type):

T test<T>(List<T> list, T value) {
  list[0] = value;
  return value;
}

void main() {
  List<String> arr = ['a', 'b', 'c'];
  test(arr, 'def'); // OK.
  test(arr, 123); // OK at compile time, inferred as `test<Object>(...)`, throws.
}

The main reason why covariance is introduced is that type inference is applied to both arguments simultaneously. We can force a separation by currying the function:

T Function(T) test<T>(List<T> list) => (T value) {
  list[0] = value;
  return value;
};

void main() {
  List<String> arr = ['a', 'b', 'c'];
  test(arr)('def'); // OK.
  test(arr)(123); // Compile-time error.
}

With the curried declaration, the value of the type parameter is determined fully by the first argument, and the second argument will never give rise to any upper bound computation (which was causing the covariance in the first place).

A similar effect can be achieved by using an extension method (because the list will now be the receiver rather than an argument, and the type of the receiver is fully determined before any of the arguments are considered).

extension<X> on List<X> {
  X test(X value) {
    this[0] = value;
    return value;
  }
}

void main() {
  List<String> arr = ['a', 'b', 'c'];
  arr.test('def'); // OK.
  arr.test(123); // Compile-time error.
}

Another approach which can be used to avoid covariance related run-time checks (or to make them explicit and perform them safely) is to eliminate the variance in the first place by keeping all parts inside a scope where the type parameter is in scope:

class A<X> {
  final List<X> xs = []; // This is actually a `List<exactly X>`.

  X? testWithCheck(Object? value) {
    if (value is X) {
      xs.add(value); // Statically safe.
      return value;
    }
    return null;
  }

  X testWithType(X value) {
    xs.add(value);
    return value;
  }
}

void main() {
  var a = A<String>();

  // `testWithCheck` accepts any argument, but returns null when the
  // argument doesn't have the required type.
  print(a.testWithCheck('def')); // 'def'.
  print(a.testWithCheck(123)); // 'null'.

  // `testWithType` only accepts an `X`.
  a.testWithType('def'); // OK
  // a.testWithType(123); // Compile-time error.

  // However, we can use covariance at the next level.
  A<Object> aObject = a; // OK, based on covariance.
  aObject.testWithType(123); // OK at compile-time, throws.
}

The point is that code inside the class A can use the type parameter X, and we've ensured by the initialization of xs that we actually have a List of exactly X (and we don't need to know the value of X). This means that all operations on that list can be handled in concert with usages of X. For instance, if (value is X) ... provides a guarantee that the given value does actually have a type which is appropriate for being an element in xs.

xs could be made private in order to prevent clients from doing unsafe things, or clients could just be informed that they should only use xs in ways that are safe with covariance (roughly: read-only).

We can also move the typing out one extra step (as in testWithType), but this reintroduces the covariance at call sites, as illustrated by the fact that aObject.testWithType(123) will throw at run time.

Finally, we can emulate invariance in current dart:

// ----------------------------------------------------------------------
// Declare `A` (plus helpers).

typedef Inv<X> = X Function(X);

typedef A<X> = _A<X, Inv<X>>;

class _A<X, Invariance extends Inv<X>> {
  final List<X> xs = []; // This is actually a `List<exactly X>`.

  X test(X value) {
    xs.add(value);
    return value;
  }
}

// ----------------------------------------------------------------------
// Use `A`, presumably in a different library.

void main() {
  var a = A<String>();

  a.test('def'); // OK
  a.test(123); // Compile-time error.

  // We can also perform the operations directly, safely.
  a.xs.add('ghi'); // OK.
  a.xs.add(123); // Compile-time error.
  
  X test<X>(A<X> a, X value) {
    a.xs.add(value); // OK
    return value;
  }

  test(a, 'jkl'); // OK.
  test(a, 123); // Compile-time error.

  // Covariance at the next level cannot happen: `A` is invariant
  // in its type parameter!
  A<Object> aObject = a; // Compile-time error.
}

The type alias A is used to enforce that clients (outside the library that declares A) cannot pass actual type arguments to the underlying class _A in any other way than _A<T, Inv<T>> for some type T. This is sufficient to ensure that A<String> is not a subtype of A<Object> (nor a subtype of A<Never>), which is exactly what it takes for A to be invariant in its type parameter.

Of course, a real invariance mechanism would be more convenient, but if you decide that you absolutely must make a particular class invariant in one or more type parameters then you can do it.