Date: Mon, 24 Mar 2025 17:08:20 +0100
pon., 24 mar 2025 o 16:56 Matheus Izvekov via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> I don't disagree in principle with the idea of allowing more kinds of
> attributes, which currently ignorability rules out.
>
> But I think the status quo with vendor attributes is not very safe.
> Either they should be mandatory to implement, or the compiler should
> make it ill-formed
> to use an attribute it doesn't know about, which seems would be quite
> a breaking change.
>
This is why I would like to have explicit "required" attributes that
if older compilers try to parse them fail with invalid syntax exceptions.
> On Mon, Mar 24, 2025 at 12:11 PM Arthur O'Dwyer via Std-Proposals
> <std-proposals_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?
> >
> > –Arthur
> > --
> > 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
<std-proposals_at_[hidden]> napisał(a):
>
> I don't disagree in principle with the idea of allowing more kinds of
> attributes, which currently ignorability rules out.
>
> But I think the status quo with vendor attributes is not very safe.
> Either they should be mandatory to implement, or the compiler should
> make it ill-formed
> to use an attribute it doesn't know about, which seems would be quite
> a breaking change.
>
This is why I would like to have explicit "required" attributes that
if older compilers try to parse them fail with invalid syntax exceptions.
> On Mon, Mar 24, 2025 at 12:11 PM Arthur O'Dwyer via Std-Proposals
> <std-proposals_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?
> >
> > –Arthur
> > --
> > 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
Received on 2025-03-24 16:08:35