ListMixin.indexOf(Object) should take an E

[jakobr-google]

In List, indexOf and lastIndexOf are defined as

int indexOf(E element, [int start = 0]);
int lastIndexOf(E element, [int start]);

but in ListMixin, they're overridden as

int indexOf(Object element, [int startIndex = 0]) { ... }
int lastIndexOf(Object element, [int startIndex]) { ... }

It'd be nice if they agreed on the types.

Context: I have a class that wraps another list and implements List<E> by delegating to the wrapped list for most methods. I mix in ListMixin<E> to make sure I catch any future additions to List. Because of the differing types, I got an error on indexOf and lastIndexOf because I'd implemented them with the signature from List.

[lrhn]

They should agree, and the List declaration is the correct one.

[rakudrama]

Should the type of [element] be consistent with contains ?

[lrhn]

Edit: List is not the correct one. It should be consistent with contains, and we are not changing how that works, so yes, we should be fixing List as well.

That is a breaking change, so we'll have to do it as part of the Dart 2 release.

[kevmoo]

This is a pretty glaring issue, no?

[lrhn]

It is potentially annoying, and we forgot to fix it when we fixed List, so I guess we'll keep it as-is for Dart 2. That's not a big issue, it does work as written.

The ListMixin implementation is a valid implementation of the List interface. We could change it to match the List interface now, but that could potentially be be breaking - maybe someone is using the List interface covariantly and relying on the implementation allowing that.

Actually, what we have now is, arguably, the best possible design with our current type system. The interface is restrictive in what it accepts, so you get a warning if you ask for something incompatible with the static type, but the implementation works covariantly, so if you assign a List<int> to List<num>, you can do .indexOf(0.5) and you still get an error for .indexOf("string")

[dgrove]

Removing this from Dart2Stable, given the "we'll keep it as-s for Dart 2" comment.

[natebosch]

Will we consider changing this for Dart 3?

[kevmoo]

I'd hope so!

[lrhn]

My guess is "no". Because I don't expect that we'll get any large-scale breaking library changes into Dart 3.0, except removing deprecated things. Maybe 4.0. (This is pure speculation, there is nothing decided about 3.0 yet. I hope that I'm wrong.)