Destructor

[khalyomede]

This proposal is for adding destructors as part of classes special methods, in the fashion of the new() method. It can allow to perform housekeeping tasks before an object instance is out of his scope (freed by the garbage collector of the target programming language). Learn more in the file proposals/0013-destructor.md.

[Aurel300]

Destructors in a GC environment are not a good design. The destructor may be called at some unpredictable time (which may happen during the sweep phase of a GC that shouldn't execute user code), or it might never be called (depending on the granularity of collection an object with a destructor may end up in the same block as a long-living object).

Your table shows the various Haxe targets and that ~half of them do not support this, yet you do not address this problem. We cannot synthesise calls to destructors on targets that do not support them, not without emulating our own GC system inside the platform (at a heavy performance penalty).

I don't think this should happen.

---

• Java finalize is deprecated since Java 9.
• For the record, HashLink supports destructors at the moment, and IIRC they are allocated in a separate kind of block to make sure the destructor is always called.

[khalyomede]

Your table shows the various Haxe targets and that ~half of them do not support this, yet you do not address this problem.

As a side note, this proposal do not try to deal with adding destructor as a native feature. It is just enabling the compiler to convert code for platforms that support destructors.

I will add this precision in my document.

[Simn]

lean-reject: confusing proposal

[Simn]

We have rejected the proposal in the haxe-evolution meeting today.

It's not clear what this proposal aims to achieve. We certainly don't want destructors as a proper feature, and anything other than that would have to be designed properly.

[TheDrawingCoder-Gamer]

Revisiting this it may be useful for say C++ externs and languages that don't have garbage collectors for native classes thru externs.

[haxiomic]

@TheDrawingCoder-Gamer the C++ target already has support for this, the terminology they use is “finalizer” https://github.com/HaxeFoundation/hxcpp/blob/master/test/haxe/native/TestFinalizer.hx

we could perhaps unify the approach between hl and hxcpp with metadata but given it’s an infrequently used feature I’m not sure the demand is there for that

making it a top level language feature could create confusion given it’s not supported everywhere

[back2dos]

It should be easy enough to write a build macro that implements this on all supported platforms (and warns on others, I suppose).

If you then still feel that it should be a language feature, you can resubmit a proposal - this time with a reference implementation that covers all details of the final design.