czw., 4 maj 2023 o 16:39 Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> 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 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.)
>

I mean bit diffrent thing. I see attributes as optional constraints on
programer that compiler can exploit them to make code better, like
`[[noreturn]]`. `[[likely]]`, or `[[gnu::always_inline]]`.
They do not affect logic of program but affect is speed/size or other
specodary things that are many times outside of standard.
I personally would prefer that you could disable attributes in one TU
and still could link with the rest of the program that had enabled
them.
And I call this "ignorable" (same as `-O3` could be integrable but
critical for any program).
But of course currently standard do not work this way, and
`[[no_unique_address]]` or `[[trivially_relocatable]]` would break if
you link two TU that have diffrent interpretation of them.

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

It's ABI not QoI. If the owner of ABI decides he uses this, then
everyone else needs to follow.
You could not link functions compiled by GCC and Clang that have one
support `[[trivially_relocatable]]` and another do not.
This means to have "portable" programs for both these attributes your
headers need to have:
```
#if !__atturibte_supported(no_unique_address) ||
!__atturibte_supported(trivially_relocatable)
#error "please install new compiler"
#endif
```

> –Arthur
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals