Type inference of parameters

Stephen Colebourne scolebourne at joda.org
Thu Jul 8 02:31:00 PDT 2010

On 8 July 2010 00:06, maurizio cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> I think an example of problematic overload resolution would be the
> following:
> ...
> In the general case, it is not clear how the compiler should attribute the
> lambda body when there is no unique target for the SAM conversion; one
> option would be to do a trial-and-error attribution, as described in [1].
> Instead of solving a problem by introducing another one (as Josh said in a
> separate post, Java method resolution is one of the most complicated parts
> of the language), we decided to ban this kind of type-inference - eventually
> the user will be able to disambiguate at the call site in a very java-ish
> fashion:
> call(SAM1 { x -> System.out.println(x); });

I find the conservative approach to be reasonable here, as I don't
think it will occur that often, and is simple to understand and
explain. Were the inference to extend to counting the number of
parameters in the lambda, I would also support that, but lub type
calculations seem a step too far.

BTW, I really don't like the new syntax suggestion, and I believe
there were obvious ways to extend the previous syntax to support the
newly required prefix type.


More information about the lambda-dev mailing list