> From: "Brian Goetz" <[email protected]>
> To: "John Rose" <[email protected]>, "Remi Forax" <[email protected]>
> Cc: "Angelos Bimpoudis" <[email protected]>, "amber-spec-experts"
> <[email protected]>
> Sent: Tuesday, October 18, 2022 10:52:09 PM
> Subject: Re: Draft JEP: Unnamed local variables and patterns
> 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.
yes, that can be an issue.
> 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).
In that case TWR should be available as an expression too, i would be handy by
example for the StructuredTaskScope of Loom,
var result = try(var scope = new StructuredTaskScope<String>()) {
var future1 = scope.fork(...);
var future2 = scope.fork(...);
scope.join();
yield future1.resultNow() + future2.resultNow();
};
To John:
>> 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?
The idea of the actual warning is to avoid
lock.lock();
try(AutoCloseable _ = lock::unlock) {
...
}
because using a try/finally is more readable
lock.lock();
try {
...
} finally {
lock.unlock();
}
and TWR mess with exception in case lock.unlock() is called without holding the
lock and there is an exception thrown in the body of the TWR.
Another way to see the issue is that TWR does not work well if the close() is
not idempotent.
For me TWR is too tailored to the management of IO resources, trying to re-use
it for RAII is a mistake and try/finally is already the way to implement the
same idea as RAII in Java.
Rémi
