Thanks for the feedback, Richard!

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

I was actually thinking the most compelling use cases were all the *smaller*
uses of attributes that are complicated by the need to have
preprocessor-based compatibility layers smoothing out the differences
across all the tools and tool versions. For instance, it should be fairly
lightweight to use `gsl::suppress` to suppress diagnostics in a relatively
vendor-portable way... except the vendors that do *not* support gsl
attributes flag the `gsl::suppress` attribute itself!

What can downstream users do? They could find or write libraries to support
`gsl::` attributes portably. But sometimes, like for header-only libraries,
the extra dependency would be a non-starter. In those cases, one could
write bespoke macros on a case-by-case basis. But both approaches are
unsatisfactory to me, especially given that each solution requires
nonstandard mechanisms (more code to write or reuse) and vendor-specific
attributes, as designed, should work portably.

That being said, I don't mind showing real-world impact by forking some
project and playing around with it if someone has an example in mind
already. In the case of user-defined attributes, I suspect there aren't
many good examples, especially given the friction caused by the problem I'm
describing in this paper. Instead, the bulk of attribute macros I've seen
anecdotally are for backwards and forwards compatibility for different C++
standards versions. But before I bother researching *that* sort of
real-world impact, I'd like to make sure solutions in this space would
target not-yet-standard attributes as an interesting use case.

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


I'll defer to others' interpretation of the standard. I'll cop to a shallow
understanding of the wording and the implications thereof. I still feel
like the wording of the standard implies a problem in the status quo,
however.

To argue ad absurdum, I do know that it would be unacceptable to end users
if a compiler started issuing compiler errors every time a class was
declared with a name that started with the letter 'A'. If a user were to
file this as a bug report against the compiler, I'd upvote that bug report
as classes are standard C++ features and they are allowed to have names
that start with the capital letter A.

Similarly, attributes are explicitly allowed to be spelled certain ways, so
I'd upvote bug reports against vendors that issued diagnostics against
`gsl::suppress`, for example. In other words: what was the point of adding
a standard `[[ vendor::something ]]` syntax when nonstandard extensions
like `__vendor_attribute__(something)` already existed and could hide
behind preprocessor indirection just as easily?

Even given that, I have some reservations about bug reports to vendors.
Basically, I'm not sure what a maintainer of a compiler or tool should do
to resolve such a bug report. In particular, as covered by the paper, I
don't see how to avoid *other* problems like misspellings of attribute
names. I expect that some broader discussion could provide some ideas in
this space. *My* best idea so far is providing a way to declare externally
defined attributes, but perhaps there is a better option out there.

Bret

On Wed, Mar 16, 2022 at 5:00 PM Richard Smith <richardsmith_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).
>
> Regards,
>> Bret Brown
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>
>