Draft JEP: Unnamed local variables and patterns

Angelos Bimpoudis angelos.bimpoudis at oracle.com
Fri Oct 14 14:59:08 UTC 2022


Hello experts!

Regarding the code locations where underscore is being introduced: The EG
already agreed on local variables and lambda parameters only, for now. To recap,
this approach has the advantage of mostly lining up with the uses of `var` and
also, that it includes code locations that deal with implementation details, as
opposed to API (fields or method formal parameters). Thus, the N places where
locals are declared in Java are the following:

1. the header of an enhanced for loop
2. a local variable declaration statement in a block
3. a catch formal parameter
4. a formal parameter of a lambda expression
5. a pattern variable
6. the header of a basic for statement
7. a resource specification of a try-with-resources statement

The obvious place to start introducing the meaning of the underscore token is to
"all of these", targeting uniformity in the language. The downside is that some
of those places are pretty messy (e.g., for loops) and Java developers may not
like this.

So, this puts us in a position between two general principles: uniformity
(support all of the above) and being seen to have introduced underscore in
places where underscore shouldn't make sense.

Where things are getting confusing are the following:

6. the header of a basic for statement

At the moment, there is code out there that uses the for statement in weird
ways, like:

`for(sideEffects(), moreSideEffects(); condition() > flag;) { }`

This is admittedly already a bit confusing. Do we really want to add to that the
ability to use underscore?

`for (var _ = sideEffects(); true; ) { ... }`

That code could be refactored to:

```
var _ = sideEffects();
for (; true; ) { ... }
```

I am wondering if `_` has a place in the init list of a regular for..

7. a resource specification of a try-with-resources statement

Today we get this warning with a TWR-statement if the local is ignored:

> javac -Xlint:all MyScopedLock.java
MyScopedLock.java:23: warning: [try] auto-closeable resource ignored is never referenced in body of corresponding try statement
        try(MyScopedLock ignored = l.lock()) {
                         ^
1 warning

So here we may have a clash of philosophies for the enhanced-for and how people
use the `AutoCloseable`.

Looking forward to hearing your thoughts.

Best,
Angelos
________________________________
From: amber-spec-experts <amber-spec-experts-retn at openjdk.org> on behalf of Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Sent: 29 September 2022 19:03
To: amber-spec-experts <amber-spec-experts at openjdk.java.net>
Subject: Draft JEP: Unnamed local variables and patterns

Dear experts,

The draft JEP for unnamed local variables and patterns, that has been previously discussed on this list is available at:

https://bugs.openjdk.org/browse/JDK-8294349

Comments welcomed!
Angelos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221014/5f96a5b1/attachment.htm>


More information about the amber-spec-observers mailing list