C.128, why not use override virutal base class destructor?

[franzhollerer]

From rule C.128

If a base class destructor is declared virtual, one should avoid declaring derived class destructors virtual or override. Some code base and tools might insist on override for destructors, but that is not the recommendation of these guidelines.

Can please someone help me to figure out why a destructor in a derived calls should not be declared override if the destructor is declared virtual in the base class.

Actually, this looks to me to be in contrast to the example in rule C.128. Maybe it is worth to address it in a separate rule.

[AndrewPardoe]

Per our editor's discussion, note that the meaning of override differs with destructors.

[robert-andrzejuk]

C.128: Should destructors be marked "override"?
#721

[MikeGitb]

Well, I personally still disagree: the meaning of override is exactly the same for destructors as for normal members (it ensures that the function in the base class was declared virtual) it is just the destructor that - virtual or not - behaves differently than a normal function as it automatically also calls the base class destructor (but the same can be done in normal virtual member functions as well).
Out of the three bad examples, destructors are immune against the last (you can't make a spelling mistake or use the wrong parameters) but the first one (forgetting the virtual key word in the base class) and the second (not explicitly indicating that you expect it to be virtual) are mistakes you can still make and that would be caught by using override. So imho, this is an unnecessary exception.

But more importantly I think c.128 misses an explanation as to why the guidelines recommend against using override on destructors - maybe a link to #721 would be in order.
Or it could be worded differently, e.g. like:

"Adding override on destructors is not necessary as you can't misspell them."

[bdeeming]

I agree with @MikeGitb. It is very easy for someone to inherit from a class and to (mistakenly) assume that the base has a virtual destructor, or the reverse, someone performs some maintenance on the base class and in the process innocently removes the virtual from it's destructor, or even just (if it's a new class hierarchy) forgets to put the virtual on the base (we're just human after all).
I'm not really seeing what the downside is to declaring "I'm counting on the base class to have a virtual destructor, warn me if that's not the case", apart from having an extra keyword to type and read (worth it in my opinion).

[sandym]

+1 for having override on destructors, this is exactly the kind of bugs we've seen in the pass and now catch by using override.

struct Base { virtual ~Base(){} };

struct SubClass : Base
{ ~SubClass() { std::cout << "It works!\n"; } };

int main()
{
	std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
}

Someone remove the virtual in the base class as part of a clean up and things stop working.

Not sure I understand why it's considered good to protect ourselves against this kind of error for methods but not for the destructor.