This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-19
Some attributes can cause undefined behavior, e.g. [[no_unique_address]] via attempting to transparently replace a subobject. Core language undefined behavior can be detected during constant evaluation (7.7 [expr.const] bullet 5.8). For example:
struct A {
[[no_unique_address]] int x;
};
constexpr int test(auto a) {
std::construct_at(&a.x, 1); // #1
return a.x;
}
template<typename T> constexpr bool call(int (*)[test(T())]) { return false; }
template<typename T> constexpr bool call(...) { return true; }
bool no_unique_address_works = call<A>(nullptr);
If [[no_unique_address]] has an effect, the attempt to transparently replace the member A::x at #1 is undefined behavior per 6.7.4 [basic.life] bullet 8.4, otherwise the replacement succeeds.
This behavior conflicts with the note in 9.12.1 [dcl.attr.grammar] paragraph 6:
[Note 5: The attributes specified in 9.12 [dcl.attr] have optional semantics: given a well-formed program, removing all instances of any one of those attributes results in a program whose set of possible executions (4.1.2 [intro.abstract]) for a given input is a subset of those of the original program for the same input, absent implementation-defined guarantees with respect to that attribute. —end note]
See also issue 2545 for implementation divergence and implementation misbehavior when replacing potentially-overlapping subobjects in constant expressions.
See also issue 2403, which might be resolved to demonstrate different behavior for potentially-overlapping subobjects (always copies) vs. non-overlapping subobjects (never copies; guaranteed copy elision).
CWG 2024-04-19
The note embodies EWG design guidelines for attributes; CWG requests EWG to address the inconsistency, via paper issue 1890.