Re: drop deprecation markers?

On 4/22/25 11:55 PM, Daniel Stenberg via curl-library wrote:
> Hello team,
Hi Daniel,
>
> Someone on IRC pointed out that the typecheck-gcc checks don't work 
> anymore. I could reproduce and I started to fix them. I have a PR 
> pending.
>
> These typechecks warning outputs get pretty damaged by the deprecation 
> warnings, because they include checks for deprecated options.
The initial code did take care of it successfully. What has changed 
since then?
>
> This made me realize that I don't think our deprecation warnings do a 
> lot of good and that they mostly just annoy me when I run into them.
"Annoying" people using these options (not you particularly!) was one of 
the goal: this forces them to see something is bad even if they don't 
read the doc, as this is the case very often. Code conversion is expected.
> We added them in November 2022 (shipped with 7.87.0) and I was 
> certainly in favor of them. I just think I over time have come to not 
> like them very much anymore.
>
> They also mark a lot of differently deprecated options, so they are 
> used on options that no longer have functionality as well as options 
> that just are recommended to not get used. All while our ABI and API 
> promise that we will not take them away - disambiguous.
To each deprecation is associated an explanation text that could be 
changed if not satisfactory.

API/ABI are guaranteed not to go away. However they often return an 
error at run-time (that many calling sequences ignore), if ever 
executed. You won't miss ANY of them with a compile-time detection, 
providing the option is a constant.

In addition, warnings help us checking deprecations consistency in the 
doc files (test 1222).

I coded this after a nth people not reading the doc asked a question 
and/or change about a long-deprecated option/function: I'm afraid to say 
I consider this is causing a waste of energy on our side and I wanted to 
reduce this. In example, see mail thread starting at 
https://curl.se/mail/lib-2024-01/0068.html (and yes, it's even after 
deprecation warnings were released, but I don't know what curl, OS and 
compiler versions were used). With warnings, non-doc-reading people 
can't pretend they are not aware of a particular deprecation. I did not 
perform statistics, but my feeling is it did reduce this kind of PM tasks.

If you effectively remove these warnings, an alternative (but 
incomplete) solution would be to have a page about deprecated 
options/functions on the web site, so we can simply reply to such 
questions/requests by a link to this page and close the issue. Just an idea.

For all the above reasons, -1 for the removal.

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html