A modern programming language that makes developers happier.

kotlinlang

Is it possible (or are there plans) to have some sort of Swift-style `deinit` in Kotlin/Native?

Can you please elaborate your use-cases for this kind of feature?

Basically if you're writing a wrapper class for a C API, where you need to call one function to allocate a resource (image data or something) and another function to then deallocate it. Having these be coupled in a `init`/`deinit` setup tends to be cleaner than always having to remember to run `.destroy()` (or whatever) on the soon-to-be-deleted object. With Kotlin/Native being reference-counted similar to Swift (correct me if I'm wrong here), I figured it might be possible to do what Swift did with `deinit`.

(If there is some more idiomatic way of doing it in Kotlin, I'm all ears)

I should maybe clarify that I'm aware of `memScoped`, and that I'm talking about storing the resource as a class member variable in the wrapper class. So this is not about using the resource in a limited scope or anything.

You can pass a reference to `Arena` to the wrapper class that stores the allocated resource. Arena is designed to serve as a drop-in replacement for RAII pattern

in many cases, binding resource lifetime to object lifetime is not such a good idea, so we try to avoid finalizers/deinit as dangerous programming pattern

maybe suspendable function with resource release at certain point of its code could be a sensible alternative if you do not want explicit scoped resource mgmt

<@U3SK5B492> I would agree with you if we were talking about an environment with a "proper" garbage collector, but seeing as how reference counting is immediately and deterministically collected I feel like it would be a very natural relationship to couple the resource with its wrapper. Then again, I suppose Kotlin code should be somewhat compatible with all its environments.

<@U2E974ELT> Any examples of `Arena` to be found somewhere?

Kotlin/Native is not a system with where objects are  "immediately and deterministically collected", as we do employ cycle collector, whose behavior somewhat similar to typical GC (just on smaller graphs). So not sure if this argument is explicitly applicable. Also we may want to add additinal tracing collector in some future releases.

Oh, so `DeferScope`, which is implemented by `AutofreeScope` and `Arena`, does have the method `defer()`, which can be used similarily to Go's `defer`. Do I understand this correctly?
Also, for my needs I added facilities similar to `java.io.Closeable` and `kotlin.io.use`. I would probably add extension method to register objects implementing this interface in `DeferScope`. Any chance something similar would be implemented in the stdlib?

<@U3SK5B492> Interesting. I didn't know about the cycle collector. That does complicate things.

<@U875H9W3U> 

&gt; Oh, so `DeferScope`, which is implemented by `AutofreeScope` and `Arena`, does have the method `defer()`, which can be used similarily to Go’s `defer`. Do I understand this correctly?

Yes. It defers the lambda to be executed on arena disposal or `memScoped` end.

&gt; Also, for my needs I added facilities similar to `java.io.Closeable` and `kotlin.io.use`. I would probably add extension method to register objects implementing this interface in `DeferScope`. Any chance something similar would be implemented in the stdlib?

Resource management in Kotlin/Native is under a (long) discussion now, but we haven’t decided yet what exactly to be added to stdlib.