Date: Fri, 15 Nov 2024 09:16:07 -0600
On Thu, Nov 14, 2024, at 03:54, Alberto Barbati via Std-Proposals wrote:
> Il 13/11/2024 17:52, Arthur O'Dwyer ha scritto:
>> On Wed, Nov 13, 2024 at 3:32 AM Alberto Barbati via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>
>> There is only one (theoretical?) problem with this solution: It's not
>> fine-grained enough. It suppresses the warning about `f1`, yes, but it
>> /also/ suppresses the warning about `f2`.
>> What you're actually asking from the toolchain is a way to "whitelist"
>> certain names — to say "I know I'm deliberately using /these/
>> deprecated facilities, but please warn me about any /others/ I'm using
>> accidentally."
>
> Yes, I proposed something more fine grained, but Thiago made a good
> point that this might be too much. Maybe having a simple "suppress all
> deprecation" attribute can be enough. We can discuss this.
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.
What I really want (but not enough to write the paper) is a suppress this one deprecated expression attribute and then a tool that run on my entire code base that will insert that for all existing uses of something that I just deprecated. Without both of them deprecated is useless because we can't deprecate anything we just delete unused things instead.
I don't think we need a to say what we are suppressing so long as we are confident that the suppression applies to one or a few things and so it is easy enough to figure out.
> Il 13/11/2024 17:52, Arthur O'Dwyer ha scritto:
>> On Wed, Nov 13, 2024 at 3:32 AM Alberto Barbati via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>
>> There is only one (theoretical?) problem with this solution: It's not
>> fine-grained enough. It suppresses the warning about `f1`, yes, but it
>> /also/ suppresses the warning about `f2`.
>> What you're actually asking from the toolchain is a way to "whitelist"
>> certain names — to say "I know I'm deliberately using /these/
>> deprecated facilities, but please warn me about any /others/ I'm using
>> accidentally."
>
> Yes, I proposed something more fine grained, but Thiago made a good
> point that this might be too much. Maybe having a simple "suppress all
> deprecation" attribute can be enough. We can discuss this.
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.
What I really want (but not enough to write the paper) is a suppress this one deprecated expression attribute and then a tool that run on my entire code base that will insert that for all existing uses of something that I just deprecated. Without both of them deprecated is useless because we can't deprecate anything we just delete unused things instead.
I don't think we need a to say what we are suppressing so long as we are confident that the suppression applies to one or a few things and so it is easy enough to figure out.
Received on 2024-11-15 15:16:31