Subject: Re: [std-proposals] Allow [[deprecated]] on call site to disable deprecated warning
From: Dominic Fandrey (isocpp.id_at_[hidden])
Date: 2021-02-22 01:00:50
On 07/02/2021 15:36, Avi Kivity via Std-Proposals wrote:
> On 07/02/2021 16.28, Ville Voutilainen wrote:
>> On Sun, 7 Feb 2021 at 12:22, Avi Kivity <avi_at_[hidden]> wrote:
>>>> Create your own MY_DEPRECATED macro, make it expand to actual
>>>> deprecation normally, but not in unit tests,
>>>> compile the unit tests with -DMY_SOMETHING that disables deprecations.
>>>> Or just add a #define into
>>>> your unit tests.
>>> Doesn't that break with modules?
>>> We should not be suggesting solutions that involve the preprocessor in 2021.
>> Fair point. When the attribute is a property of a real declaration,
>> text-processing techniques no longer help.
>> I wonder whether we should go for a [[nowarn]] instead that just turns
>> off diagnostics that don't report
> That's a heavy hammer. I prefer more selective tools. For example, I wouldn't want a [[nodiscard]] warning discarded in a call site where I meant to shut down a [[deprecated]] warning.
> Perhaps [[nowarn(deprecated)]].
>> Â If I had that, I would certainly hop on my time
>> machine and make it available on every
>> C++11 compiler I've ever used. :)
> An approach that I've seen working is to make developer builds use -Werror, but user builds omit it. This way developers of a project have to battle the warnings (and suffer when a new compiler is released), but users are able to compile the project regardless of the compiler/platform combination (at least if warnings are the only problem).
Generally I wouldn't want to turn off the warning for all unit tests, not even for
a whole test (after all I want to keep my unit tests up to date). I would prefer
something that affects a single statement.
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups