hg: lambda/lambda/langtools: Next round of implementation reflecting the latest 'State of the Lambda' draft; implemented features are:

[Neal Gafter]

This issue is independent of overload resolution.  The automatic conversion
of a lambda to a SAM type does not in any way ensure that the lambda obeys
the SAM's contract.

On Mon, Jul 26, 2010 at 2:08 PM, Neal Gafter <neal at gafter.com> wrote:

> The issue of lambdas converting to "tagging" SAMs exists independent of
>
> -Neal
>
> On Jul 26, 2010, at 2:02 PM, "Nathan Bryant" <nathan.bryant at linkshare.com>
> wrote:
>
> > Right, because (just as scala.Nothing is a subtype of every type)
> > lambdas are widening-convertible to every compatible SAM type. I get
> > that.
> >
> > The point was that the call site:
> >
> > (1) foo({x -> something})
> >
> > is inherently different from the call site:
> >
> > (2) foo(SomeTaggingInterface {x -> something})
> >
> > If we infer that (1) is the same as (2) in the presence of an overloaded
> > foo(), we've added a new source of surprise to the language. Maybe it's
> > not the most common use case, but there is no such opportunity for
> > surprise with tagging interfaces today.
> >
> > -----Original Message-----
> > From: neal.gafter at gmail.com [mailto:neal.gafter at gmail.com] On Behalf Of
> > Neal Gafter
> > Sent: Monday, July 26, 2010 4:48 PM
> > To: Nathan Bryant
> > Cc: Neal Gafter; Joe Darcy; maurizio.cimadamore at oracle.com;
> > lambda-dev at openjdk.java.net
> > Subject: Re: hg: lambda/lambda/langtools: Next round of implementation
> > reflecting the latest 'State of the Lambda' draft; implemented features
> > are:
> >
> > The "more specific" analysis doesn't depend on knowing the argument
> > types.
> >
> > On Monday, July 26, 2010, Nathan Bryant <nathan.bryant at linkshare.com>
> > wrote:
> >> The usual rules would seem to be appropriate when the parameter type
> > is known. In this case, it is not.
>