Lambda expressions vs Diamond

[Neal Gafter]

You need the types of the lambda parameters to determine the result type in a lambda, which you need to do overload resolution.  So you can't delay determining the types of the parameters until after overload resolution.

Unless, of course, you're willing to have type a completely different kind of type inference.  I believe C# and Scala can both infer lambda parameter types completely, enabling you to omit their types altogether.  I think that would be a good thing to consider.  It can be done as a further extension later, too.

Cheers,
Neal

-----Original Message-----
From: Mark Mahieu <mark at twistedbanana.demon.co.uk>
Sent: Saturday, November 21, 2009 8:27 PM
To: closures-dev at openjdk.java.net
Subject: Lambda expressions vs Diamond

I'm wondering whether Diamond could/should be useable with lambda expressions, for example:

	#int(Collection<SomeLongType>) foo = #(Collection<> c) c.size();

I can imagine people intuitively expecting that to work, depending on whether they think of lambda expressions as objects with a type first and foremost, or as functions with a signature.

One downside though - if 'foo' above had been declared as a normal interface type, it would become more difficult to understand the type of 'c' (not that it's relevant in this example).


Mark