Fix issue 17440: do not call .destroy on class instances in Nullable.nullify

[quickfur]

This is a reboot of #6038 with a simpler fix that doesn't require extensive, backward-incompatible changes to Nullable.

It does not take care of the problem of Nullable!Class introducing a second, inequivalent null state to a class reference.

[dlang-bot]

Thanks for your pull request, @quickfur!

Bugzilla references

Auto-close	Bugzilla	Description
✓	17440	Nullable.nullify() resets referenced object

[n8sh]

Should this be if (is(T == class) || is(T == interface)) ?

[quickfur]

You're right, I missed that. Fixed.

[MetaLang]

I don't think we can do this. There may be code bases relying on the fact that nullify will call destroy on objects.

[quickfur]

@MetaLang It seems unlikely, and in any case, the GC will collect the object eventually, if indeed there are no more references to it (if there's still another reference to it, then it's a bug to call the dtor, which is the complaint in issue 17440).

[wilzbach]

I think we can do this - the spec never guaranteed deterministic calling of the the dtor for classes. OTOH object.destroy calls rt_finalize immediately, but that's a bug of nullify - it was never documented that it does so.
We should probably add a changelog entry so that it's visible to people.

[quickfur]

Added changelog.

[schveiguy]

but that's a bug of nullify

Agree, I think most people expect it to work just like assigning a pointer or class ref to null. If they want deterministic destruction, they can destroy the object specifically, or use a scoped class.

[MetaLang]

I don't agree but this is low on the list of things I care about.