Draft JEP: Unnamed local variables and patterns

[Joseph D. Darcy]

On 10/18/2022 1:52 PM, Brian Goetz wrote:
> 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).

There were extensive discussions during the development of Project Coin 
/ JSR 334 about using TWR for non-IO resources, in particular locks. In 
the end, no specific accommodation was made for non-IO types. From the 
JSR 334 PFD discussion:

> At least in Java SE 7, a class must have a method named "close" to 
> implement the |AutoCloseable| interface and thus work with the 
> |try|-with-resources statement. To allow methods with other names like 
> "dispose" to be called at block exit instead, an adapter interface 
> with a matching factory can be used to wrap the object in question and 
> forward calls from "close" to the type-specific clean-up method. In 
> the future, it is possible other mechanisms, such as interface 
> injection, may also allow classes not declared to implement 
> |AutoCloseable| to be operated on by the |try|-with-resources statement.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221018/16c33a2a/attachment-0001.htm>