Unnamed variables and match-all patterns

[Guy Steele]

On Sep 7, 2022, at 1:41 PM, Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:
. . .

Where we stumble is on method parameters, because method parameter names serve two masters -- the implementation (as the declaration of a variable) and the API (as part of the specification of what the method does.)  Among other things, we like to document the semantics of method parameters in Javadoc with the `@param` tag, but doing so requires a name

And a general language-design pattern is that if you discover a single language feature is serving two masters, consider splitting it into two features, one to serve each master (and then perhaps continue to allow the old feature, explaining it in terms of the new, more general features.

In this case, a single feature (method parameter name) provides both a name for the implementation and a name for the API. So, consider having a way to provide two names. Common Lisp has been doing this for its keyword parameters for almost four decades:

(defun foo (&key ((:color c) white) ((:angle a) 0))
   … c … a …)

(foo :color black :angle 45)

So the names :color and :angle are part of the API, and the names c and a are the variable names that are actually bound for use in the body.

When you write

(defun baz (&key (color white) (angle 0))
  … color … angle)

it is by definition an abbreviation for

(defun baz (&key ((:color color) white) ((:angle angle) 0))
  … color … angle)

So you don’t have to write out two names in the common case where you actually do want them to be “the same”.

————

So in Java we could pick some crazy syntax to allow specifying two names for a method parameter, the API name and the implementation (bound variable) name:

int colorHack(int red=>r, int green=>g, int blue=>b, int fromIndex=>from, int toIndex=>to) {
// Here the names `r`, `g`, `b`, `from`, and `to` are in scope.
}

and then if you really want to ignore a parameter:

int colorBlindHack(int red=>_, int green=>_, int blue=>_, int fromIndex=>from, int toIndex=>to) {
// Here the names `from` and `to` are in scope.
}

Not sure we want to go in that direction, but we should at least consider it.

—Guy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20220908/c33b5c68/attachment.htm>