Incomplete fix for CWG 3049

[phalpern]

The following code fails:

struct C trivially_relocatable_if_eligible {
  ~C() = delete;
};

struct D : C
{
};

static_assert(std::is_trivially_relocatable_v<C>);
static_assert(std::is_trivially_relocatable_v<D>);

Although this is correct according to literal reading of the proposed resolution to CWG 3049, in private discussions, it was decided that a deleted destructor should not prevent class that is annotated with trivially_relocatable_if_eligible from being TR. In effect, the last bullet of 11.2/p3, "-- has a deleted destructor," should be removed from the CD.

[iains]

@NinaRanns - let's assume we can defer dealing with this until the current reviews are done.

[NinaRanns]

@phalpern this was done intentionally. My understanding was that only the implicitly deleted destructor should not prevent trivial relocatibility (which made the original suggestion to just remove the bullet wrong as it does indeed allow for this case with an explicitly deleted destructor).

Can you please confirm that the following behaviour is desired :

struct C1 trivially_relocatable_if_eligible {
  ~C1() = delete;
};

struct C2 {
  ~C2() = delete;
};

static_assert(std::is_trivially_relocatable_v<C1>);
static_assert(!std::is_trivially_relocatable_v<C2>);

[phalpern]

Correct, the first is explicitly TR because of the keyword, which ignores the explicitly deleted destructor. The second is not TR because an explicitly deleted destructor (or move constructor or move assignment operator) prevents implicit TR.

[NinaRanns]

@phalpern ack, thank you.
What is the the deadline/priority for this ? It's a minor change (probably a line of code, and a couple of lines of regression tests) and can probably be done when one needs to take a break from the time consuming tasks. :)

[phalpern]

At this point, I would put it at a low priority level, as I'm 99% certain that it will have no effect on being paid. It will have a small effect on the successor proposal to P2786, which will have the desired semantics in the wording and would therefore benefit a little from existing implementations having the correct semantics, but even then, it is not worth pushing more pressing work out of the way. The equivalent fix in Clang was one line of code; I'm hoping this one is equally simple, but, of course finding the right line and doing all of the testing is a non-trivial amount of work.