I wasn't aware of P1887R1! I'll read over it. Probably it should be referenced in this new paper. I did consider reflection as a use case, though I didn't call it out explicitly. One of the biggest reasons people want C++ reflection and/or code generation is for serialization and serialization and a family of attributes that convey "ignore this field when serializing" would be popular, I expect.

What is the status of P1887? If it has stalled or failed to reach consensus, there might be relevant concerns to incorporate in the discussion of this new paper.

As to declaration syntax, I am not opposed to different thoughts there. Using struct or constructor declarations would parallel user-defined attribute features from other languages.

Though we do have two issues to consider. First, can one declare a "will_be_in_the_next_standard" struct in cases where there is a legacy version of a  compiler to educate? One use case I would like to solve is the need for compatibility macros. Second, is it fine to assume relevant namespaces map to attribute names?

At any rate, I have some questions, but I think I'm fine converging the papers if SG15 as a group likes that idea.


On Tue, Mar 22, 2022, 04:14 Corentin Jabot <corentinjabot@gmail.com> wrote:
I'd like to point out https://wg21.link/p1887r1 - Reflection on attributes which have a different goal (being able to reflect on user defined attributes), but a similar conclusion:
attributes would be in general that much more usable if they were declared before being used.

My approach at the time (this is not something I'm currently actively pursuing as reflection has not progressed) was to use defined attributes as good old c++ structs with a constexpr constructor,
which allow for different overloads and can do some validation - without adding new syntax.

I don't know if you would find this approach suitable,  but maybe we can converge on a solution.

Alas, because of the whole "attribute can be ignored even if compilers warn on unknown attribute" thing, it's likely that people will want a new syntax...
This is the feedback I got at the time anyway.

struct my_attr {};
[[my_atr()]] void foo(); // typo or other attribute that should be ignored?
[[+my_atr()]] void foo();  // some kind of sigil might be necessary.

Have a great day, 

On Wed, Mar 16, 2022 at 2:48 AM 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.

Bret Brown
SG15 mailing list