On Fri, Nov 15, 2024, at 09:28, Thiago Macieira via Std-Proposals wrote:
> 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.

We have [[deprecated]] already. However there is no way to say "I know this is deprecated but I'm using it anyway for reasons". If such reasons didn't exist the function wouldn't be deprecated it would have been deleted. Having attempted to use deprecated in my own code I've given up because of lack of an easy way to express this.

> 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 agree they don't happen often, and are really annoying to users when they do. However I still have a lot of C++98 style APIs and even when I add a new modern C++ alternative people use the C++98 version. I need a good way to stop them and so far I haven't found one that doesn't cost me thousands of hours to update all old uses so I can delete the old API.

> 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.

I fully agree we need experience to draw on. I hope anyone who proposes something has used it in something enough to have confidence it works. I can tell you that [[deprecated]] isn't useful for me today because the current control I have isn't powerful enough. I can't tell you if any particular solution will work for me though. (you will note that I requested both find grained control and a tool that will go mark all existing uses as okay - I believe that manually adding fine grained annotation takes to long to be acceptable)

I believe that line numbers won't work as eventually someone will go into a file and add/delete one line (or even move lines around) and now your suppression is wrong. Putting them in code gives much higher chances that such changes don't break your suppression. Putting them in code also means that if someone is touching that area of code anyway they are given notice that maybe they should update to the new way while they are in there anyway. However I haven't used this proposed method so maybe it isn't as bad as it looks to me - do you have experience with it or are you speculating just as much as me?