generic methods should be able to override non-generic ones.

[jmesserly]

From @jmesserly on February 22, 2016 17:33

Split from dart-archive/dev_compiler#301. Something like this should be supported (or we need to explicitly disallow it):

class B {
  Iterable map(f(x)); // (* -> *) -> Iterable<*>
}
class D extends B {
  Iterable<T> map<T>(T f(x)); // <T>(* -> T) -> Iterable<T>
}

See comments starting from dart-archive/dev_compiler#301 (comment).

Normally the subtyping relation is fine, because implicit instantiation can be generated as an explicit instantiation in the generated JavaScript. However for a method override, we don't have any way to express that. It'd be a little unfortunate if all generic method calls used a different calling convention, but perhaps it's unavoidable.

Copied from original issue: dart-archive/dev_compiler#459

[jmesserly]

From @Andersmholmgren on February 22, 2016 19:39

I am already hitting this in the wild. As the annotations are missing on the Iterable methods of the collections package, those methods are not considered to be overriding those in the core dart package. So I get warnings for them

[jmesserly]

Ah, that sounds like the reverse problem:

class B {
  Iterable<T> map<T>(T f(x));// <T>(* -> T) -> Iterable<T>
}
class D extends B {
  Iterable map(f(x)); 
}

Having a non-generic override a generic is not allowed in either strong or normal mode. If you think about it, it's kind of like optional arguments. You can add optional parameters in a subtype, but you can't take parameters away:

class B {
  m(x, y) { ... }
}
class D extends B {
  m(x) { ... } // error
}

The short term fix is to annotate the collections package.

We've discussed doing inference. Given my first example, we could conclude that D.map needs a type parameter, which would make it D.map<T>. However the return type of Iterable<dynamic> is also problematic, unless we can conclude it too should be Iterable<T>. But we're unsure if this kind of inference is a good idea, as it's sort of analogous to inferring a missing function parameter :)

[vsmenon]

@leafpetersen @jmesserly - I think we're explicitly disallowing this now statically. Can we close?

[jmesserly]

yup, good catch. this was restricted in the type system.