On 13/02/2026 20:18, Simon Schröder via Std-Proposals wrote:
>
>
>> On Feb 13, 2026, at 2:52 PM, David Brown via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> I am quite convinced the answer is that we /do/ need something that is basically like today's attributes, but not ignorable. However, I am very much open to the idea that this could be "something like attributes" rather than attributes.
>>
>> Call them "characteristics", and use smiley brackets - (-: ... :-)
>
> We do have two new characters in C++ (@ and $) that could be used for something. We could use one of these for new (context dependent?) keywords. It would look a little nicer than the square brackets of attributes and it certainly doesn’t collide with any existing code.
>>

Those would look better, yes.

Historically there have been a few uses of @ in compiler extensions, but
I think the risk of collisions with existing code are minimal. (I have
seen it used for placing data at specific addresses in embedded systems,
for example.)

The $ sign is a bit riskier as many compilers have supported it as a
"letter" in identifiers for decades. While it is obviously not found in
portable code, it /is/ used in some real-world code, and that might
conflict with some potential uses in new syntax. (As I understand it,
early proposals for reflection used $, but were changed to avoid such
conflicts.)

>>
>> It might also be nice if tools like doxygen and Code Sonar started having [[dox:: ]] and [[sonar:: ]] attributes. Even better would be an independent body defining [[lint:: ]] attributes that Code Sonar, Coverity, and others could use (with gcc and clang supporting what they can). That would hugely benefit developers who want to use multiple tools. And yes, those would /definitely/ be ignorable by other tools!
>
> IIRC in the context of reflection we will get user-defined attributes with the [[=myattribute]] syntax (notice the =). For doxygen we could even reflect over all documentation attributes and write out appropriate documentation (with the current reflection proposal, we can’t write to files at compile time, but we can create a string that is itself C++ code which will be a program that does what we want). In the future we don’t need extra tools (which would have to catch up with new standard syntax), but can do everything at compile time and the fully compliant compiler does the heavy lifting.

I am sure the doxygen and linter folk will be appreciate that - parsing
C++ is a steadily more complex task. As a user of cross-compilers, I
would also be happy to get all the parsing done from one place - it is
not easy ensuring that things like include files, pre-defined macros,
etc., all match up appropriately for different tools.