lambda expression parameters

[Venkat Subramaniam]

Over the past couple of years I have been caught at least twice by bugs where I wasted significant time.
In both cases, the programmer had modified the parameter of the method and in the process
introduced the bugs. I have since started marking my method parameters final (call me paranoid).
I find it really odd that anyone would want to modify the parameters, but I have seen it happen.
One thing I really appreciate in languages that support functional style (hybrid or not) is the treatment
of parameters as final by default. I fully understand this can't be done for Java for regular methods.
I sincerely thing this is a good opportunity for such treatment for parameters to lambda expressions.
I hope this is given a good consideration among the key decision makers. Thank you.

Venkat

On Dec 19, 2012, at 9:04 AM, Ricky Clarkson <ricky.clarkson at gmail.com> wrote:

> I'd just like to raise one potential case for making it implicitly final:
> 
> Iterable<Boolean> list = someNumbers.map(x -> x = 5);
> 
> (If it really returns a Stream, Streamable, CanBeStreamed or
> NotTonightDearImBusyStreaming, please give me some leeway.)
> 
> The programmer is left wondering why the compiler says that map returns an
> Iterable<Integer> instead of an Iterable<Boolean>, and it's all because he
> used = instead of ==.  The programmer then wonders why Java didn't just
> give him a compile error when he assigned to the parameter, after all
> assigning to the parameter there is basically a no-op.
> 
> 
> On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> 
>> On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith <daniel.smith at oracle.com>
>> wrote:
>>> On Dec 18, 2012, at 5:43 PM, David Holmes <David.Holmes at oracle.com>
>> wrote:
>>> 
>>>> I don't grok the problem. If the parameter is not modified then it is
>>>> effectively final. Making parameters final is then only an
>>>> error-detection mechanism, and I don't see that is warranted in lambda
>>>> expressions. So I don't see "final by default" as warranted.
>>>> 
>>>> Having to add back the inferred type to enable final to be added doesn't
>>>> seem like a large burden.
>>> 
>>> Yeah, I think I agree with David.  The times when it seems most useful
>> to say "this parameter is final and I definitely don't want anyone changing
>> it" are when you've got a large lambda body, and then it's really not so
>> painful to give your parameters full declarations ('final String s').
>>> 
>>> It's worth noting that 'final' parameters and local variables didn't
>> exist in the original language and were only added to support the "captured
>> variables must be final" rule when anonymous/local classes were added.  If
>> "effectively final" were an option back then (don't know if it's something
>> they thought about or not), I would bet we still wouldn't have 'final'
>> parameters and local variables.  They're really a lot less useful than
>> 'final' fields -- because all interaction is in a single thread and within
>> a single block of code.
>> 
>> Agreed, although most method parameters and many local variables are
>> conceptually final, people don't bother to mark them final.
>> 
>> Making method parameters implicitly final is inconsistent with
>> existing practices; the benefit is dubious:
>> 
>> If a programmer assigns a new value to a method parameter, and later
>> reads it, it is very likely intentional, there's no need for alarm
>> here.
>> 
>> If a programmer assigns a new value to a method parameter, and never
>> reads it, it is probably a mistake; fortunately IDEs will raise a
>> warning for it.
>> 
>> Zhong Yu
>> 
>>> 
>>>> On the other hand can't the compiler accept
>>>> parameter modifiers even if it infers the type?
>>> 
>>> No, there are two syntax options: list of identifiers, or full method
>> parameter list.  Less complex that way.
>>> 
>>> —Dan
>>> 
>> 
>> 
>