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
