On Friday 15 November 2024 08:16:07 Mountain Standard Time Henry Miller via
Std-Proposals wrote:
> I want a suppress this deprecation attribute. Not a suppress all, but
> suppress this one "expression" (could even be line, or next line - I leave
> that to compiler writers to figure out). The point is I know I'm using
> something deprecated, if it wasn't too much bother I'd update this line of
> code to not use the deprecated thing in the first place and delete the
> deprecated API (assume unlike Thiago I don't have external uses of this API
> that I've made a promise to). When there are thousands of uses of some API
> that works but isn't how you would do things with current C++ it isn't
> worth the time to update everything, but you still want to stop new uses of
> that old thing.

I still think that's overkill and unwarranted use. I would recommend on
focusing on a basic functionality and then we can look at what needs
expanding, later.

Again from experience, deprecations don't happen all the time. If you're using
a library that is constantly deprecating things, you should question the
quality of that library in the first place, of the procedures adopted there,
and of their API reviews. During the last Qt Contributors' Summit, we had a
discussion on this and even the little we've deprecated was considered noisy
and troublesome by our users. See https://wiki.qt.io/QtCS2024_Deprecate

I could see fine-grained ignoring being useful, but right now we have no
experience to draw upon. I'd encourage some vendor experience first. For
example, I could see a mode where given deprecation is ignored wholesale
throughout a project by way of a command-line switch that disables it based on
the file name and line number where that declaration is located, and I don't
see a path to this ever becoming part of the standard.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering