Date: Mon, 12 Feb 2024 20:34:00 +0100
On 12/02/2024 19.35, Gabriel Morin via SG14 wrote:
> We compile with warnings as errors on all projects. So custom attributes always triggering a warning is an issue. If we turn off the warning, typos such as [[no_un*o*que_addr*i*ss]] won't get caught. I was wishing for anything with a custom namespace to be accepted silently, while standard attributes are still validated. So what are we to do? File bugs against every single compiler despite the fact they already standardized on this behavior for some reason? Seems like a tall order.
If you're being convinced in this e-mail thread that a change to the
standard to achieve what you want is an even taller order, we've made
progress.
In particular, changing the standard means convincing implementers to
support the new way of doing things. We rarely standardize something
against express implementer opposition.
> Since all compilers act like this, I assumed it was standard-mandated (and my attempts at deciphering the standard didn't seem to contradict this).
Where did you read a mandate in the standard to issue a warning for
an unrecognized attribute?
> Is the standard really unable to enforce that compilers should not emit a warning in a given situation? In some situation it says that "implementations are encouraged to emit a warning". So it seems to me it could say "implementations are discouraged from emitting a warning" whenever an attribute with a custom prefix is detected.
"encouraged" / "discouraged" is not enforcement.
I'm not aware of any situation where we expressly prohibit issuing
a diagnostic (i.e. warning).
> /But perhaps a more elegant solution to coax things
We tend to avoid coaxing things. We try to make principled, well thought-out
amendments to the ISO standard for C++, a language millions of people rely on.
> in the right direction would be to allow declaration of custom attributes./ For now, this declaration would do nothing, but down the line it could be associated with a custom attribute implementation in C++ code.
If and when there's a design for a "custom attribute implementation in C++ code",
I'm interested in adding syntax for declaring attributes.
> This way it'd be more natural for the compiler to accept your attributes, and you'd get typo protection.
What about adding a feature to your compiler that reads something like
-Wattributes-ignore=<namespace>
and suppresses warnings for those attributes only? That feels like a fairly
small extension and seems useful beyond your particular use-case.
> Is this placement between the name and the trailing semicolon valid?
May I suggest that you familiarize yourself with the grammar aspects
of attributes before attempting to suggest core language changes around
such? [dcl.decl.general], grammar production noptr-declarator might be
one place where to look. Also, of course, [dcl.attr].
> For the purpose I have in mind, it would help readability, and most especially match the existing use of code generation tags in various engines while allowing automatic upgrades of the code with tools.
> class Test {
> int m_member [[no_unique_address]];
> };
>
> If it's not valid, would a proposal to make it valid make sense?
Have you actually tried that, e.g. on godbolt.org ?
Jens
> We compile with warnings as errors on all projects. So custom attributes always triggering a warning is an issue. If we turn off the warning, typos such as [[no_un*o*que_addr*i*ss]] won't get caught. I was wishing for anything with a custom namespace to be accepted silently, while standard attributes are still validated. So what are we to do? File bugs against every single compiler despite the fact they already standardized on this behavior for some reason? Seems like a tall order.
If you're being convinced in this e-mail thread that a change to the
standard to achieve what you want is an even taller order, we've made
progress.
In particular, changing the standard means convincing implementers to
support the new way of doing things. We rarely standardize something
against express implementer opposition.
> Since all compilers act like this, I assumed it was standard-mandated (and my attempts at deciphering the standard didn't seem to contradict this).
Where did you read a mandate in the standard to issue a warning for
an unrecognized attribute?
> Is the standard really unable to enforce that compilers should not emit a warning in a given situation? In some situation it says that "implementations are encouraged to emit a warning". So it seems to me it could say "implementations are discouraged from emitting a warning" whenever an attribute with a custom prefix is detected.
"encouraged" / "discouraged" is not enforcement.
I'm not aware of any situation where we expressly prohibit issuing
a diagnostic (i.e. warning).
> /But perhaps a more elegant solution to coax things
We tend to avoid coaxing things. We try to make principled, well thought-out
amendments to the ISO standard for C++, a language millions of people rely on.
> in the right direction would be to allow declaration of custom attributes./ For now, this declaration would do nothing, but down the line it could be associated with a custom attribute implementation in C++ code.
If and when there's a design for a "custom attribute implementation in C++ code",
I'm interested in adding syntax for declaring attributes.
> This way it'd be more natural for the compiler to accept your attributes, and you'd get typo protection.
What about adding a feature to your compiler that reads something like
-Wattributes-ignore=<namespace>
and suppresses warnings for those attributes only? That feels like a fairly
small extension and seems useful beyond your particular use-case.
> Is this placement between the name and the trailing semicolon valid?
May I suggest that you familiarize yourself with the grammar aspects
of attributes before attempting to suggest core language changes around
such? [dcl.decl.general], grammar production noptr-declarator might be
one place where to look. Also, of course, [dcl.attr].
> For the purpose I have in mind, it would help readability, and most especially match the existing use of code generation tags in various engines while allowing automatic upgrades of the code with tools.
> class Test {
> int m_member [[no_unique_address]];
> };
>
> If it's not valid, would a proposal to make it valid make sense?
Have you actually tried that, e.g. on godbolt.org ?
Jens
Received on 2024-02-12 19:34:08