Serialization stability and naming (and syntax)

[Brian Goetz]

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