Date: Mon, 24 Mar 2025 11:11:15 -0400
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?
–Arthur
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?
–Arthur
Received on 2025-03-24 15:11:29