Add generic annotations to more SDK APIs.

Add generic annotations to more SDK APIs.

Fixes https://github.com/dart-lang/sdk/issues/25860 .

BUG=
R=floitsch@google.com

Committed: https://github.com/dart-lang/sdk/commit/92edd907c1d66a9c4ed3c65a801521769494af87

[Leaf, 2016-03-18 00:02:50]

leafp@google.com changed reviewers:
+ floitsch@google.com

[Leaf, 2016-03-18 00:02:50]

This is primarily to add generic annotations on Stream.transform.  While I was
at it, I added some of the other missing generic method annotations that are
present in the DDC sdk but not in the main SDK.

There are a few places where the changes can already be expressed in the
existing Dart class generics, and where possible I have done so.

[floitsch, 2016-03-18 14:46:02]

LGTM with comment.

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
File sdk/lib/async/future_impl.dart (right):

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
sdk/lib/async/future_impl.dart:194: Future/*<S>*/ then/*<S>*/(/*=S*/ f(T value),
{ Function onError }) {
That's not correct.
f is allowed to return S or a Future<S>

[Leaf, 2016-03-18 16:20:30]

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
File sdk/lib/async/future_impl.dart (right):

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
sdk/lib/async/future_impl.dart:194: Future/*<S>*/ then/*<S>*/(/*=S*/ f(T value),
{ Function onError }) {
On 2016/03/18 14:46:02, floitsch wrote:
> That's not correct.
> f is allowed to return S or a Future<S>

You can instantiate S with Future<S> when f returns Future, and then Future
flattening does the right thing on the return type.  It's a total hack, but
without union or intersection types and/or intrinsic support for the future
operations its the best we can do right now.   We could type f as returning
dynamic, but then inference won't be able to use the return type of the passed
closure to figure out the instantiation.

[floitsch, 2016-03-18 16:39:06]

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
File sdk/lib/async/future_impl.dart (right):

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
sdk/lib/async/future_impl.dart:194: Future/*<S>*/ then/*<S>*/(/*=S*/ f(T value),
{ Function onError }) {
On 2016/03/18 16:20:30, Leaf wrote:
> On 2016/03/18 14:46:02, floitsch wrote:
> > That's not correct.
> > f is allowed to return S or a Future<S>
> 
> You can instantiate S with Future<S> when f returns Future, and then Future
> flattening does the right thing on the return type.  It's a total hack, but
> without union or intersection types and/or intrinsic support for the future
> operations its the best we can do right now.   We could type f as returning
> dynamic, but then inference won't be able to use the return type of the passed
> closure to figure out the instantiation.

I don't think I agree with that type-information. It just leads to troubles in
the next '.then' call.
In other words, what should X be in the following expression?

f.then<X>(new Future.value(499)).then((int x) => x);

[Leaf, 2016-03-18 17:04:43]

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
File sdk/lib/async/future_impl.dart (right):

https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
sdk/lib/async/future_impl.dart:194: Future/*<S>*/ then/*<S>*/(/*=S*/ f(T value),
{ Function onError }) {
On 2016/03/18 16:39:05, floitsch wrote:
> On 2016/03/18 16:20:30, Leaf wrote:
> > On 2016/03/18 14:46:02, floitsch wrote:
> > > That's not correct.
> > > f is allowed to return S or a Future<S>
> > 
> > You can instantiate S with Future<S> when f returns Future, and then Future
> > flattening does the right thing on the return type.  It's a total hack, but
> > without union or intersection types and/or intrinsic support for the future
> > operations its the best we can do right now.   We could type f as returning
> > dynamic, but then inference won't be able to use the return type of the
passed
> > closure to figure out the instantiation.
> 
> I don't think I agree with that type-information. It just leads to troubles in
> the next '.then' call.
> In other words, what should X be in the following expression?
> 
> f.then<X>(new Future.value(499)).then((int x) => x);

Assuming that you mean to pass a closure to the first .then:

  f.then<Future<int>>((_) => new Future.value(499)).then<int>((int x) => x);

The first .then returns Future<Future<int>> == Future<int>, and so the second
.then expects a closure taking an int and returning an int.

Does that make sense, or am I missing the gist of your example?

[floitsch, 2016-03-22 19:24:54]

On 2016/03/18 17:04:43, Leaf wrote:
>
https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
> File sdk/lib/async/future_impl.dart (right):
> 
>
https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
> sdk/lib/async/future_impl.dart:194: Future/*<S>*/ then/*<S>*/(/*=S*/ f(T
value),
> { Function onError }) {
> On 2016/03/18 16:39:05, floitsch wrote:
> > On 2016/03/18 16:20:30, Leaf wrote:
> > > On 2016/03/18 14:46:02, floitsch wrote:
> > > > That's not correct.
> > > > f is allowed to return S or a Future<S>
> > > 
> > > You can instantiate S with Future<S> when f returns Future, and then
Future
> > > flattening does the right thing on the return type.  It's a total hack,
but
> > > without union or intersection types and/or intrinsic support for the
future
> > > operations its the best we can do right now.   We could type f as
returning
> > > dynamic, but then inference won't be able to use the return type of the
> passed
> > > closure to figure out the instantiation.
> > 
> > I don't think I agree with that type-information. It just leads to troubles
in
> > the next '.then' call.
> > In other words, what should X be in the following expression?
> > 
> > f.then<X>(new Future.value(499)).then((int x) => x);
> 
> Assuming that you mean to pass a closure to the first .then:
> 
>   f.then<Future<int>>((_) => new Future.value(499)).then<int>((int x) => x);
> 
> The first .then returns Future<Future<int>> == Future<int>, and so the second
> .then expects a closure taking an int and returning an int.
> 
> Does that make sense, or am I missing the gist of your example?

From the static-inference point-of-view that makes sense, but it doesn't really
work with how the code is dynamically checked. The moment we get semantic
support for generic methods, this won't work. You don't actually get a
Future<Future<int>> back, and the check will thus complain. Or in other words:
the code inside the 'then' instantiates a Future<T>, and the code there does
*not* flatten the type.
This is more visible in new Future (and all the other constructors). It has
exactly the same problems, but the hack already won't work there. For
constructors we keep the generic type, and there is simply no X that will work
for `new Future<X>(() => new Future.value(499) as X)`.

[Leaf, 2016-03-22 22:20:16]

On 2016/03/22 19:24:54, floitsch wrote:
> On 2016/03/18 17:04:43, Leaf wrote:
> >
>
https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
> > File sdk/lib/async/future_impl.dart (right):
> > 
> >
>
https://chromiumcodereview.appspot.com/1815583002/diff/1/sdk/lib/async/future...
> > sdk/lib/async/future_impl.dart:194: Future/*<S>*/ then/*<S>*/(/*=S*/ f(T
> value),
> > { Function onError }) {
> > On 2016/03/18 16:39:05, floitsch wrote:
> > > On 2016/03/18 16:20:30, Leaf wrote:
> > > > On 2016/03/18 14:46:02, floitsch wrote:
> > > > > That's not correct.
> > > > > f is allowed to return S or a Future<S>
> > > > 
> > > > You can instantiate S with Future<S> when f returns Future, and then
> Future
> > > > flattening does the right thing on the return type.  It's a total hack,
> but
> > > > without union or intersection types and/or intrinsic support for the
> future
> > > > operations its the best we can do right now.   We could type f as
> returning
> > > > dynamic, but then inference won't be able to use the return type of the
> > passed
> > > > closure to figure out the instantiation.
> > > 
> > > I don't think I agree with that type-information. It just leads to
troubles
> in
> > > the next '.then' call.
> > > In other words, what should X be in the following expression?
> > > 
> > > f.then<X>(new Future.value(499)).then((int x) => x);
> > 
> > Assuming that you mean to pass a closure to the first .then:
> > 
> >   f.then<Future<int>>((_) => new Future.value(499)).then<int>((int x) => x);
> > 
> > The first .then returns Future<Future<int>> == Future<int>, and so the
second
> > .then expects a closure taking an int and returning an int.
> > 
> > Does that make sense, or am I missing the gist of your example?
> 
> From the static-inference point-of-view that makes sense, but it doesn't
really
> work with how the code is dynamically checked. The moment we get semantic
> support for generic methods, this won't work. You don't actually get a
> Future<Future<int>> back, and the check will thus complain. Or in other words:
> the code inside the 'then' instantiates a Future<T>, and the code there does
> *not* flatten the type.
> This is more visible in new Future (and all the other constructors). It has
> exactly the same problems, but the hack already won't work there. For
> constructors we keep the generic type, and there is simply no X that will work
> for `new Future<X>(() => new Future.value(499) as X)`.

I think I would claim that it is a bug that Futures flatten in the static system
and not in the dynamic system.  You can write 
code that blows up in the middle of the SDK in checked mode currently because of
this.  It seems to me that 
X = Future<int> is the right answer to your example.  The static return type is
Future<Future<int>> == Future<int>
and the created runtime type likewise is (should be) Future<Future<int>> ==
Future<int>.  The cast works just fine.  

It's true that currently the runtime does not implement the equality between
Future<Future<int>> and Future<int>, but that 
seems like a bug.  I'm not a fan of future flattening myself, but doing it in
the static system and not the dynamic system is just buggy.

[Leaf, 2016-03-29 00:30:33]

Per offline discussion, I've removed the return type on the _Future.then
callback, and will look into implementing ad-hoc inference for Future.then.

[Leaf, 2016-03-29 00:52:45]

Description was changed from

==========
Add generic annotations to more SDK APIs.

Fixes https://github.com/dart-lang/sdk/issues/25860 .

BUG=
==========

to

==========
Add generic annotations to more SDK APIs.

Fixes https://github.com/dart-lang/sdk/issues/25860 .

BUG=
R=floitsch@google.com

Committed:
https://github.com/dart-lang/sdk/commit/92edd907c1d66a9c4ed3c65a801521769494af87
==========

[Leaf, 2016-03-29 00:52:46]

Committed patchset #2 (id:20001) manually as
92edd907c1d66a9c4ed3c65a801521769494af87 (presubmit successful).