Draft JEP: Unnamed local variables and patterns

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "John Rose" <john.r.rose at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Angelos Bimpoudis" <angelos.bimpoudis at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221018/54bac78c/attachment-0001.htm>