C++ Logo

std-proposals

Advanced search

Re: Allow [[deprecated]] on call site to disable deprecated warning

From: Avi Kivity <avi_at_[hidden]>
Date: Sun, 7 Feb 2021 16:36:32 +0200
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
> ill-formedness.


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).

Received on 2021-02-07 08:36:37