Date: Fri, 12 Mar 2021 09:07:29 -0500
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
>
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
>
Received on 2021-03-12 08:08:27