On using `Using`

[julienrf]

@NthPortal has recently put a nice effort (scala/scala#6907 and scala/scala#7468) to provide a resource safety system to the scala-library.

I think this is a great step forward but I do have some concerns about including it in the scala-library in its current form:

• It only works for synchronous execution paths,
• It introduces a Releasable typeclass with only one instance, java.lang.AutoCloseable (thus, it looks like a premature abstraction, unless we have other possible instances in mind?),
• It hasn’t been tested a lot in the wild.

So, although I completely agree that supporting AutoCloseable is useful, I think we should wait for the proposed design to have been proven successful before including it in the scala-library. I would suggest instead incubating it as a separate library (for instance scala-autocloseable).

Last but not least, I think it would be extremely valuable to provide a resource safety system in the scala-library but it should have a larger applicability: it should also support asynchronous execution paths. For the record, this is something that libraries like Monix or scalaz-zio do support. When Future was introduced to the standard library 6 years ago that was a huge step forward, but we’ve seen room for improvement over time: it’s too easy to leak CPU resources by mistake (e.g. Future.firstCompletedOf(aLongComputation() :: anotherLongComputation() :: Nil) continues running the longest computation even after the first one has completed). In my opinion, this is an important problem that we should address.

I’m not sure how much time we have before 2.13.0-RC1 but I think we should allocate some research work to properly support asynchronous execution paths before commiting to a design. If it’s too late, then I would suggest moving the current Using abstraction to a separate library so that we can provide a nice, solid and polyvalent resource safety system in Scala 2.14.

[Ichoran]

Try also only works for synchronous execution paths. Same deal with mutable pretty-much-everything. Not to mention (careless) manual closing of file resources. I'm not sure why this is an especially acute problem here.

(Agreed that there hasn't been much testing, though.)

[ritschwumm]

@julienrf there are a few classes in the JDK which are closeable, but do not implement AutoCloseable. https://docs.oracle.com/javase/7/docs/api/javax/naming/Context.html#close() for example.

[NthPortal]

A few thoughts on Releasable:

• Not having a typeclass and using AutoCloseable instead limits usability - it can't be used for APIs you don't control that don't extend AutoCloseable, and it can't be used by people who don't want to use Java APIs when designing their resource types (or anyone who uses their APIs).
• Because it is a SAM type, you can pass a bespoke function literal instead of using an implicit.
• The reason the only default instance is for AutoCloseable is because I couldn't think of any other types in the Java or Scala stdlibs for which there should be instances. I'm 100% open to suggestions.
• Another obvious choice would be to have implicit instances for the structural types { def close(): Unit } and/or { def release(): Unit }, but we generally try to avoid structural types for a variety of reasons (not limited to performance, which is unlikely to be a huge concern here).
• I'm happy to add instances for the class @ritschwumm suggested, as well as any others, though that may quickly get a bit ridiculous (as well as unnecessarily adding requirements for other platforms to implement?)

[ritschwumm]

@NthPortal while i do agree a typeclass is the most sensible way to go here, it wouldn't make much sense to add instances for the ones i found in the JDK (Lock, TimerTask, DirContext and NamingEnumeration). none of these is, should be or can be supported by scala-js in a meaningful way.

[NthPortal]

There is actually some argument for supporting Lock - guaranteed releasing of a lock is important (the only reason it would be useful for Lock is because it's poorly designed and doesn't have a method that performs an operation while having the lock acquired). However, I think that requires some sort of acquire typeclass (or to rename Releasable (Manageable?) and add such a method).

Edit: you could also add an acquire method that defaults to a no-op

[NthPortal]

I have mixed feelings about this. On the one hand, I completely agree that Using.Manager is untested and that it could be valuable for ending up with the best API to incubate it in a separate library so there is more time to see what's good about it and what isn't.

On the other hand, my original intention was to add a very simple resource management method similar to Java's try-with-resources (which is now Using.resource). Because the logic is non-trivial (as seen in scala/bug#11003), I thought it should be provided. However, the scope steadily crept until we now have scala/scala#7468. I was originally very reluctant to use a loan/scope-based approach, because it seemed like a significantly larger scope than originally intended (though it ended up being simpler than I had initially expected). I think that core simple method is important to have in 2.13, even though there are a lot of use cases it doesn't cover.

[NthPortal]

If scala/scala#7528 gets accepted, would it make sense to mark Using as @ApiMayChange? Otherwise, I think I agree that it would be better to put it into its own module until it becomes better tested and more complete.

[dwijnand]

Yeah, maybe it should!

[He-Pin]

Netty is using the reference counting:https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/ReferenceCounted.java

[SethTisue]

Having it synchronous-only doesn't bother me. If a more ambitious proposal that covers asynchronous calls eventually materializes, we could consider deprecating the synchronous-only one at that time.

As for incubating this first in an external library before bringing it into stdlib, I'm somewhat torn. For a sufficiently large/complex stdlib addition, yes, it ought to be incubated elsewhere first. But my intuition is that this addition is not "sufficiently large", and that Using as an external library would probably end up being mostly ignored and not getting much testing, since the inconvenience of adding the dependency (and having to even know that it exists) would tend to outweigh the convenience Using provides. (Especially since the problem Using solves is often a problem that people don't even necessarily realize that their code has...!)

Also, Using has been evolving for a while now here in scala/scala, it's not just parachuting in from nowhere right before a release.

So overall, I lean towards allowing the addition.

[SethTisue]

discussion at https://gitter.im/scala/contributors?at=5c350c928b6399655e2ac03b

[NthPortal]

are we considering this closed, leaving it with the status quo?

[SethTisue]

@adriaanm opinion? I'm inclined to just close this