Variable number of parameters

Brian Goetz brian.goetz at oracle.com
Mon Dec 5 17:37:21 PST 2011


I don't think we'll be doing that.  As you point out, it interferes with 
target type inference.  (What you suggest is more natural in a 
functional language where tuples are subtyped inclusively (i.e., 
Tuple(T,U) <: Tuple(T,U,V)), and where argument list are treated as 
tuples.  But that's a pretty foreign concept in Java.)  In any case, I 
don't think this feature pulls its weight.  Saying (v, i) -> ... is just 
not that much more typing than (v) -> ...

What we did consider was allowing the use site to omit *all* the 
parameters when they are unneeded, such as is common with certain event 
listener APIs where the parameters carry information that is not always 
needed.  (Think of this as inferring the arity.)  Though this was a 
better intuitive match with the syntax that supported the #{ ... } 
nilary syntax than it is with the current () -> {} syntax.


On 12/5/2011 6:22 PM, Stephen Colebourne wrote:
> Consider this looping method (on a DoubleList class for simplicity of
> discussion):
>
> interface IndexedBlock {
>    void apply(Double value, int index);
> }
> class DoubleList {
>    public void each(IndexedBlock block);
> }
>
> To fulfil this functional interface, the writer of the lambda must
> specify two parameters:
>
>   list.each( (value, index) ->  print("Index " + index + " value " + value) );
>
> But, it would be convenient to be able to only specify the index if
> required when writing the lambda:
>
>   list.each( value ->  print("Value " + value) );  // this still uses
> IndexedBlock!
>
> The example here is based on Fantom, but probably occurs in other
> languages. It is important, because it affects the way in which the
> APIs are designed - access to the index while looping can be provided
> with an additional parameter that is only used when necessary, rather
> than needing to provide a separate "eachIndexed()" method.
>
> Of course, such an approach complicates inference, and adds
> complexity, taking lambdas further away from inner classes. Its
> possible that the EDR allows this, but I don't think it does.
>
> I raise it as I don't recall a discussion here about this (not because
> I necessarily think its right for Java).
>
> Stephen
>


More information about the lambda-dev mailing list