Serialization stability and naming (and syntax)
David M. Lloyd
david.lloyd at redhat.com
Sun Sep 30 14:24:13 PDT 2012
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
More information about the lambda-spec-observers