higher-performance wrote:
@ojhunt note that this is already the exact same problem `[[gnu::deprecated]]`
faced, and handled just fine:
```
void f3(void) [[gnu::deprecated]] {} // warning: attribute
'gnu::deprecated' ignored, because it cannot be applied to a type
[-Wignored-attributes]
auto g3(void) [[gnu::deprecated]] -> void {} // warning: attribute
'gnu::deprecated' ignored, because it cannot be applied to a type
[-Wignored-attributes]
auto g5(void) -> void [[gnu::deprecated]] {} // error: 'gnu::deprecated'
attribute cannot be applied to types
```
If we assume we want the `[[...]]` syntax, it seems only logical that it could
and should receive the exact same treatment.
So are you asking why the `[[...]]` syntax is better than the `__attribute__`
syntax? I would say for the same reason(s) that that is the case universally,
including for all the other attributes already supported with that syntax. Off
the top of my head (I may be missing some), just a few:
- Using a standard syntax rather than a nonstandard syntax allows it to compile
with other compilers openly, rather than having to hide it behind a macro that
users then have to navigate to the definition of in order to understand.
- The standard syntax is a lot friendlier to basic text-based tools (regexes,
lexers, etc.) as they can skip everything inside them without knowing what they
mean.
- Forcing users to put these behind a macro means parsers can understand the
file without having to read the `#include`s or preprocessing macros. (Lots of
examples here, but the most well-known is probably tree-sitter.)
- Rudimentary parsers/code generators/etc. don't understand nonstandard syntax.
- It's just so much easier to read. The underscores are ugly and distracting.
>From my perspective, therefore, the question is what is there to lose from
>treating this similarly to `gnu::deprecated`, `gnu::always_inline`, etc.?
>There are so many upsides and no real downsides I can see.
https://github.com/llvm/llvm-project/pull/225900
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
