On Wed, Mar 16, 2022 at 5:00 PM Richard Smith via SG15 <
sg15_at_[hidden]> wrote:

> On Tue, 15 Mar 2022 at 18:48, Bret Brown via SG15 <sg15_at_[hidden]>
> wrote:
>
>> Hi all!
>>
>> It's interesting that all the tools I've looked at have a hard time
>> distinguishing between misspellings of attributes and user-defined
>> attributes.
>>
>> Given that, and the need to keep the SG15 backlog populated, I have
>> marked a paper on the subject for review, though I believe I just missed
>> the filing deadline. It might be officially published in the April mailing.
>>
>> Here is the paper: https://isocpp.org/files/papers/P2565R0.pdf
>>
>> Here is the abstract:
>>
>> While the standard supports vendor-provided and otherwise user-defined
>> attributes in C++, actual use of nonstandard attributes while preventing
>> trivial misspellings is a challenge. In particular, diagnostics in
>> compilers used to prevent misspellings of standard and well-known
>> attributes will reject attributes provided for other contexts, including
>> attributes used to support other compilers. This document explores how this
>> problem presents itself in practice and proposes a potential attribute
>> declaration syntax to address the problem.
>>
>>
> This is an interesting approach. I think it would be great to live in a
> world where macros aren't used for attribute compatibility any
> more, although I'm not sure whether this paper takes us all the way there,
> so I'd really like to see an investigation into how close this paper would
> get us to that state: for example, an investigation in a codebase that
> makes moderate to heavy use of macros for attribute portability of how many
> existing macros could be replaced with this mechanism, and a
> before-and-after view of the code once the mechanism is in use. Do we end
> up with a mixture of macros and real attributes? Is the result more or less
> verbose than the original? Is the readability of the code improved?
>
> One comment on the status quo as described by the paper. You say that the
> requirement to ignore unknown attributes means that they "should be fully
> accepted by all tools. This includes issuing no warnings and no errors
> against the vendor-specific attributes." That doesn't follow: the standard
> has no notion of warnings or errors, only "diagnostics" (which may or may
> not include warnings depending on the implementation-defined meaning of
> "diagnostic"), and a conforming implementation is always permitted to
> produce a diagnostic on any program; the only requirement on an
> implementation regarding diagnostics is that ill-formed programs result in
> at least one (see http://eel.is/c++draft/intro.compliance.general#2).
>

Many of the attributes talk about warnings in their "Recommended practice";
that seems like the pattern to follow here, e.g.

*Recommended practice*: The use of an attribute declaration should suppress
a warning [diagnostic?] that an implementation might otherwise issue for an
attribute it does not recognize.

Jason