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