Serialization stability and naming (and syntax)

[David M. Lloyd]

On 09/30/2012 11:14 AM, Brian Goetz wrote:
>> Your point is that the benefits to stability of serialized forms are very small, and I'm inclined to agree.  But for what other reasons are names useful?  We've talked about how that name could appear in toString output and in stack traces.
>
> Named lambdas are potentially useful for:
>   - stack traces, toString
>   - nonlocal return
>   - recursion
>   - serialization
>
> Of these, its seeming that serialization is not important enough to add naming, and clearly nonlocal return is not, since we don't have that.  Ditto for recursion.  So that leaves stack traces / toString.
>
> A few folks have suggested the syntax
>     name(args) -> body
>
> for named lambdas but I think this is impractical; the interaction with inferred parameter types renders the confusion between method invocations and lambdas too great:
>
>    foo(x, y) -> x+y
>
> looks too much like a method invocation.
>
> We also considered a label-like scheme:
>
> (name: x, y, z) -> body
>
> But in any case, something like @Serial(name) lambda would really be bad, because then we would *only* be able to use the name for serialization.
> 
>> So, at issue is: do we need the ability to name lambdas at all?
>
> Need?  No.  Nice to have?  Yes.  Willing to pick an ugly syntax?  Probably not.

If the problem is limited to *just* stack traces and toString, choosing 
a name based on the defining scope seems reasonable.  For method 
references you have a name obviously (it would be surprising if it 
looked too far removed from a normal invocation); for other cases just 
pick the enclosing type or method name and add a tag to it to identify 
it as a lambda declared within that scope (maybe with a number for 
disambiguation).  So if method Foo.bar() contains a lambda it could show 
up on the stack trace as
   ...
   at org.blah.Foo.bar[lambda#8](Foo.java:123)
   ...

-- 
- DML