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).

Regards,
> Bret Brown
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>