List.toList() Type problem about sdk

[lrhn]

It's expected and specified behavior.

The analyzer doesn't warn, because it's perfectly valid code.

The inherent unsoundness in covariant generics is so deep in the language that it's impossible to warn about it, because that would make almost all uses of (for example, but not limited to) List.add give a warning.

It might be possible to locally deduce that you are casting a List<int> to List<Object>, and shortly after doing .add(x) on it with something that's not an int. But it's also incredibly easy to do that without the analyzer having any chance of recognizing it.

[lrhn]

Because your code is not type safe. And nor is List.

It's the same error you'll get from

List<Object?> list = <C>[];
list.add(B()); // Type error, B is not a C

The function test takes a Holder, aka Holder<Object?>.
That contains some List<Content<T>>, deleted you haven't shown the type. I'm assuming it's a List<Content<C>>, but from where your code is looking, it has static type List<Content<Object?>>

If you try to add a Content<B> to that, it fails, as it should.

If you do .toList() on it, you get another List<Content<C>> with static type List<Content<Object?>>, and adding still fails.

If you do var list = List.of(...);, you create a new List<Content<Object?>> with the same elements. That's safe, and you can safely add to it. That is, the static element type becomes the runtime element type of the newly created list.
That's why it works.

[feduke-nukem]

Because your code is not type safe. And nor is List.

It's the same error you'll get from

List<Object?> list = <C>[];
list.add(B()); // Type error, B is not a C

The function test takes a Holder, aka Holder<Object?>. That contains some List<Content<T>>, deleted you haven't shown the type. I'm assuming it's a List<Content<C>>, but from where your code is looking, it has static type List<Content<Object?>>

If you try to add a Content<B> to that, it fails, as it should.

If you do .toList() on it, you get another List<Content<C>> with static type List<Content<Object?>>, and adding still fails.

If you do var list = List.of(...);, you create a new List<Content<Object?>> with the same elements. That's safe, and you can safely add to it. That is, the static element type becomes the runtime element type of the newly created list. That's why it works.

Thanks for answer but I still don't get it. toList() is a shortcut for List.of() (basically the same operation) then why behaviour differs?

[lrhn]

If list is an instance of List<E>, then list.toList() works like List<E>.of(list), no matter what the static type of list is.

Doing List.of(list) infers the type of the created list from the static type of list, because the compiler infers the missing type argument to List. This is List<T>.of(list) for some T, which is inferred because you didn't write it.

Which means:

List<Object> list = <int>[1]; // Valid, up-cast.
var list2 = list.toList(); // Same as `List<int>.of(list);`, called by list itself, which knows it's an `int` list.
var list3 = List.of(list); // Same as `List<Object>.of(list);`, inferred from static type.

Those two calls are not the same.

[feduke-nukem]

If list is an instance of List<E>, then list.toList() works like List<E>.of(list), no matter what the static type of list is.

Doing List.of(list) infers the type of the created list from the static type of list, because the compiler infers the missing type argument to List. This is List<T>.of(list) for some T, which is inferred because you didn't write it.

Which means:

List<Object> list = <int>[1]; // Valid, up-cast.
var list2 = list.toList(); // Same as `List<int>.of(list);`, called by list itself, which knows it's an `int` list.
var list3 = List.of(list); // Same as `List<Object>.of(list);`, inferred from static type.

Those two calls are not the same.

So is that an expected behaviour?

Why doesn't an analyzer warn about it or something?