pon., 24 mar 2025 o 13:01 Jonathan Wakely <cxx_at_[hidden]> napisał(a):
>
> 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.
>
>

`[[gnu::always_inline]]` is fine as what consequences are there if we
ignore it? It could reduce performance but the end result should be
the same (same with `[[optimization(size)]]`).

For `[[gnu::packed]]` and `[[no_unique_address]]` I would prefer a
contextual keyword as it could affect ABI and if the compiler does not
recognize it it should crash as it could result in an incorrect
layout.

`[[clang::musttail]]` is mix as in some context it will be fine but if
I try deep call-taill I could stackoverflow on unsupported compilers.

If we want not-ignorable attributes it should be explicit and know
upfront even if compiler is 10y old.
I would suggest change syntax a bit and add `!!` to attribute to mark
it required:

```
[[!!no_unique_address]] int foo;
```

or

```
[[!!(gnu::packed, clang::packed)]] class Foo;
```

If the compiler does not recognize and support any attribute from this
it should break compilation.

One benefit of this solution is "backward compatibility", all old
compilers will reject this code as it contains
illegal characters in attributes.

Overall even if there are "required" attributes I would keep them to
only control implementation defined behaviors.