Hi!

This is a known LWG issue which has been resolved: https://cplusplus.github.io/LWG/issue3870.

If you use the latest libc++ (Clang 20 trunk), the latest libstdc++ (GCC 15 trunk), or MSVC STL since VS 2022 17.7, the casting-away-constness use of construct_at will be error.

Thanks,
F.v.S.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of S¨¦bastien Bini via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, December 8, 2024 18:40
To: Std-Proposals <std-proposals_at_[hidden]>
Cc: S¨¦bastien Bini <sebastien.bini_at_[hidden]>
Subject: [std-proposals] Potential defect in std::construct_at

Hello,

I recently noticed something unexpected: it is possible to construct an object over constant storage with `std::construct_at`. At least it works in gcc 13.2.0 and clang 18.
Note that this is not possible with placement new.

I tried playing with the following code:
template <class T>
void swap_const_references(T const& a, T const& b)
{
T c{a};
a.~T();
std::construct_at(&a, b);
b.~T();
std::construct_at(&b, c);
}

And it compiles fine with both compilers. If I replace the std::construct_at with placement new, the code fails to compile (cannot convert 'const void*' to 'void*').

This swap_const_references is definitely something we don't want to be able to write! At least not without relying on UB. I can even make it constexpr and it is still compiling >< (and working as designed...)

I don't know who is in the wrong here, between the library implementers and the C++ standard. But here is a case where code with a non-constexpr placement new is actually safer than the shinny construct_at...

Should we open a defect to fix std::construct_at so it does not accept constructing over constant storage?

Best regards,
S¨¦bastien BINI