I'd like to re-raise `Closeable` as a feature Kotl...

# multiplatform

[kevin.cianfarini]

I'd like to re-raise Closeable as a feature Kotlin developers desire in the common stdlib. Here's an associated YouTrack Issue.

This conversation has been brought up several times, and the argument against Closeable being defined in common was that the stdlib doesn't use it anywhere.

Library maintainers have coped by creating their own implementations of Closeable and use. This is undesirable because:

1. Consumers of these libraries have to rectify multiple different namespaces of what is essentially the same interface.
2. Library maintainers need to recreate closeable for every one of their projects.
Right now, Okio, SQLDelight, and Ktor all have their own implementations of Closeable. I'm sure there's many more libraries which do the same.

I personally feel that coalescing around a single implementation of Closeable is import in the Kotlin ecosystem now that we've shown it to be a common use case in multiplatform code.

[kevin.cianfarini]

Furthermore, libraries are starting to depend on other library implementations of Closeable. For example, Zipline by CashApp leans on okio.Closeable.

https://github.com/cashapp/zipline/blob/c67a4b18f597bdffa9c50351ef04bcd1a48f8f0f/z[…]tecode/src/main/kotlin/app/cash/zipline/bytecode/lineNumbers.kt

[Stylianos Gakis]

apollo-kotlin also seems to have implemented their own implementation of closeable initially. But due to them depending on okio already anyway, this was changed to use okio’s alternative just 9 days ago on an unreleased version of the library as of right now.
Just thought I’d add another example that is also multiplatform 🤗