That's right. My intention is not at all to try to force Microsoft's hand. Their hesitation to implement [[no_unique_address]] serves to demonstrate the problem with the ignorability of attributes, though of course there is no problem if attributes never affect program behaviour, but that particular cat is now out of the bag. I can't speak for Microsoft of course, but i believe they would not have the same objection to implementing no_unique_address if its use was ill formed in compiler versions or language modes where it is not supported.


As for __has_cpp_attribute, that is a good question. Requiring it to return 1 iff the required form of the attribute in question would be accepted seems in line with my draft proposal as written.




On 4 May 2023, 14:23, at 14:23, Edward Catmur <ecatmur_at_[hidden]> wrote:
>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.
>
>
>
>
>>
>>> 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
>>