Re: RFC proposal to deprecate crypt()
| From: | Tim Düsterhus | Date: | Mon, 21 Feb 2022 11:39:34 +0000 |
| Subject: | Re: RFC proposal to deprecate crypt() | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117092@lists.php.net to get a copy of this message | ||
Hi
On 2/21/22 12:12, Marco Pivetta wrote:
I understand that that's the point. However I agree with Stas that this would be a BC break with no practical gain and I articulated the reasons why I believe that: If crypt() is what you need, then crypt() is what you need and being told that your use-case is invalid is not helping you. The function already exists and I assume that it does not require (relevant) maintenance effort for PHP maintainers keeping it. With the same arguments one could deprecate and remove md5() (and possibly sha1() as well). It should not be used for passwords, it should not be used for signatures and any new use should require *careful* review. Nonetheless there are cases where you still need an implementation of md5() and then not having md5() is an issue. If someone proposed the removal of md5() I'd disagree the same. Best regards Tim Düsterhus...yes? That's the point?In contrast to other deprecations (e.g. the utf8_encode/decode currently discussed), deprecating and ultimately removing crypt() results in an actual loss of functionality.If it's not going to be removed, what's the point of annoying people with deprecation warnings (that they would patch out/silence anyway)?Probably to be removed in9.0or10.0? Yes, it should be removed at some point.