I was surprised the new `Resource<A>.allocat...

# arrow-contributors

[phldavies]

I was surprised the new Resource<A>.allocated() extension returns Pair<suspend () -> A, suspend(A, ExitCase) -> Unit> rather than Pair<A, suspend (ExitCase) -> Unit> . Much like in cats.effect.Resource I would expect allocated to actually allocate/acquire the resource (and provide the release).

[simon.vergauwen]

That is actually a good point. I didn't spot this on the PR... 😕

The signature suspend fun allocated(): Pair<supend () -> A, ... doesn't actually make sense to have suspend there twice.

[simon.vergauwen]

The implementation I've used experimentally to build support for Kotest, and other utilities which I referenced in the PR actually has the signature you mention.

https://github.com/kotest/kotest-extensions-arrow/pull/189/files#diff-d8900c94975d0caa6b4aae270e0fd47cfc7f1b61b3f1f4216c228af835957ae1R15

[phldavies]

Also I found the fun ExitCase(Throwable) in the companion a little confusing - fun forThrowable or operator fun invoke would make more sense imo.

[simon.vergauwen]

What would be semantically different between operator fun invoke vs fun ExitCase?

operator fun invoke has horrible IDEA support, and many people including myself are moving away from that pattern.

[simon.vergauwen]

The Kotlin Std takes the same approach in many cases such as Random.kt and Duration.kt.

[simon.vergauwen]

We can rectify the API easily though since the API you mention can easily be derived from the PR added in the PR.

[simon.vergauwen]

This API should only be used in low-level interop code anyways.

[phldavies]

semantically they’re the same, but I just found the import arrow.fx.coroutines.ExitCase.Companion.ExitCase a little weird - might be I’m too used to the invoke approach though 😉

[simon.vergauwen]

I've had some issues with IDEA never automatically suggesting an invoke import or syntax when typing, and apparently in Android Studio it's much worse. Whilst this doesn't suffer from it. Originally I also found it strange but I got used to it from import kotlin.time.Duration.Companion.milliseconds

[simon.vergauwen]

Thanks for the feedback, we should flatten the suspend in that signature for the next versions. I already started rolling out the 1.1.3 release so it's a day late 😅

Luckily we're now in a fast path of faster iterations, and preparing the APIs for 2.0.0 next year 🥳 So all, and any feedback is always much appreciated!

[phldavies]

Yeah I saw 1.1.3 was on it’s way 🙂. Just introduced this locally to keep me going:

suspend fun <A> Resource<A>.allocate(): Pair<A, suspend (ExitCase) -> Unit> =
    allocated().let { (acquire, release) ->
        val acquired = acquire()
        acquired to { release(acquired, it) }
    }

[simon.vergauwen]

Improved this for Arrow 2.0, https://github.com/arrow-kt/arrow/pull/2835/commits/e497ffb3fbac50f2854f34ce29414c28deb8f1dd#diff-e0d353d49ae01ce142dcb[…]1c67cf7411c5825b7edc8cL480

Not sure how I can best back-port this fix to 1.1.x 🤔

I don't want to break the binary, and am thinking that a small API change here will be non-harmful since this API is marked Delicate and only released in last patch version.

[phldavies]

I think given the delicate annotation and it's short lifespan so far, a breaking change isn't too problematic - it's likely to have a very small blast radius. Even a deprecation cycle may be overkill?

[simon.vergauwen]

We can do it without breaking the binary using DeprecationLevel.HIDDEN and then we can do a small API breaking change (Kotlin) only.

[simon.vergauwen]

Damn, I thought this was valid in Kotlin. Appears I was mistaken 😕

[phldavies]

Wouldn't allocate be a better name and avoid the clash?

[simon.vergauwen]

That is actually a great recommendation! 👍

[simon.vergauwen]

I didn't think of that

[simon.vergauwen]

Thanks for all your feedback on Arrow so far @phldavies 🙏 It's been really great getting help and feedback to improve Arrow for 2.x.x 🙌