Improve Future<T>.then<R> inference

Improve Future<T>.then<R> inference

This is not a general fix, but it's a simplest fix I could come up with.

It fixes the common problem of downwards and upwards inference conflicting. On the way down, we use the return context, but on the way back up, we ignore it for `Future.then`. This allows inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it works out).

Many of the other example cases are not fixed, though. Downwards inference will only push down `R` not `Future<R> | R`, so if the Future<R> branch was needed, for example: Future<Lint<int>> g = f.then(() => new Future.value([])) will not infer the `<int>[]` allocation nor the `Future<List<int>>` type. I have a work-in-progress that fixes those but introduces a special union type notion for `Future<R> | R`, and I'm not sure we're ready for that.

R=leafp@google.com

Committed: https://github.com/dart-lang/sdk/commit/5fcf79c6180337231e02857b0c206ee64c23efcc

[Jennifer Messerly, 2016-05-26 18:53:16]

Description was changed from

==========
Improves Future<T>.then<R> inference

This is not a general fix, but it's a simple fix for the common problem of
downwards and upwards inference conflicting.
==========

to

==========
Improves Future<T>.then<R> inference

This is not a general fix, but it's a simple fix for the common problem of
downwards and upwards inference conflicting. On the way down, we use the return
context, but on the way back up, we ignore it for Future.then. This allows
inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return
type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it
works out).

Many other cases are not fixed, though. Downwards inference will only push down
`R` not `Future<R> | R`, so if the Future<R> branch was needed, for example:
Future<Lint<int>> g = f.then(() => new Future.value([])) will not infer the
`<int>[]` allocation nor the `Future<List<int>>` type. I have a work-in-progress
that fixes those but introduces a special union type notion for `Future<R> | R`,
and I'm not sure we're ready for that.
==========

[Jennifer Messerly, 2016-05-26 18:53:16]

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

[Jennifer Messerly, 2016-05-26 18:54:37]

Description was changed from

==========
Improves Future<T>.then<R> inference

This is not a general fix, but it's a simple fix for the common problem of
downwards and upwards inference conflicting. On the way down, we use the return
context, but on the way back up, we ignore it for Future.then. This allows
inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return
type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it
works out).

Many other cases are not fixed, though. Downwards inference will only push down
`R` not `Future<R> | R`, so if the Future<R> branch was needed, for example:
Future<Lint<int>> g = f.then(() => new Future.value([])) will not infer the
`<int>[]` allocation nor the `Future<List<int>>` type. I have a work-in-progress
that fixes those but introduces a special union type notion for `Future<R> | R`,
and I'm not sure we're ready for that.
==========

to

==========
Improves Future<T>.then<R> inference

This is not a general fix, but it's a simplest fix I could come up with.

It fixes the common problem of downwards and upwards inference conflicting. On
the way down, we use the return context, but on the way back up, we ignore it
for `Future.then`. This allows inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return
type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it
works out).

Many of the other example cases are not fixed, though. Downwards inference will
only push down `R` not `Future<R> | R`, so if the Future<R> branch was needed,
for example: Future<Lint<int>> g = f.then(() => new Future.value([])) will not
infer the `<int>[]` allocation nor the `Future<List<int>>` type. I have a
work-in-progress that fixes those but introduces a special union type notion for
`Future<R> | R`, and I'm not sure we're ready for that.
==========

[Jennifer Messerly, 2016-05-26 18:54:46]

Description was changed from

==========
Improves Future<T>.then<R> inference

This is not a general fix, but it's a simplest fix I could come up with.

It fixes the common problem of downwards and upwards inference conflicting. On
the way down, we use the return context, but on the way back up, we ignore it
for `Future.then`. This allows inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return
type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it
works out).

Many of the other example cases are not fixed, though. Downwards inference will
only push down `R` not `Future<R> | R`, so if the Future<R> branch was needed,
for example: Future<Lint<int>> g = f.then(() => new Future.value([])) will not
infer the `<int>[]` allocation nor the `Future<List<int>>` type. I have a
work-in-progress that fixes those but introduces a special union type notion for
`Future<R> | R`, and I'm not sure we're ready for that.
==========

to

==========
Improve Future<T>.then<R> inference

This is not a general fix, but it's a simplest fix I could come up with.

It fixes the common problem of downwards and upwards inference conflicting. On
the way down, we use the return context, but on the way back up, we ignore it
for `Future.then`. This allows inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return
type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it
works out).

Many of the other example cases are not fixed, though. Downwards inference will
only push down `R` not `Future<R> | R`, so if the Future<R> branch was needed,
for example: Future<Lint<int>> g = f.then(() => new Future.value([])) will not
infer the `<int>[]` allocation nor the `Future<List<int>>` type. I have a
work-in-progress that fixes those but introduces a special union type notion for
`Future<R> | R`, and I'm not sure we're ready for that.
==========

[Leaf, 2016-05-26 23:01:32]

lgtm

[Jennifer Messerly, 2016-05-27 00:02:50]

Description was changed from

==========
Improve Future<T>.then<R> inference

This is not a general fix, but it's a simplest fix I could come up with.

It fixes the common problem of downwards and upwards inference conflicting. On
the way down, we use the return context, but on the way back up, we ignore it
for `Future.then`. This allows inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return
type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it
works out).

Many of the other example cases are not fixed, though. Downwards inference will
only push down `R` not `Future<R> | R`, so if the Future<R> branch was needed,
for example: Future<Lint<int>> g = f.then(() => new Future.value([])) will not
infer the `<int>[]` allocation nor the `Future<List<int>>` type. I have a
work-in-progress that fixes those but introduces a special union type notion for
`Future<R> | R`, and I'm not sure we're ready for that.
==========

to

==========
Improve Future<T>.then<R> inference

This is not a general fix, but it's a simplest fix I could come up with.

It fixes the common problem of downwards and upwards inference conflicting. On
the way down, we use the return context, but on the way back up, we ignore it
for `Future.then`. This allows inference to conclude an instantiation like:

    f.then/*<Future<int>>*/(...)

Then, thanks to Future flattening, we get the right return type as well (return
type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it
works out).

Many of the other example cases are not fixed, though. Downwards inference will
only push down `R` not `Future<R> | R`, so if the Future<R> branch was needed,
for example: Future<Lint<int>> g = f.then(() => new Future.value([])) will not
infer the `<int>[]` allocation nor the `Future<List<int>>` type. I have a
work-in-progress that fixes those but introduces a special union type notion for
`Future<R> | R`, and I'm not sure we're ready for that.

R=leafp@google.com

Committed:
https://github.com/dart-lang/sdk/commit/5fcf79c6180337231e02857b0c206ee64c23efcc
==========

[Jennifer Messerly, 2016-05-27 00:02:52]

Committed patchset #1 (id:1) manually as
5fcf79c6180337231e02857b0c206ee64c23efcc (presubmit successful).