czw., 4 maj 2023 o 13:23 Edward Catmur via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> On Thu, May 4, 2023, 05:40 Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>
>>
>> On Thu, 4 May 2023 at 11:22, Lauri Vasama via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>> The fact is that there are programs which behaviours depend on whether the implementation chooses to ignore this particular attribute or not. Perhaps that is fine, but perhaps not. As noted in the draft proposal, Microsoft has also been unwilling to implement [[no_unique_address]] in its ignorable form because it would cause an insidious ABI incompatibility depending on the language standard in use.
>>
>>
>> How does your proposal help with that? Assuming your proposal got into C++26, you wouldn't be able to use [[!no_unique_address]] in C++23 or older, so you'd have exactly the same problem.
>>
>> struct A {
>> #if __cplusplus >= 202600
>> [[!no_unique_address]]
>> #endif
>> B b;
>> };
>>
>> How does this help?
>>
>> If your intention is to somehow force MSVC to support the attribute, I don't think your proposal achieves that. They will just refuse to support the new form as well, because it has the same issues (older versions of MSVC will not support the attribute, whether "required" or not, and so the same risk of ABI incompatibility exists for any code using it). So the proposal is not well motivated.
>
>
> But you wouldn't write that. The point is that you'd rather the program fail to compile than to compile without the attribute in effect, whether because the compiler doesn't understand it, hasn't implemented it, or is unable to apply it in this particular instance.
>
> You would then be able to investigate whether to drop support for that compiler, apply flags to that compiler to change behavior, or rewrite your program so that it uses some other technique.
>

But attributes "failure" should be preferably "invisible" and
"undetectable"? 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.

>
>
>>
>>>
>>> Thank you for the information regarding the usage of italics. I'll be sure to keep that in mind in the future. Certainly the wording here is demonstrative at best.
>>
>>
>> Your proposal doesn't mention how __has_cpp_attribute works with required attributes, or even if it does at all.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals