https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368
--- Comment #3 from Hannes Hauswedell <h2+bugs at fsfe dot org> --- (In reply to Jonathan Wakely from comment #2) > It might be reasonable for GCC to silently ignore attributes that use an > unrecognized attribute-namespace. If somebody uses [[clang::foobar]] or > [[acme::rocketboots]] they probably aren't expecting GCC to handle it. > > This could mean silently ignoring typos like [[ngu::unused]] but it's > arguably easier to spot a typo like "ngu" than to spot "warn_unsued_result" > or "alwasy_inlne". That's true, but I would still argue that *by default* GCC should also ignore [[foobar]] if it doesn't know it. Let me elaborate: I develop a header-only library and want to start including [[likely]] so that for newer compilers things "start working" as soon as they pick up the feature. I am ok with [[likely]] not being interpreted by the compiler, that's why a choose an attribute to begin with and not some low-level magic, but if it works, all the better. This is precisely what attributes are designed for and why they are supposed to be ignored if unknown. BUT if this code generates warnings there is a problem: obviously I don't want to tell downstream developers that "it's ok, just ignore the warnings" (since I have a header-only library I cannot pre-decide this). And I cannot workaround this in code short of introducing a MACRO. Note that not being able to workaround the warning makes this different from almost all other warnings I am aware of. And wrapping future attributes in MACROs just to be able to ship code that is warning/error-free clearly defeats the intent of the standard, or not? I am not sure, maybe we should take the question to a reflector?
