lambda expression parameters

[Ricky Clarkson]

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
> >
>
>