simplify inference of generic function types

simplify inference of generic function types

removes the support for finding a partial solution

[Jennifer Messerly, 2016-07-01 01:06:45]

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

[Jennifer Messerly, 2016-07-01 21:56:15]

Hi Leaf,

I may merge this into an upwards inference CL I'm working on, so curious about
your thoughts. :)

Here's an example of a case that was (arguably) made worse by the partial
inference code path, and is what motivated me to send this CL:

    class A<S, T> { A(S s, T t); }
    A<int, String> a = new A('hi', 42);

What we used to do is push down `<int, String>`, and issue an error for each
parameter to the constructor. But once I integrated upwards inference, it would
hit the "partial solution" code and conclude `A<dynamic, dynamic>`, resulting in
a DownCastComposite warning about assigning `A<dynamic, dynamic>` to `A<int,
String>`. It's a shame because we know the code is incorrect during inference,
but we're losing that info and sort of trying to muddle through using `dynamic`.

Thinking on this more, an alternate idea: if we encounter an error, we could use
only the return type context information. That would sort of get us the best of
both worlds. (We already special case the return type -- the position that the
type variable T occurs in the return type is part of the heuristic of whether to
prefer the lower or upper bound for T.)

[Leaf, 2016-07-12 20:10:57]

On 2016/07/01 21:56:15, John Messerly wrote:
> Hi Leaf,
> 
> I may merge this into an upwards inference CL I'm working on, so curious about
> your thoughts. :)
> 
> Here's an example of a case that was (arguably) made worse by the partial
> inference code path, and is what motivated me to send this CL:
> 
>     class A<S, T> { A(S s, T t); }
>     A<int, String> a = new A('hi', 42);
> 
> What we used to do is push down `<int, String>`, and issue an error for each
> parameter to the constructor. But once I integrated upwards inference, it
would
> hit the "partial solution" code and conclude `A<dynamic, dynamic>`, resulting
in
> a DownCastComposite warning about assigning `A<dynamic, dynamic>` to `A<int,
> String>`. It's a shame because we know the code is incorrect during inference,
> but we're losing that info and sort of trying to muddle through using
`dynamic`.
> 
> Thinking on this more, an alternate idea: if we encounter an error, we could
use
> only the return type context information. That would sort of get us the best
of
> both worlds. (We already special case the return type -- the position that the
> type variable T occurs in the return type is part of the heuristic of whether
to
> prefer the lower or upper bound for T.)

This got moved into the other CL, right?  Or is this still live?

[Jennifer Messerly, 2016-07-12 20:29:46]

On 2016/07/12 20:10:57, Leaf wrote:
> On 2016/07/01 21:56:15, John Messerly wrote:
> > Hi Leaf,
> > 
> > I may merge this into an upwards inference CL I'm working on, so curious
about
> > your thoughts. :)
> > 
> > Here's an example of a case that was (arguably) made worse by the partial
> > inference code path, and is what motivated me to send this CL:
> > 
> >     class A<S, T> { A(S s, T t); }
> >     A<int, String> a = new A('hi', 42);
> > 
> > What we used to do is push down `<int, String>`, and issue an error for each
> > parameter to the constructor. But once I integrated upwards inference, it
> would
> > hit the "partial solution" code and conclude `A<dynamic, dynamic>`,
resulting
> in
> > a DownCastComposite warning about assigning `A<dynamic, dynamic>` to `A<int,
> > String>`. It's a shame because we know the code is incorrect during
inference,
> > but we're losing that info and sort of trying to muddle through using
> `dynamic`.
> > 
> > Thinking on this more, an alternate idea: if we encounter an error, we could
> use
> > only the return type context information. That would sort of get us the best
> of
> > both worlds. (We already special case the return type -- the position that
the
> > type variable T occurs in the return type is part of the heuristic of
whether
> to
> > prefer the lower or upper bound for T.)
> 
> This got moved into the other CL, right?  Or is this still live?

Yup, merged! closing this one.