CWG 2024-04-19

The note embodies EWG design guidelines for attributes; CWG requests EWG to address the inconsistency, via paper issue 1890.

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).