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@google.com> wrote:
On Tue, 15 Mar 2022 at 18:48, Bret Brown via SG15 <sg15@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15