#[dtor] does not match semantics of #[ctor]

[melvyn2]

Registering a function with atexit does not really match what I would expect from this crate/attribute. I would expect that, like __attribute__((destructor)), the function is called at module unload time, which could occur at a different time than actual program exit.

[mmastrac]

Most likely dtor will be disappearing in a 1.0 release as it's been finicky to get working. I just need some time to get around to doing that major release.

[mmastrac]

FWIW I'd be open to a discussion of the future of the API, but I think it is difficult to get this working cross-platform.

[melvyn2]

for *bsd and linux, link_section = ".fini_array" should work (haven't tested yet), and __DATA,__mod_term_func works for macos. I can't find a corresponding section for windows (though I haven't looked far), but it certainly is possible with DllMain.

[CGMossa]

I was banking on dtor-functionality :(

[mmastrac]

For ctor 1, I'm going to split the dtor functionality out into its own crate, where we can experiment with different design decisions.

I've create a placeholder crate for dtor for now, published from this repo: https://crates.io/crates/dtor

[CGMossa]

Thanks! Somehow, I encountered an inconsistency that made me drop the whole idea (that includes using dtor), but I still think there is room for dtor as a whole.