<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"John Rose" <john.r.rose@oracle.com>, "Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Angelos Bimpoudis" <angelos.bimpoudis@oracle.com>, "amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Sent: </b>Tuesday, October 18, 2022 10:52:09 PM<br><b>Subject: </b>Re: Draft JEP: Unnamed local variables and patterns<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">I come to the same conclusion as John, but from a slightly different
angle.<br>
<br>
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. </blockquote><div><br></div><div>yes, that can be an issue.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">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.) <br>
<br>
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). </blockquote><div><br></div><div>In that case TWR should be available as an expression too, i would be handy by example for the StructuredTaskScope of Loom,<br></div><div> var result = try(var scope = new StructuredTaskScope<String>()) {<br data-mce-bogus="1"></div><div> var future1 = scope.fork(...);</div><div> var future2 = scope.fork(...);<br data-mce-bogus="1"></div><div> scope.join();<br data-mce-bogus="1"></div><div> yield future1.resultNow() + future2.resultNow();<br data-mce-bogus="1"></div><div> };<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>To John:<br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
<br>
<blockquote cite="mid:5EB235EC-5CEA-4618-9086-8C85AF9C812C@oracle.com">
<div style="font-family: sans-serif;">
<div class="markdown" style="white-space: normal;">
<p dir="auto">I think the opposite on this one. It seems to me
that using <code style="margin: 0; padding: 0 0.4em;
border-radius: 3px; background-color: #F7F7F7;">_</code>
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?</p></div></div></blockquote></blockquote><div><br></div><div>The idea of the actual warning is to avoid<br data-mce-bogus="1"></div><div> lock.lock();<br data-mce-bogus="1"></div><div> try(AutoCloseable _ = lock::unlock) {<br data-mce-bogus="1"></div><div> ...<br data-mce-bogus="1"></div><div> }<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>because using a try/finally is more readable<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div> lock.lock();<br data-mce-bogus="1"></div><div> try {<br data-mce-bogus="1"></div><div> ...<br data-mce-bogus="1"></div><div> } finally {<br data-mce-bogus="1"></div><div> lock.unlock();<br data-mce-bogus="1"></div><div> }<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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.<br data-mce-bogus="1"></div><div>Another way to see the issue is that TWR does not work well if the close() is not idempotent.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br></div></div></div></body></html>