I would say the same thing. By generalizing from "experimental feature diagnostic" to "custom diagnostic" you've also increased the scope of the diagnostic, which prevents fine-grained control of these custom diagnostics. With simply [[diagnostic]] programmers would have the option to disable none or all. With a set of specialized diagnostic attributes (deprecated, experimental, etc.) then programmers can pick and choose what diagnostics to ignore, what diagnostics to promote to errors, and which to leave.
Yes, although, you could solve that by scope-creeping again: the vendor might provide `-Wcustom=<tag>` with the semantics that it produces a warning for any "custom diagnostic" attribute whose tags include "<tag>".
[[diagnostic(experimental, abi, v1.4, "a custom message")]] void f();
[[diagnostic(deprecated, v1.2, "a custom message")]] void g();
[[diagnostic(v1.2, "a custom message")]] void h();
gcc -Wcustom=v1.2 test.cpp
// warns on uses of `g` and `h`, but not `f`
On 11/03/2021 17.55, codusnocturnus via Std-Proposals wrote:
> Why not just a generic compiler diagnostic message mechanism?
>
> [[diagnostic(level, msg)]]
> Where level in { info, warn, error }
If you allow customizing the level to "error", your proposal will need to explain how that level is different from `=delete`.
Am I just imagining that someone recently submitted a proposal "=delete should have a reason"?
my $.02,
–Arthur