lambda explicit type declaration. (original) (raw)

Remi Forax forax at univ-mlv.fr
Thu Nov 29 01:44:02 PST 2012

Sergey Kuksenko recently sent a mail on lambda-dev mailing list resurrecting an old issue, inferred formal parameter types are usually boxed type but users can easily think there are primitives, and we don't have a good answer for that.

I don't think we should allow more boxing rules now, it's too late and given that it currently not compile, these rules can be added later. But I think javac should emit a warning if == or != is used on values that have their type inferred.

cheers, Rémi

On 11/26/2012 02:31 PM, Maurizio Cimadamore wrote:

Rules could be more flexible and match those used for method references - said that, some motivations behind current rules are:

*) the current rules are clearer as to what types are being used in a lambda body in an implicit lambda (i.e. same types as the target type) - note that a method reference doesn't have an analogous of a 'body' - in the lambda it seems it's useful to know what the types of the parameters will be, so that you know which members will be available on them. If you add a lot of conversion rules, the type might be not immediately obvious to the user. *) More precise overload resolution - i.e. by putting explicit types you will have the ability to effectively select which (among the set of ambiguous methods) will be selected. I also believe that inner classes were a bit in the back of our minds when designing this - i.e. we basically wanted lambdas and anonymous inner classes to be inter-changeable - it is true that once you add method references to the picture you have another construct that behaves slightly different, and that can be confusing too. Maurizio On 26/11/12 12:40, Sergey Kuksenko wrote: Hi,

I'd like to ask about lambda with explicit parameters type declaration. There is a difference between method reference and lambda. Method reference parameters should be assignable to types of functional interface method parameters, but lambda parameters should be the same as types of functional interface method parameters. Different rules leads to inconsistency between lambda & method references (it is my opinion - I understand that others may think such inconsistency is ok). I think such strict rule for lambda makes less value of the ability to declare lambda parameter types explicitly. Let's consider a couple examples. 1. Well known "boxed value equals" problem. Comparator wrongcomparator = (x, y) -> (x < y) ? -1 : ((x == y) ? 0 : 1);_ _And I expecting more similar bugs in the new code with lambdas,_ _especially in places where generic boxed and specialised primitive_ _functional interfaces are used. Developers will misthink, misprint,_ _misevaluate type inference ...._ _The best (IMO) way to fix the problem is not allowed right now:_ _Comparator fixedcomparator = (int x, int y) -> (x < y) ? -1 : ((x == y) ? 0 : 1);_ _// won't compile._ _Other ways to fix it are not such simple like:_ _Comparator fixedcomparator = (a,b) -> { int x = a; int y = b; return (x < y) ? -1 : ((x == y) ? 0 : 1); };

[...]

More information about the lambda-libs-spec-observers mailing list