Multiple variables/fields in same score with name '_' should be allowed

[retronym]

The idea of a compiler generated quasi-unique name is that if it appears in
api, you need it to be stable over time so that you don’t need to recompile
callers all the time.

Jason

[retronym]

The idea of a compiler generated quasi-unique name is that if it appears
in api, you need it to be stable over time so that you don’t need to
recompile callers all the time.

*Problem with the idea

[nafg]

@retronym I guess you mean if it’s implicit? I think it’s fair to disallow it outside of private or local scope.

[Blaisorblade]

@nafg

In short, the consistent options are:

(A) and (C) compile and work – implement #1 and #2. (B) doesn’t compile because defs can’t use patterns.

I like @nafg’s analysis and this proposal in particular.

Like others, I don’t like the idea of using _ for object fields, but @newhoggy’s argument here seems strong enough to deserve an answer.

@newhoggy

The object referenced by the field may not be able to be accessed directly via this field, but it may be accessed via another reference, for example a WeakReference, in which case the the inaccessible field expresses ownership rather than accessibility.

I think this is the correct behaviour because it is the least surprising. I should be able to fearless modify val _ to val name and vice-versa without changing the behaviour of the code.

That refactoring seems indeed reasonable. But going from val _ = expr to expr also seems reasonable (with different assumptions on _), yet it must make the result of expr garbage-collectable.

Anyway, since that refactoring might seem reasonable enough to try it, it should preserve behavior or give a compile-time error—as it does now, so we should keep that. The best rationale is that local scope and class/trait/object scope are not actually the same in Scala after all—even though they’re both templates in terms of the spec.

If you still believe all templates should really be the same: you have a point, but the JVM is not the platform you want. The concept of template comes instead from other languages, where methods are classes and stack frames are objects, having local variables as fields, like in Smalltalk, Python, etc. The actual concept of template comes from research language Beta AFAIK, but the rest is more common. That approach is more consistent, but IMHO it leads to outlawing underscore-named variables altogether. And you can’t make local variables into object fields efficiently without VM support (assuming you’d want that, which is far from obvious).

Fun thing is, people learned in the '80s how to do efficient VM support for locals = fields, for efficient Smalltalk JITs, and Hotspot comes from a Smalltalk implementation, so I assume they just ripped out this support.