Draft JEP: Unnamed local variables and patterns

[Brian Goetz]

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>