On Mon, 24 Mar 2025 at 15:11, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> On Mon, Mar 24, 2025 at 8:01 AM Jonathan Wakely via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Mon, 24 Mar 2025 at 09:36, Marcin Jaczewski wrote:
>>
>>> pon., 24 mar 2025 o 10:13 Jonathan Wakely via Std-Proposals
>>> <std-proposals_at_[hidden]> napisał(a):
>>> > Yes, it seems appropriate as an attribute to me (but then I think the
>>> rule that attributes must be ignorable and can't change semantics is silly
>>> anyway).
>>>
>>> But for me it is right, as enforcing can be done by "clang format"
>>> when you push changes to a public repo.
>>> Or by other tools like PVS-Studio, or by only the developer of header
>>> library (if attributes affect self use in header) and his compiler,
>>> all user can use older compilers that are not aware of the attribute
>>> but still indirectly benefit from it.
>>>
>>
>> Which means we can't ever standardize attributes for e.g.
>> [[gnu::always_inline]] or [[gnu::packed]] or [[clang::musttail]] or
>> [[no_unique_address]] (oh whoops, we did, and we come up with contorted
>> explanations for why it isn't *really* changing semantics and ignoring it
>> is fine), or alignas (oh right, it's defined as part of the attribute
>> grammar but is actually a keyword, because we couldn't add it as an
>> attribute due to the ignorable rule).
>>
>> Attributes are precisely the right tool for extending the semantics in
>> particular places without having to introduce new keywords every time.
>>
>
> @jwakely: You know this, and I know this; why doesn't WG21 know this?
>

I keep saying it in square brackets and so everybody ignores me.