[feature]: Change chained Scope release order from FIFO to LIFO.

[megri]

Problem Statement

Chains of Scope.acquire are released in the order they are acquired, so the first acquired resource will be released first. This feels unintuitive and goes against most conventions I've found elsewhere; Java's try-with-resources for instance is explicitly documented to release resources in reverse order of acquisition. Having the current behaviour can lead to nasty bugs, but if the design is intentional I think it should at least be documented.

Proposed Solution

Change release order from FIFO to LIFO.

Alternative Solutions

No response

Current Workaround

You can work around the limitation by explicitly wrapping nested scopes in Scope.run. So from my understanding something like

for
    in <- Scope.acquire(FileInputStream("foo.zip"))
    gzip <- Scope.acquire(GZIPInputStream(in))
    reader <- Scope.acquire(InputStreamReader(gzip, "UTF-8"))
yield process(reader)
…

could be rewritten to work as indended as

for
    in <- Scope.acquire(FileInputStream("foo.zip"))
    result1 <- Scope.run(
        for
            gzip <- Scope.acquire(GZIPInputStream(in))
            result2 <- Scope.run(
                for
                    reader <- Scope.acquire(InputStreamReader(gzip, "UTF-8"))
                yield
                    process(reader)
            )
        yield result2
    )
yield result1

but it's not pretty.

Additional Context

No response

[megri]

Well turns out it's pretty easy to do this by changing Async.foreachDiscard(tasks, parallelism) to Async.foreachDiscard(tasks.reverse, parallelism) here:

kyo/kyo-core/shared/src/main/scala/kyo/Scope.scala

Line 188 in 9f2f957

Async.foreachDiscard(tasks, parallelism) { task =>

However, once I started looking more at this I realised that this is philosophically incompatible with the asynchronous nature of Scope.run. I'm interested in something that can manage resources in a predictable manner, but as Scope.run(n > 1) would be non-deterministic in the order it closes resources, perhaps this is the wrong abstraction? I'm also a confused by this API, as the only way I can protect myself against someone calling code I've written with the wrong parallelism, is to wrap my own resources in a defensive Scope.run, but that would defeat the purpose of being able to do this from the outside.

What am I missing here?

[hearnadam]

@megri can you explain further by what you mean when you say:

I realised that this is philosophically incompatible with the asynchronous nature of Scope.run

I don't think this is an impossible ask

[megri]

@megri can you explain further by what you mean when you say:

I realised that this is philosophically incompatible with the asynchronous nature of Scope.run

I don't think this is an impossible ask

What I mean is the ask—releasing resources serially in LIFO order—is directly add odds with the proposition of Scope.run(n) where n > 1. In other words, even if we were to reverse the order resources are released, a caller might wrap a piece of code in Scope.run(3) and inadvertently break the required order of the wrapped code.