Here are the problems with the Closeable.use extension method:
* Doesn't work with Autocloseable (easy to fix, but seriously? this is a can of worms, but Kotlin's stdlib needs to be 100% compatible with whatever the latest JDK is. In fact, you probably need to version the stdlib (and, perhaps, Kotlin itself) together with the JDK.)
* Awkward to handle multiple resources
* Often needs a try block anyway to catch the exceptions coming from close(), the constructor, or the body
* Uses ad-hoc syntax

What do I mean by ad-hoc syntax?

It always has to be used like:

Files.newOutputStream(path).use {
it.write(‘a’)
}

It shouldn’t be used like:

val ostream = Files.newOutputStream(path)
…
ostream.use {
// by it value you can get your OutputStreamWriter
it.write(‘a’)
}
… Oops, we’ve closed our ostream but the variable is still in scope, waiting to throw an IOException

Absolutely agree. But we want to avoid language construct just for this as much as possible and we have an idea of the solution, it's not implemented in stdlib yet, but you can try it using code like this:

Wow, that's a great idea that even beats most built in constructs that adresses this kind of issues. Your idea even allows for conditional creation of closable resources which is much harder with most common using/try-with-resources constructs, e.g.:

But to provide some constructive criticism:
* This code is not 100% safe. In particular, adding to a list is not safe from exceptions (OutOfMemoryError), so you’ll get into a situation where you lose track of a resource and don’t close it. If you use a fixed-length array, you’ll run out of room.
* You’ll still often need a try/catch block
* This syntax is still a little ad-hoc (much better, yes, but you still have to remember to add “.autoClose()”)

Why do you say “we want to avoid language construct just for this as much as possible”?

The point of language constructs (at least the really good language constructs!) is to cement a “pattern” from being some ad-hoc boilerplate code into a syntax that jumps out at the user and tells them to “use it correctly!” Gotos became if/for/while, structs with function pointers became objects, continuations became exceptions and async/await, etc, etc. Yet, there’s not many code patterns more fitting of a language construct than correct resource lifetime management. Java and C# both fucked up in not even shipping Closeable/IDisposable in versions 1. (The hubris!) Then they fucked up in how they implemented Closeable/IDisposable. (Java had to release another class, AutoCloseable, and C# requires developers to read giant articles like http://www.codeproject.com/Articles/15360/Implementing-IDisposable-and-the-Dispose-Pattern-P to even write a class that implements IDisposeable. Microsoft actually “fixed” it again when it created managed Visual C++ by generating the boilerplate automatically https://msdn.microsoft.com/en-us/library/ms177197%28v=vs.100%29.aspx , which is one of the very few advantages of Visual C++ as a managed language. Yes, the irony.)

So, I would advise you to consider this subject seriously, and support the user with solid language constructs to deal with resource lifetime management. Even if we just make your “using” function into a keyword, we’re cementing it with syntax highlighting, and prohibing people overriding, overloading, or otherwise messing with the semantics. I’m sure there’s plenty of other things that could be tidied up along the way. I’m afraid I don’t have a ready list, but a pain point that comes to mind is implementing close for a class that has multiple autocloseable fields (which it owns):

@Override public void close() throws Exception // Really icky. But we can’t just throw IOException, since the type of ‘t’ is unrestricted. { Throwable t = null; try { if (a != null) a.close() } catch (Throwable t2) { if (t==null) t = t2; else t.addSuppressed (t2); } // We want to catch Errors as well, since there’s no reason to not try to dispose of our resources if there’s been an Error (the Error may be caught and the program may continue). try { if (b != null) b.close() } catch (Throwable t2) { if (t==null) t = t2; else t.addSuppressed (t2); } // A trickier case is the InterruptedException, but I think we should catch those as well (since interrupting a thread is not guaranteed to work) for (Closeable cc : c) try { if (c != null) c.close() } catch (Throwable t2) { if (t==null) t = t2; else t.addSuppressed (t2); } // Oh, geez, do we need to put for inside a try block as well?? if (t != null) throw t; // I wonder, if this exception also gets suppressed, will the suppressed exceptions in this exception still get printed? Or will we need to “unroll” them? }}

Maybe we can have ‘autoclosed var’ and ‘autoclosed val’ which will close the object whenever it leaves the scope? No “using” keyword required. For fields/properties, ‘autoclosed’ generates a ‘close’ method. This should be enough for most AutoCloseable classes (which just need to close their fields). For classes with more complex close logic, the user can specify one or more “destructors” which will be called from the generated close method using the appropriate try { } catch { suppress } logic. Additional features would be correct chaining of ‘close’ methods in the inheritance heirarchy, calling any finalizer logic from ‘close’ (and making any class which has a finalizer AutoCloseable), checking if the object has been closed on every method call (or at least maintain an isClosed property which can be manually checked), not running the destructors/finalizers more than once, etc. Maybe even a ‘close’ keyword for use inside a destructor (to catch the exceptions, as above). Basically, take a look at what Visual C++ does on the CLR.

The article I linked to previously (http://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About) highlights other big-picture issues with the dispose pattern, such as having to pre-determine object ownership and how it really fucks with the Liskov Substitution Principle in that if you have an object which implements interface Foo which does not derive from AutoCloseable, you don’t actually know whether the object itself implements AutoCloseable and needs to be closed (!!!). However, the proposed solution, reference counting, seems too radical for Kotlin. The article also brings up a laundry list of specific issues in the CLR, but I haven’t parsed it to figure out which apply to the JVM. (Generally, the JVM has much fewer such issues.)

Btw, you know what would be a quick fix to point #2 and a great addition to the language in general? Allowing catch/finally blocks to follow any block, permitting code like:

Yes, it's nice. The use of an extension function may cause unexpected issues though. For instance if you refactor some code out of the using block into a separate method, suddenly the autoClose method disappears, doesn't it? If autoClose was always present and would push the resource onto a Cocoa style autorelease pool, it'd fix that issue, but at the cost of less type safety.

It doesn't disappear, if extracted function will have ResourceHolder as a reciever, which indicates that function requires external resource management. It actually allows for some nice composition techniques, and if ResourceHolder is interface, even passing resource cleaning strategy, etc.

It appears that is use, but based on AutoCloseable instead of Closeable. Many things that implement AutoCloseable also implement Closeable, but some do not. However the issue is that AutoCloseable is not available in Java 6, but Closeable is and Kotlin targets only Java 6.

It occurs to me that there could be a use for a more general purpose use:

It occurs to me that there could be a use for a more general purpose use:

The general purpose function with an onExit is very useful. That does not mean that an autoclose function would not be very useful as well (extending on your base, in this case with Closeable, but overloads to other types would be acceptable, for example to the jdbc types that for some reason don’t implement closeable):

What would be really cool is if the following code would actually compile (maybe using some sort of template like SFINAE approach), note that this fails if T does not have a close method, but that the method could be resolved at compile time:

For those who do not want to implement the utility themselves and while Kotlin developers think whether to add it or not to stdlib, you may use a basic implementation (as described above) already available in Maven Central

I completely agree with the point that new language construct should be avoided. But the lack of the try-with-resources (a feature that both Java and C# have) is a step backwards. It’s a fundamental concept which is a must-have in language without destructors. It deserves a proper syntax and a language construct which would make it fool-proof, as safe as possible and autocomplete-, fixit- and diagnostcs- friendly. It’s 10 times as important as any other candidate for a language construct.

This + overload is the exactly reason why many people don’t like operator overloading. + is about numbers, not about resource management. I would suggest just to use some function name. Otherwise great idea, I didn’t know that you could “overload” catch like that. I made similar library for myself. Honestly Jetbrains should just add something like that to standard library along with use.

I agree about + overloading. Better to use something like use or even resource to avoid name clashes. As for the whole discussion, I think it is a great idea to move a lot of features from language into library, it simplifies understanding of the code and gives a lot of additional freedom.

I also think that try-with-resources should be in library functions.
On the other hand, I think that a seperate project “Kotlin-EE” like “Java-EE” should be maintained, where things like this should be standardized.
But maybe it’s to early for that, yet?