There are may other names for this construct. For example: using and cleanly. I find loan not to be the best name for this.

SBT io defines https://github.com/sbt/io/blob/1.x/io/src/main/scala/sbt/io/Using.scala

I find that name to be much more descriptive.

We should consider extending the native try to support resources. It would avoid the allocation / indirection of having it in a library. The change could go along with an equivalent update to scala.util.Try to support resources too.

@lrytz adding try-with-resource to the core language would be great. The program transformation in https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.20.3 shouldn't be hard to implement in the compiler.

That said, I never worried about the allocation of the LoanX objects in the code in this PR. The cost of those allocations is tiny compared to dealing with resources (native calls, system calls, file handle allocations, etc).

I would suggest posting on https://contributors.scala-lang.org to call attention to this PR. We may end up merging some form of this, but it needs community discussion. (Posting on Discourse will reach people who don't watch this repo.)

I wasn't sure how you handle Java classes leaking into the Scala library. Is it permissible to use java.lang.AutoCloseable?

The scala library depends on Java classes in many places and ways. The strategy so far has been to cross-compile Scala ports of the Java classes for Scala.is and scala-native.

https://contributors.scala-lang.org/t/adding-try-with-resource-to-scala/1641

What do you think about implementation by type class ?
For example: https://gist.github.com/piyo7/a82da2bcb5ede5a53d6d93354d7cea6f

@ocadaruma Closer-pattern would allow the scala implementation to be independent of AutoCloseable. Ofcourse an implementation of a Closer[AutoCloseable] would be provided and the type bounds should be adjusted accordingly

Heads up: if this is going to make it into 2.13, it will need to be ready to merge by M5 (due Aug 10).

@varming I'm going to close this for inactivity, since we are trying to hard to cut down on the number of open PRs scala/scala. (closing the PR for now doesn't mean anything about its eventual chances of success.)

the action's at #6907 now