Variable number of parameters

Rémi Forax forax at univ-mlv.fr
Mon Dec 5 17:37:22 PST 2011


On 12/06/2011 01:08 AM, Vitaly Davidovich wrote:
> I should clarify that C# allowing the case when no parameters are used is
> for anonymous methods, not lambda syntax, so maybe an invalid comparison.

The question is what is a valid expression when the
type of a hidden local variable is used as return type.

interface Identity<I> {
   I identity(I i);
}
<I> void foo(Identity<I> identity) { ... }

so are these calls valid ?
foo( () -> null );
foo( () -> "bar" );
foo( () -> 42 );

It may break one important rule of the  spec
is that the return value of the lambda expression
is not involved in the inference.

Rémi

> On Dec 5, 2011 7:05 PM, "Vitaly Davidovich"<vitalyd at gmail.com>  wrote:
>
>> This probably comes down to cost/benefit - it would seem that the
>> complication in inference and disambiguation isn't worth the cost for such
>> a minor convenience.
>>
>> C#, for example, does not support this type of thing either (they do
>> support the case where you don't use any of the parameters though).
>>
>> Just my 2 pennies though ...
>> On Dec 5, 2011 6:23 PM, "Stephen Colebourne"<scolebourne at joda.org>  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