Draft JEP: Unnamed local variables and patterns

John Rose john.r.rose at oracle.com
Tue Oct 18 20:30:34 UTC 2022


On 18 Oct 2022, at 7:47, Remi Forax wrote:

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

I think the opposite on this one.  It seems to me that using `_` is an 
excellent way to mute that warning.  I find it annoyingly opinionated:  
Why shouldn’t I expect to use TWR to simulate the RAII-style 
open/close events from C++, without lint bumping my elbow?

> If we allow '_', it means that we are in a way able to call _.close().

The documentation for desugaring TWR can just introduce a new name if 
necessary; the JLS introduces unnamed temps all the time and this is 
just another place for one.

>
> 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, _;

I agree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221018/324b6123/attachment-0001.htm>


More information about the amber-spec-observers mailing list