Generally, when things get deprecated they happen for a reason.

That reason mainly being “there’s something that is not ideal with it and you should not use it”, but more than just that “for whatever reason you are trying to use the deprecated content, there is for all cases an alternative that is better and you should use that instead”, and you are also saying “we would have removed this right now but didn’t because you might be using it and we don’t want to break your stuff right now, so please change your stuff we will likely remove this in the future”.


  1. If there is a valid use case that is not replaceable by something else
  2. There’s no intention of removing the content in the future

Then it is not really deprecated.

Having said that, marking something as [[deprecated]] really does nothing, it changes no behavior, your compiler will still be able to compile the code just the same.
Unless you turn on a compiler specific option (that is not mandated by the standard) to abort compilation and force it to fail.

If you introduced a tag that would allow you to ignore something being flagged as deprecated, people would use it, thus defeating the purpose of it being flagged as deprecated. (i.e. this is going to be removed in the near future, you should be using something else please change it). In other words, they would just use it to ignore it not realizing the that come problems later.

It’s like having a unit test that does not have deterministic test cases, when it fails devs don’t go fix the cause of the fail, they just re-run the test again until it passes and becomes the next person’s problem.




From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Alberto Barbati via Std-Proposals
Sent: Tuesday, November 12, 2024 1:40 PM
To: std-proposals_at_[hidden]
Cc: Alberto Barbati <alberto_at_[hidden]>
Subject: [std-proposals] RFC: Ignorable deprecation


Hello everyone,

I'd like to know if there's interest in introducing a way to selectively ignore the effects of the [[deprecated]] attribute. Such a thing could be useful in at least two scenarios:

  1. You have an old API that is being replaced by a new API, but the new API is written in terms of the old one (either temporarily or because you plan to make the old API private in a future release, without completely removing it)
  2. You have both a “safe” and an “unsafe” API and you want to encourage the naïve user to use the safe one, while giving the possibility to an experienced user to choose the unsafe API by declaring such intent explicitly

This is an example of case b, with *placeholder* syntax:

 // this is the old API, that still works but is deemed unsafe
[[deprecated_ignorable("unsafe", "This overload is unsafe, please use strlen_s")]]
size_t strlen( const char* str );

// this is the new "safe" API
size_t strnlen_s( const char* str, size_t strsz );

void f(const char* str, size_t str)
{
    // this use of strlen is flagged as deprecated by the compiler, possibly raising a warning
    auto len1 = strlen(str);

    // this line should not emit diagnostics
    auto len2 = strlen_s(str, MAX_SIZE);

    // we know what we're doing and really want to suppress the warning
    [[ignore_deprecation("unsafe")]]
    {
        // in this scope all ignorable deprecations with the tag "unsafe" are ignored
        auto len3 = strlen(str); // no diagnostic here
    }
}

Details of the precise syntax are open to discussion. A few, certainly not all, questions to address are:

1) Are attributes the right tool?

2) Should we use a different attribute (as "deprecated_ignorable" above) or can/should we overload the existing [[deprecated]]?

3) The example above uses a string literal to tag the deprecation, so that it can be referenced in [[ignore_deprecation]]. Alternatives and variations could be considered, including, but not limited to, identifiers instead of strings, multiple tags, etc.

4) Should [[ignore_deprecation]] be applied only to compount statements (as in the example above) or other statements/entities? Are there scopes that could use the attribute that we would be missing (for example function default arguments)?

In case there's interest, I am going to write a more detailed paper with a formal proposal.

Thanks for your feedback,

ab