>> If you allow customizing the level to "error", your proposal will need to explain how that level is different from `=delete`.
>
> My thinking for that would be, if it were an "advisory" level to the implementation, it could be used to select the default behaviour (so error would make it so that -Werror=... is on by default, and users could suppress with -Wno-error=... or -Wno-...). However, if that's the case, this is probably more granular control in default behaviour then implementations offer already (and would be reasonable to offer).
> Also, under that interpretation, I'm at a loss to explain "info".

Consider a mostly closed and stable code base with a core library consumed by a number of product applications which are expected to mostly keep pace with library releases. As API breaks are identified for the major version release, they can be marked with an info level diagnostic, which wouldn't be promoted by -Werror and break builds, but would give the application teams notice to start anticipating the change in terms of usage and build machinery. At some point before the major version release (let's say feature freeze), those 'info's change to 'warn', and the application teams are nudged a bit harder to prepare for the major version bump. This process could be used in reverse for "experimental" features.

As Arthur pointed out, the use case for an error level diagnostic is, perhaps, narrower, since =delete is an option. Simply marking a function as deleted, however, doesn't provide an opportunity for a custom message. Extend the above scenario with an emergency patch in which some function must not be used, for whatever reason. A custom diagnostic message could be infinitely more helpful than "error: use of deleted function" in such a scenario.

Thanks,

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 12, 2021 7:07 AM, connor horman via Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Fri, Mar 12, 2021 at 08:56 Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>
>> 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>".
>
> Makes sense, though the -Werror syntax for that would be fun: -Werror=custom=abi (not necessarily an issue, just an observation).
>
>> [[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`.
>
> My thinking for that would be, if it were an "advisory" level to the implementation, it could be used to select the default behaviour (so error would make it so that -Werror=... is on by default, and users could suppress with -Wno-error=... or -Wno-...). However, if that's the case, this is probably more granular control in default behaviour then implementations offer already (and would be reasonable to offer).
> Also, under that interpretation, I'm at a loss to explain "info".
>
>> 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