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

Reply via email to