Marcin Jaczewski wrote:
>
> But attributes "failure" should be preferably "invisible" and
> "undetectable"?


Should it, though? As Timur said, he wrote a proposal that said attributes
should be ignorable, and that wording got into (a note in) C++23. But
*should* it have? Attributes are just part of C++'s syntax — they're part
of the language — and they are "non-ignorable" in the same sense that `if`
or `const` are "non-ignorable." Attributes, similar to keywords like `if`,
have very real *intended effects* on the program's semantics, and it's
certainly a problem for the working programmer if the compiler is allowed
to just *ignore* part of the programmer's code.
The "ignorable attributes rule" is defensible only by semantic arguments,
such as:
- WG21: "Attributes can be ignored, but a quality implementation should of
course *voluntarily* support them."
- Working programmer: "Okay, then, I choose to use only quality
implementations, because my code won't work as intended on non-quality
implementations."
- WG21: "Okay, we'll give you a way to detect
<https://eel.is/c++draft/cpp.cond#6> whether an implementation is quality
or not."

If a construct were truly "ignorable," then the working programmer wouldn't
write it at all; there's no sense in writing something that will have no
effect in practice. (He writes, ironically.)


Like `[[noreturn]]` you can't easily detect that the compiler generates
> useless return handling.
> `[[no_unique_address]]` probably is a bad attribute as its "failure" causes
> UB and portability problems.
> I personally think that `no_unique_address` should be the keyword as this
> affects ABI, then if compiled do not support it it will simply reject the
> program.
> I now do not recall any other attribute that the compiler needs to implement
> otherwise it would break something.


[[no_unique_address]] is "ignorable" as a QoI issue (as above).
You can tell whether the compiler ignored it or not by inspecting
`sizeof(T)` after the fact.

Another example close at hand is P1144's proposed
[[trivially_relocatable]], which is "ignorable" as a QoI issue.
You can tell whether the compiler ignored it or not by inspecting
`std::is_trivially_relocatable_v<T>` after the fact.

–Arthur

>