On Wed, Nov 13, 2024 at 3:32 AM Alberto Barbati via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Il 12/11/2024 17:21, Thiago Macieira via Std-Proposals ha scritto:
On Tuesday 12 November 2024 04:40:00 Pacific Standard Time Alberto Barbati via 
Std-Proposals wrote:
Hello everyone,

I'd like to know if there's interest in introducing a way to selectively
ignore the effects of the [[deprecated]] attribute. [...]
3. Unit-testing the deprecated API itself.
2) Should we use a different attribute (as "deprecated_ignorable" above)
or can/should we overload the existing [[deprecated]]?
I don't think so. Either you have a reason to ignore a deprecation or you 
don't. The library author has already given you a heads up that this is either 
going away or is obsolete for some reason (or actively dangerous).

[...] Of course, the only solution is to write a paper :)


I strongly encourage you to solve this at the toolchain level, not the ISO level.
Basically what you're asking for is a way to "suppress" the deprecation warning for a specific component, for a specific stretch of (e.g. unit-testing) code.
That's already possible today, using the tool specially designed for marking stretches of code:

[[deprecated]] int f1();
[[deprecated]] int f2();
int f3();
void test_f1() {
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored("-Wdeprecated-declarations")
  f1(); f2(); f3();
#pragma GCC diagnostic pop
}

There is only one (theoretical?) problem with this solution: It's not fine-grained enough. It suppresses the warning about `f1`, yes, but it also suppresses the warning about `f2`.
What you're actually asking from the toolchain is a way to "whitelist" certain names — to say "I know I'm deliberately using these deprecated facilities, but please warn me about any others I'm using accidentally."
That would look something like this:

    g++ -Wall -Wno-deprecated-declarations=f1

and this:

    #pragma GCC diagnostic ignored("-Wdeprecated-declarations=f1")

Now, when you actually get this feature into code review, the compiler devs will poke lots of holes in it. For one thing, what if the deprecated declaration is a member function, or a hidden friend, or an operator — how do you even spell the name of such a thing? Or what if there are two deprecated overloads, and you deliberately use one, but want to be warned about the other — how can you spell that?

    [[deprecated("Please switch to the path-taking one")]] int f4(std::string);
    [[deprecated("We don't support flags anymore")]] int f4(std::string, int flags);
    int f4(const std::filesystem::path&);

I think concerns like this would probably stall an attempt to implement a fine-grained suppression mechanism.
But if practical concerns would stall it at the compiler level, bringing it to WG21 is exactly the most inappropriate approach. You should instead try to find something that you think will work at the local level, implement it (or get it implemented), and then see if programmers need it to be in the paper standard or not.

Notice also that you are reinventing the classic tool named "lint", which has many modern incarnations in different languages.
Each "lint" variation has invented its own ways of indicating "I am deliberately doing [bad thing] on this line; please don't warn me about it."
Here's the best man page I found in a quick search (for `flake8`, the Python linter):
https://flake8.pycqa.org/en/3.1.1/user/ignoring-errors.html

HTH,
Arthur