Hi On 7/27/24 13:24, Christoph M. Becker wrote:
Hmm, such soft deprecations should be a good thing, but I'm afraid they are not really reaching much of the user base. Remember ext/mysql? That was soft deprecated for "centuries", but still support channels were burning when it actually had been deprecated, and even after it had been removed. (interestingly <https://pecl.php.net/package/mysql> still says the package would have been moved to <http://php.net/mysql>)
What prevented me personally from adding a "soft deprecation" to the documentation is, that the function is not actually deprecated and not slated for deprecation. It is not up to me to decide to soft deprecate something.
And regarding your remark of not reaching folks, I agree. uniqid()'s documentation is already full of warnings, but folks still reach for it.
Maybe, just maybe, it might be a good idea to repurpose E_STRICT for such things. Basically a three step deprecation: first document that a feature is obsolete, then trigger E_STRICT, and only then E_DEPRECATED. I haven't really thought this through, though.
I've proposed a deprecation instead of any other error level, because it is the least severe error level we have available: Libraries and Frameworks nowadays generally understand that deprecations are not hard errors and thus do not convert these to exceptions, but instead just direct them to a different log file / show them in the framework's debugging toolkit.
Best regards Tim Düsterhus
