Draft JEP: Unnamed local variables and patterns

[Remi Forax]

the previous message was sent too fast, sorry for the inconvenience, 

> From: "Angelos Bimpoudis" < angelos.bimpoudis at oracle.com >
> To: "amber-spec-experts" < amber-spec-experts at openjdk.java.net >
> Sent: Friday, October 14 , 2022 4:59:08 PM
> Subject: Re: Draft JEP: Unnamed local variables and patterns

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

Does the code make no sense or can it be written in a better way ? 

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

Given that people already write things like 
for(boolean unused = sideEffects(); ...;) { ... } 
i think that replacing "unused" by '_' is a step forward. 

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

I think we should disallow '_' here, mostly because the variable is used to call close() so i think it is a good idea to maintain the idea that a try-with-resources is just a syntactic sugar on top of a try/finally that call close(). 
If we allow '_', it means that we are in a way able to call _.close(). 

The other case is the case (2), should we allow '_' in a middle of an init list, i think that like with 'var' we should not allow '_' in an init list. 
So reject 
int x, _; 

> Looking forward to hearing your thoughts.

> Best,
> Angelos

regards, 
Rémi 

> 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 |
> 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/20221018/ddc2ef2c/attachment.htm>