Support declaration of generic type for methods

[alxhub]

Dart should support generic methods/functions, similar to Java:

class Foo<E> {
  E _item;

  /* ... */

  <T> T transform(T fn(E)) {
    return fn(_item);
  }
}

Currently this is supported only by omitting the type information. Additionally, some core Dart code includes the <T> annotation within comments: /<T>/. In order for proper tool/IDE support, Dart should support explicitly declaring generic types for a method.

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

[gbracha]

We've tried to keep things very simple. but this is obviously a possible enahncement.

---

Set owner to @gbracha.
Added Accepted label.

[anders-sandholm]

Added apr30-triage label.

[anders-sandholm]

Removed apr30-triage label.

[anders-sandholm]

Added triage1 label.

[anders-sandholm]

Added this to the Later milestone.
Removed triage1 label.

[peter-ahe-google]

I think type inference and generic functions go hand in hand.

Since I would prefer not having type inference in Dart, I would prefer to not have generic functions.

[DartBot]

This comment was originally written by vva...@gmail.com

---

I want to write top-level function with generics.

for example, I create this top-level function.
Expection<T> expect(T obj){
  return new _ExpectionImpl.expect(obj);
}

use this function invalid case. and raise a type mismatch error on IDE.
expect("foobar").toBe(1);
                                 ↑ warning. message "int is not assignable to String"

(google group log) https://groups.google.com/a/dartlang.org/d/topic/misc/6eTB2Vrrwh0/discussion

[DartBot]

This comment was originally written by Konstantin.Solo...@gmail.com

---

This would be especially helpful in Futures API. There are transform methods which would be improved if they had generics.

[gbracha]

Issue #7099 has been merged into this issue.

[gbracha]

Issue #11033 has been merged into this issue.

[justinfagnani]

Issue #11033 has been merged into this issue.

[lrhn]

Issue #11689 has been merged into this issue.

[lrhn]

I could easily live with generic methods without type inference. As long as you don't specify the type, it'll just default to "dynamic" anyway, but it would still improve documentation, and you can use it if you want. It's better than just using dynamic, which is the other option.

 T id<T>(T value) => value;

 int x = id<int>("not an int"); // Static type warning! Checked mode error!

So, can we have it, please?

[polux]

Same here. It would improve documentation and completion so much... (plus it would help the editor's inference for providing completion even when you don't specify the type explicitly).