Inferring lambda parameter types in an argument position

[Neal Gafter]

On Sat, Mar 5, 2011 at 4:18 AM, maurizio cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> *a.F( x -> x.G( y -> H(x, y) ) )*
> The above is quite nasty - in general you only will be able to establish
> members of the type of an unspecified lambda parameter after a type for it
> has been inferred (which should be done by looking at the expected formal
> type during overload resolution). Depending on which strategy we decide to
> support in the spec, 'x.G' might or might not be a typable expression (e.g.
> part of the problem is that doing overload resolution with partially
> inferred types could lead to selecting a method that could turn out to be
> inapplicable when all inference variables have been inferred).  The design
> space is very big - I think the best solution would be to find a resonable
> compromise between expressiveness and language complexity; speaking of
> which, all examples submitted in this mailing list and the experiments we
> are starting to make on collections are surely a valuable resource to drive
> design of type-inference forward.
>

I would like to point out that C# handles such cases quite well, even though
its specification for type inference is fairly simple.  It might be valuable
to learn the extent to which C#'s techniques could be applied to Java.