On Fri, Mar 12, 2021 at 8:16 AM connor horman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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"?
At least I thought the "should have a reason" meme was used in more than
just P1301 [[nodiscard("should have a reason")]]
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1301r4.html>.

my $.02,
–Arthur