reloc and constexpr

[SebastienBini]

The paper never mentions how reloc and constexpr work together. Namely:

• can reloc be used in a constexpr?
• can the relocation constructor be constexpr?
• can the relocation assign operator be constexpr?
• can a decomposing function be constexpr?

The only thing that gets me slightly worried is the eliding ABI trick. On caller-destroy ABI, we propose to emit two functions (eliding and classic) for the reloc assign operator and decomposing functions.
The classic function is caller-destroy and will call the eliding one which is callee-destroy, using the following trick:

f.classic(T value)
{
  union { T __tmp } = { .__tmp = reloc value /* move or copy construct */ };
  f.eliding(&__tmp);
}

I don't know to what extent the union trick is compliant w/t constexpr, nor if it even matters as this is part of compiler-generated code.

Also, in the case of a trivially relocatable type, reloc x will likely get optimized into a single memcpy call. This paper legalizes this optimization, but I believe we must clearly write it down in the context of constexpr.

Do you foresee any other issues? What's your take on this?

[SebastienBini]

Another point, in:

f.classic(T value)
{
  union { T __tmp } = { .__tmp = reloc value /* move or copy construct */ };
  f.eliding(&__tmp);
}

We may end-up in a situation where the relocation constructor is constexpr, some decomposing function is constexpr, but calling it won't be constexpr because of non-constexpr move or copy ctor.

Consider:

struct T
{
T(T const&) = default;
T(T&&) = default;
constexpr T(T) = default;
constexpr auto get_all(this T reloc);
// [...]
};

constexpr void foo(T val)
{
  auto [x, y] = reloc val; //< under caller-destroy ABI, calls T(T&&) at some point, and hence cannot be constexpr
}

One way around it is that, for the relocation ctor to be constexpr, then the copy and move ctor (if declared) must be constexpr as well.