I came across this thread from the old mailing list today: https://groups.google.com/a/isocpp.org/g/std-discussion/c/YEB0sIgGoHA/m/PL4NYEq5yykJ

The claim was that std::atomic<T> has undefined behavior if T fails to meet the requirement that it "shall be trivially copyable". Daniel Krügler stated that [res.on.functions]/2 (I suppose of what was at the time the C++14 draft) applied to this situation.

I've always thought that [res.on.functions] only applies to the specific cases delineated in that section, which is necessary because violations of the requirements in those specific cases are impossible to diagnose in general. For example, the compiler cannot prove that a replacement allocation function fails to return suitably aligned storage. A standard library component cannot `static_assert` that it has been instantiated with a complete type, for reasons discussed here.

So, my interpretation is that [res.on.functions]/2 doesn't apply to the violation of the trivially copyable requirement for atomics. I think that [intro.compliance]/1 controls (i.e., such violation is required to be diagnosed), as Casey Carter originally stated.

For atomics, the issue is moot in C++20 because the standard now says that the program is ill-formed if the type is not trivially copyable. However, as [res.on.functions] still plausibly applies to other sections of the standard, I am still wondering what it is supposed to mean.

--
Brian Bi