Thread
#multiplatform
    kevin.cianfarini

    kevin.cianfarini

    4 months ago
    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.
    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

    Stylianos Gakis

    3 months ago
    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 🤗