On February 7, 2021 1:22:41 PM Avi Kivity via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> On 28/01/2021 13.34, Ville Voutilainen via Std-Proposals wrote:
>> On Thu, 28 Jan 2021 at 13:06, Dominic Fandrey via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>> I recently ran into this issue:
>>>
>>> 1. Marked a set of legacy methods [[deprecated]]
>>> 2. Unit tests no longer compile (we run -Wall -Werror of course)
>>>
>>> Of course I don't want to get rid of the unit tests before I get rid of the
>>> functions. So I was faced with two choices:
>>>
>>> 1. Create #ifdef #pragma soup for all 3 compilers that we use
>>> 2. Remove [[deprecated]]
>>>
>>> The #ifdef #pragma soup needs to be updated every time a compiler is added,
>>> and it bloats the code and makes unit tests more difficult to read. So I
>>> went for option 2. As long as I cannot ignore [[deprecated]] in a portable
>>> manner I cannot use it.
>>>
>>> So my suggestion is:
>>>
>>> ```
>>> [[deprecated("use: std::optional<std::size_t> size()")]]int
>>> size(std::size_t & size);
>>>
>>>
>>> bool test_size() {
>>> std::size_t s{0};
>>> return 0 == [[deprecated]]size(s) && s != 0;
>>> }
>> 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.

I don't think that preprocessor is deprecated or its proper use should be
judged or anything. A preprocessor based solution is fine if this tool is
best fit for the job.