On Sunday, 21 April 2024 at 19:28:11 UTC, Steven Schveighoffer wrote:

Amazing.

I'm biased towards deleting code, so...

On Sunday, 21 April 2024 at 19:28:11 UTC, Steven Schveighoffer wrote:

If a user writes a destructor, and that destructor is never called sometime after a new, then yes, I think "Why isn't the GC working?" is a valid and fair question for that user to ask. I don't see any way in which that expectation should be considered unreasonable. If the answer is "No you don't understand, the GC internals such that this- that- and the other thing- means you can't have guaranteed destructors", then I'd say you've failed to make the sale and the customer is right to walk away.

As an aside, I would observe if one wants them to stay, one probably shouldn't be in the habit of calling them "the unwashed masses", either.

On Tuesday, 23 April 2024 at 07:38:25 UTC, cc wrote:

I always thought destructors run on GC-allocated objects some time between the last reference to the object disappears and the application exits. If you want some cleanup to run promptly after last reference is gone, a destructor is not the right tool. (You need reference counting or something like that, if a unique owner cannot be established.) The destructor not running at all is really surprising if you allocated the object normally.

On Tuesday, 23 April 2024 at 07:38:25 UTC, cc wrote:

This is a property of ALL GCs, even Java does not guarantee finalizers will run.

I agree it's reasonable to ask such a question, and we get them all the time. The thing is, even if we do something as drastic as not scan live stacks for roots, you still may end up not seeing the destructor run. This is a fact of life for GC, and it's better to learn that fact than to try and fight it.

Typically, this is not a question of "why isn't my stuff getting cleaned up", it's more that they are trying to poke the GC to see if it's working (usually a small test program). I've done it too...

And ironically, collecting extra "live" blocks actually hides from people the true nature of GC and finalization. In truth, you should never rely on the GC to clean up anything but memory. Resources other than memory should be cleaned up synchronously when you are done with them, as they are far more rare than memory.

Sorry, it's just my dry humor. It was more intended as (good-natured) satire on Walter (I imagine him scoffing at the insolent nothings that complain about his perfect language) than an actual slight on the people asking.

-Steve

On Tuesday, 23 April 2024 at 12:18:34 UTC, Quirin Schroll wrote:

It normally happens but is not guaranteed, especially with a conservative collector (one which does not know whether a word of memory is a pointer or not).

-Steve

On Tuesday, 23 April 2024 at 14:24:14 UTC, Steven Schveighoffer wrote:

That's why it is recommended to use try-with-resorces statement to manage non-memory resources such as http connections opened files and etc. in java

For D code it would make sense to have such resources, reference counted.