Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: drop deprecation markers?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 23 Apr 2025 02:14:56 +0200
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.
Date: Wed, 23 Apr 2025 02:14:56 +0200
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.htmlReceived on 2025-04-23