On Fri, Nov 15, 2024, at 10:10, Sebastian Wittmeier via Std-Proposals wrote:
> Hi Henry,
>
>
> you probably would just want to suppress the actual direct use of the
> identifier, not indirect ones (e.g. within called functions), as those
> could be called with or without suppression.

Ideally yes, but I'm willing to compromise.

> Perhaps that works not everywhere, but it reduces the need for
> individual suppression.
>
> OTOH it makes automatic tool use to insert the [suppress] more
> difficult, as it now has to separate the expressions.

This is why I'm willing to compromise. More than once I've build some new API that is a modern style and better than the old one. However it isn't a direct substitution (also I can't figure out how to write tools for an automatic replacement) and there are thousands of uses. At this point I just want new code to use the new API, but not touch the old code that uses that bad API. Maybe in 20 years we have updated most code and so the last uses are not a big deal to get rid of but now it costs more than it is worth. (likely in 20 years we discover a better yet way and deprecate my now bad API).

Remember, if it was feasible to update everything I wouldn't use deprecated, I'd just update everything and delete the old thing. So deprecated is a sign that you are using this thing even though you shouldn't. The real question is how do we ensure someone doesn't see the deprecated thing, decide it does what they want and they never find the better way. By having a find grained suppress the next deprecated things at least reviewers will see if you used it and can discuss if that is really the right thing to do.