<div dir="auto">I agree that it seems like a minor improvement to remove 1 level if nesting. But it removes 1 level of nesting per individualy managed recourse (taking into consideration that you can group resources in 1 try block).<div dir="auto">I would argue that it isn't really a completely new feature but an ergonomic addition to the existing of try resource. It would be handled completely by the preprocessor (or however syntactic sugar is implemented).</div><div dir="auto">Regarding the coupling of object and resource scope. I would argue that resource scopes naturally align with method scopes since the single responsibility of the method would be something regarding the closable resource.</div><div dir="auto">Regarding refactoring I don't think tools would have a hard time refactoring:</div><div dir="auto"><br></div><div dir="auto">void foo() {</div><div dir="auto"><span style="white-space:pre"> </span>try (var foo = new Foo()) {</div><div dir="auto"><span style="white-space:pre"> </span>foo.bar();</div><div dir="auto"><span style="white-space:pre"> </span>} </div><div dir="auto">}</div><div dir="auto">To:</div><div dir="auto">void foo() {</div><div dir="auto"><span style="white-space:pre"> </span>try (var foo = new Foo());</div><div dir="auto"><span style="white-space:pre"> </span>foo.bar();</div><div dir="auto">}</div><div dir="auto">And back. This refactoring can also often easily done by hand. Regarding methd extraction the tool would simply need to unwind (turn the lower example into the one above it). This is always a trivial refactoring since the implicit scope of the foo variable lasts from the try block to the end of the method. Even if you have multiple resources:</div><div dir="auto"><br></div><div dir="auto">void foo() {</div><div dir="auto"><span style="white-space:pre"> </span>try (var foo = new Foo());</div><div dir="auto"><span style="white-space:pre"> </span>try (var foo2 = new Foo());</div><div dir="auto"><span style="white-space:pre"> </span>foo.bar(foo2);</div><div dir="auto">}</div><div dir="auto">It is trivially refactored to:</div><div dir="auto"><br></div><div dir="auto">void foo() {</div><div dir="auto"><span style="white-space:pre"> </span>try (var foo = new Foo()) {</div><div dir="auto"><span style="white-space:pre"> </span>try (var foo2 = new Foo()) {</div><div dir="auto"><span style="white-space:pre"> </span>foo.bar(foo2);</div><div dir="auto"><span style="white-space:pre"> </span>} </div><div dir="auto"><span style="white-space:pre"> </span>} </div><div dir="auto">}</div><div dir="auto"><br></div><div dir="auto">If you look at this simple example alone without any logic like an if statement or a loop the amount of nesting really makes things hard to read. In contrary the version with the scopeless try resource still highlights the special treatment of the object while looking similar to a normal object creation the whole thing really is. </div><div dir="auto">The implementation effort and risk of the feature is low while the amount of clarity it adds is high. </div><div dir="auto">There is also a data that shows the impact of the feature since it already exists in c# which is synthatically nearly equivalent to java.</div><div dir="auto">I also don't think it makes the language harder to learn or to understand. For people who already know the try with resources feature only need to "learn" that you can now use try resource with a method level scope. If you are new to try with resources you learn that you can automatically manage closable resources either at method level or with its own confined scope.</div><div dir="auto"><br></div><div dir="auto">The c# reference site of the feature:</div><div dir="auto"><a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-statement">https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-statement</a><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 28, 2022, 18:16 Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Dec 28, 2022, at 12:06 PM, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer">brian.goetz@oracle.com</a>> wrote:<br>
> <br>
>> I think there where many valid points against it mentioned. But I disagree with your scope thesis. The "open try resource" is not meant to be used like this:<br>
>> void foo() {<br>
>> ..<br>
>> {<br>
>> try (..);<br>
>> ..<br>
>> } <br>
>> .. <br>
>> }<br>
> <br>
> Which is what I understand you mean by opening a scope just for the scope itself. It is meant primarily for use cases where your resource live the lifetime of the function, which is pretty common in well refractored code.<br>
<br>
There was some sort of editing error here, the above sentence was part of Red’s mail, not my reply. My reply begins here: <br>
<br>
> What you are advocating for is something like Golang’s `defer` statement, which queues up cleanup operations to run at function exit. <br>
> <br>
> But, the `defer` mechanism is a weak bit of language design; it forces developers to align method boundaries with resource management boundaries, even when the two don’t agree. Yes, the two coincide often enough to make it seem harmless and even clever, but such couplings often end up being impediments to refactoring and the source of subtle bugs. (For example, an “extract method” refactor may change the order in which resources are released.). Ultimately, it has many of the same deficiencies as global static state or nonlocal control flow — it interferes with modular reasoning. Adding more of this into the language isn’t necessarily helpful. <br>
> <br>
> <br>
>> Which is exactly what the current existing try resource is. The motivation of feature is to remove redundant nesting.<br>
> <br>
> I think this is the root of the problem. This is not a very strong motivation for introducing a new and different form of scoping into the language. <br>
> <br>
> <br>
<br>
</blockquote></div>