avoid error 'placement new would change type of storage'

[cppljevans]

With the following code:

template < unsigned I >
struct type {
  constexpr type() {}
};

#include <cstddef>   //std::byte
#include <algorithm> //for std::max

template < typename... T >
union uninitialized_T0
/**<@brief
 *  A buffer for stoarge of a 
 *  variant of types T...
 */
{
  constexpr uninitialized_T0() noexcept {}
  uninitialized_T0(const uninitialized_T0&)            = delete;
  uninitialized_T0& operator=(const uninitialized_T0&) = delete;
  constexpr ~uninitialized_T0() noexcept {}

  static constexpr size_t Size = std::max({sizeof(T)...});

  alignas(T...) std::byte buffer[Size]{}

  /**<@brief
   *   Storage for any of T... with proper alignment for all.
   */
  ;
  constexpr void* voidify() { return buffer; }
//#define EXPLICIT_TYPE0
#ifdef EXPLICIT_TYPE0
  type<0> t0
      /**<@brief
       *  The only reason for this is to show the
       *  absurdity, in one sense, of the error when
       *  defined(USE_BUFFER) && defined(USE_CONSTEXPR). 
       *
       *  The error is not absurd in another sense because
       *  it conforms to the <A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2747r2.html">standard</A>:
       *  saying(at "(5.14)"):
       *    "unless P points to an object whose type is similar to T;"
       *  and std::byte[Size] is NOT similar to type<0>.
       *
       *  OTOH, it is absurd because the purpose of this union is to provide
       *  an uninitialized buffer in which to placement new a type, T, whose 
       *  "alignment and size requirements" are "compatible"
       *  with that of the buffer's.
       *
       *  Note, "alignment and size requirements" means alignas(T) and sizeof(T). 
       *
       *  The constraint, "similar to" should be irrelevant, in this case.
       */
      ;
#endif //EXPLICIT_TYPE0
};

#include <new>

template < typename... T >
struct variant {
private:
  uninitialized_T0< T... > storage;

public:
  constexpr variant() {
    new
#ifdef EXPLICIT_TYPE0
        (&storage.t0
    //with clang++20, WHEN defined(USE_CONSTEXPR),
    //this compiles without error.
#else
        (storage.voidify()
    //with clang++20, WHEN defined(USE_CONSTEXPR),
    //this causes error:
    //  error: constexpr variable 'v' must be initialized by a constant expression
    //  note: placement new would change type of storage from 'std::byte' to 'type<0>'
#endif //EXPLICIT_TYPE0
         ) type<0>;
  }
};

int main() {
  variant<type<0>, type<1>, type<2>>
#define USE_CONSTEXPR
#ifdef USE_CONSTEXPR
      constexpr
#endif //USE_CONSTEXPR
      v;
  return 0;
}

When:

defined(USE_CONSTEXPR) and !defined(EXPLICIT_T0)

as explained in the comments, clang++-20 -std=c++26 produces the error shown in the comments.

However, when:

defined(USE_CONSTEXPR) and defined(EXPLICIT_T0)

No error is produced.

Is there someway to disable the error about:

placement new would change type of storage

? If not, is there some code modification to disable that error message in
this particular case? If so, where is that code?

[frederick-vs-ja]

I slightly clang-formatted your code to make it more readable.

In short, although a byte array (array of unsigned char/std::byte) can provide storage for other objects, such mechanism is effectively disabled in constant evaluation. In order to implement a constexpr-friendly variant, one can't rely on this mechanism, and should only use (possibly nested) union of desired types.

See also the implementation strategy of std::variant.

• libc++'s <variant>
• libstdc++'s <variant>
• MSVC STL's <variant>

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Larry Evans (cppljevans)

With the following code:

template < unsigned I >
struct type {
  constexpr type() {}
};

#include <cstddef>   //std::byte
#include <algorithm> //for std::max

template < typename... T >
union uninitialized_T0
/**&lt;@<!-- -->brief
 *  A buffer for stoarge of a 
 *  variant of types T...
 */
{
  constexpr uninitialized_T0() noexcept {}
  uninitialized_T0(const uninitialized_T0&amp;)            = delete;
  uninitialized_T0&amp; operator=(const uninitialized_T0&amp;) = delete;
  constexpr ~uninitialized_T0() noexcept {}

  static constexpr size_t Size = std::max({sizeof(T)...});

  alignas(T...) std::byte buffer[Size]{}

  /**&lt;@<!-- -->brief
   *   Storage for any of T... with proper alignment for all.
   */
  ;
  constexpr void* voidify() { return buffer; }
//#define EXPLICIT_TYPE0
#ifdef EXPLICIT_TYPE0
  type&lt;0&gt; t0
      /**&lt;@<!-- -->brief
       *  The only reason for this is to show the
       *  absurdity, in one sense, of the error when
       *  defined(USE_BUFFER) &amp;&amp; defined(USE_CONSTEXPR). 
       *
       *  The error is not absurd in another sense because
       *  it conforms to the &lt;A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2747r2.html"&gt;standard&lt;/A&gt;:
       *  saying(at "(5.14)"):
       *    "unless P points to an object whose type is similar to T;"
       *  and std::byte[Size] is NOT similar to type&lt;0&gt;.
       *
       *  OTOH, it is absurd because the purpose of this union is to provide
       *  an uninitialized buffer in which to placement new a type, T, whose 
       *  "alignment and size requirements" are "compatible"
       *  with that of the buffer's.
       *
       *  Note, "alignment and size requirements" means alignas(T) and sizeof(T). 
       *
       *  The constraint, "similar to" should be irrelevant, in this case.
       */
      ;
#endif //EXPLICIT_TYPE0
};

#include &lt;new&gt;

template &lt; typename... T &gt;
struct variant {
private:
  uninitialized_T0&lt; T... &gt; storage;

public:
  constexpr variant() {
    new
#ifdef EXPLICIT_TYPE0
        (&amp;storage.t0
    //with clang++20, WHEN defined(USE_CONSTEXPR),
    //this compiles without error.
#else
        (storage.voidify()
    //with clang++20, WHEN defined(USE_CONSTEXPR),
    //this causes error:
    //  error: constexpr variable 'v' must be initialized by a constant expression
    //  note: placement new would change type of storage from 'std::byte' to 'type&lt;0&gt;'
#endif //EXPLICIT_TYPE0
         ) type&lt;0&gt;;
  }
};

int main() {
  variant&lt;type&lt;0&gt;, type&lt;1&gt;, type&lt;2&gt;&gt;
#define USE_CONSTEXPR
#ifdef USE_CONSTEXPR
      constexpr
#endif //USE_CONSTEXPR
      v;
  return 0;
}

When:

defined(USE_CONSTEXPR) and !defined(EXPLICIT_T0)

as explained in the comments, clang++-20 -std=c++26 produces the error shown in the comments.

However, when:

defined(USE_CONSTEXPR) and defined(EXPLICIT_T0)

No error is produced.

Is there someway to disable the error about:

placement new would change type of storage

? If not, is there some code modification to disable that error message in
this particular case? If so, where is that code?

[tbaederr]

Closing since the question has been answered and question aren't issues anyway.

[cppljevans]

In short, although a byte array (array of unsigned char/std::byte) can provide storage for other objects, such mechanism is effectively disabled in constant evaluation. In order to implement a constexpr-friendly variant, one can't rely on this mechanism, and should only use (possibly nested) union of desired types.

See also the implementation strategy of std::variant.

Thanks @frederick-vs-ja.

I'm aware of the nested or recursive union implementation of std::variant.

But recursive templates, such as, I believe, used in std::variant, suffers the problems described here.

What's is puzzling is why this is necessary. IOW, why is "such mechanism disabled in constant evaluation"? It makes no sense.

This code tries to show that it makes no sense because when defined(EXPLICIT_type0), there's no compile
error; yet:

&storage.t0

is at the same location as:

storage.voidify()

[frederick-vs-ja]

What's is puzzling is why this is necessary. IOW, why is "such mechanism disabled in constant evaluation"? It makes no sense.

IMO unions are considered more well-typed (by implementations) and hence it's quite easier to check validness of operations on unions than storage-providing buffers in constant evaluation.

On the other hand, a feature (storage providing mechanism in constant evaluation for this example) is missing by default until one designs or implements it.

I think it's better to be aware of that there're some unanswered questions for this feature. E.g.

1. How to determine the alignment of address of each byte in the buffer during constant evaluation? Note that it's undefined behavior to create an object at a misaligned address, and the alignment of address of some byte in the buffer can vary for each execution at run time.
2. How to enable reinterpret_cast, which is necessary for accessing the object whose storage is provided by the array, in constant evaluation? Currently reinterpret_cast always results in constant evaluation failure. Perhaps we also need to fix some launder-related mechanisms, see P3006R1.

If you have deterministic answers for how to select storage-provided objects and verify of validness of operations on a storage-providing byte array during constant evaluation, I recommend you to write a paper targeting WG21/EWG.