Iterable<E>.contains() argument should be templated?

[duzenko]

Currently the contains(Object element) method accepts any argument value.
I wonder why not limit element to template type E?

[mit-mit]

cc @lrhn

[duzenko]

I have the same complain towards the Map [] operator.

final m = Map<num,num>();
final x = m['what???'];

[duzenko]

Somewhat related - Map.fromIterable could use templating:
Map.fromIterable(Iterable iterable, {K key(element), V value(element)})
=>
Map.fromIterable<T>(Iterable<T> iterable, {K key(T element), V value(T element)})
Right now constructions like
Map<num,String>.fromIterable(myList, key: (x)=>x.id, value: (x)=>x.name.value) are asking for trouble due to abuse of dynamic downcasts.

[lrhn]

This has been asked before, e.g. #30405.
In short, there are reasons for the current design, and changing it now would be breaking.

The Object typed parameters are there because of covariant generics. You can treat a Set<int> as a Set<num> or Set<Object>, and all non-mutating functions still work. That means that contains needs to be able to accept any Object.

The option of typing the parameter as E in the interface, and then make all implementations actually accept Object, is not really viable. It's too easy to create something with the interface type.

The map constructors are a consequence of the lack of generic constructors (#30355).

[duzenko]

The # you're referring to says

I'm guessing these are unlikely to occur or should be broken up into individual requests.
Why can't this one qualify as that (individual request)?

[lrhn]

It can count as an individual request, but this particular request is solidly in the "unlikely to occur" bucket.
The one duplicate issue that was linked was not the only issue ever, just the most recent one. We also have, e.g., #26852 and #22781 which are basically the same issue.

Changing the member declaration now is breaking. Even if we do so, it will mean that there are use-cases that are no longer supported. Unless we introduce a language feature which makes it possible to declare a method parameter to have a static type of E and a run-time type of Object, ensuring that all implementations of the method will support this, then we are unlikely to change the current design. That is why this request is closed. I'm adding a "not planned" along with the "duplicate" closing marker, just to make it clear why it is closed.