Indeed, this why there is a need to distinguish between valid scenarios and abuses.

>In a destructor, a partially destructed object may conceivably be re-destroyed.

I strongly disagree there: yes, some object reference can be FreeAndNil’ed multiple times during as part of their design during an owner context lifetime, but that should never happen during a destruction chain. If it does happen, then you’re facing either redundant or spaghetti code, with poor maintainability and higher risk of divergence.

Separating FreeAndNil and FreeAndInvalidate allows to make that distinction between a normal nil reference situation, and an abnormal one.

> Any objects Free’d during execution of the previous partial destructor chain obviously should not be re-freed.

Indeed, but FreeAndNil is not a protection against that: a field will stay nil ONLY if the memory of the context that hosted the reference isn’t reallocated during the destruction chain, something you just can’t guarantee in a destruction chain (especially in multi-threading situations).
This can (and does) lead to code initially “working” in single-threaded situations, that very randomly goes bonkers in multi-threading situations, or after some allocations get mixed in the destruction chain …like allocations arising from debug code added to diagnose the very random bonkers situations just mentioned!

>More realistically there may be “instantiate on demand” references

In that case use FreeAndNil, that’s what it’s for.
For all the other situations (IME the vast majority of cases), there is no need to abuse FreeAndNil, and one should never forget that FreeAndNil/FreeAndInvalidate are nothing more than optimistic defensive strategies, so fix the design, that saves pains down the road.

I would say: “thus leaving an invalid reference that CAN however never be used anymore.” This does not require FreeAndNil, nor does it need anything like FreeAndInvalidate, IMO.

FreeAndNIL() isn’t always about NIL’ing a reference to an object and hoping that an AV will result if that reference is subsequently re-used. NIL’ing the reference can also be valid in it’s own right.

In a destructor, a partially destructed object may conceivably be re-destroyed. Any objects Free’d during execution of the previous partial destructor chain obviously should not be re-freed.

Yes, a partially destroyed object indicates a potential problem in that class or it’s design, but still may be a valid/unavoidable scenario.

More realistically there may be “instantiate on demand” references that are periodically disposed of, but not replaced until needed. NIL’ing those references when disposed creates a testable condition to trigger the creation of a new object if subsequently referenced.

This sort of thinking process coming out of Embarcadero is illuminating. It seems to indicate to me that the guys “running the show” behind Delphi these days are less concerned about practical work and getting a job of work done, and more interested in abstract language and coding theory and practises.

Sad.

It’s all about moving the issue from a gray area, to one of black and white.

How to fix that?