Il 15/11/2024 18:23, Henry Miller via Std-Proposals ha scritto:
> 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.

I agree with Thiago that a way, possibly with an attribute, of generally
suppressing the deprecation diagnostic in a specific region of code (be
it a statement or a scope) can be useful. However, I also agree that we
should design the feature in such a way that it can be expanded to allow
a more fine-grained control.

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


We do have some experience to draw on. Someone already mentioned lint,
but also clang-tidy has a very precise way to silence undesired
diagnostic
https://clang.llvm.org/extra/clang-tidy/#suppressing-undesired-diagnostics
. It's a pity that clang-tidy followed the lint way of using comments,
instead of trying attributes. For example, clang-tidy use this:


class Foo {
   // Suppress all the diagnostics for the line
   Foo(int param); // NOLINT
};

which could have been written, for example

class Foo {
   // Suppress all the diagnostics for the line
   [[clangtidy::NOLINT]] Foo(int param);
};

Notice that clang-tidy use a tag system not dissimilar to what I
proposed in my OP:

   Foo(double param); // NOLINT(google-explicit-constructor,
google-runtime-int)

where the tags are "google-explicit-constructor" and
"google-runtime-int". Notice that clang-tidy can suppress diagnostic in
bulk using wildcards, for example "google-*" would match all diagostics
with a "google-" prefix.

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

In my opinion, line numbers won't work. A tag system like clang-tidy is
definitely more powerful, expressive and less prone to breakage. Maybe
we could use structured tags, for example in the form "A.B.C", something
that could be both simple enough and provide a framework for different
vendors to avoid tag clashes.

Just my two eurocent,

ab