Draft JEP: Unnamed local variables and patterns
Brian Goetz
brian.goetz at oracle.com
Tue Oct 18 20:52:09 UTC 2022
I come to the same conclusion as John, but from a slightly different angle.
First, I'm not thrilled with the idea of specifying TWR via desugaring
at all; it means that accidental artifacts of specification end up being
weighted too seriously. But I also think that TWR suffers from failure
of imagination (it is too IO-specific) and also that it suffers from
other accidental issues (such as, using an interface for AC, which
forces us to pick a name that might be great for IO but lousy for
arbitrary resources. A type class would be better, when we have them.)
So I would prefer to raise our sights on TWR towards the construct we
would like to work towards (just as we raised up switch from the gutter
of byte-stream parsing).
> 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-experts/attachments/20221018/148f2219/attachment.htm>
More information about the amber-spec-experts
mailing list