Hey Gina, Tim, I agree with most of these deprecations, except:
* `uniqid()`, in my case (XKCD 1172) is largely used for quickly generating a semi-random string for test purposes: a suitable replacement PRNG implementation would be welcome. Even refactoring with tools like Rector will lead to quite messy code, or added dependencies. IMO fine to get rid of **this specific implementation**, if a safe function is provided, such as `random_ascii_string()` or such (dunno, just a hint) * `md5()`, `sha1()` - OK-ish with moving to `hash('<algo>', ...)`, but while these are insecure for most use-cases, they are part of the domain of many tools, including GIT itself. I can Rector my way out of it, just not sure these should be hidden into `hash(...)` That said, welcome changes :-) Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/ On Tue, 25 Jun 2024 at 16:37, Gina P. Banyard <intern...@gpb.moe> wrote: > Hello internals, > > It is this time of year again where we proposed a list of deprecations to > add in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > > As a reminder, this list has been compiled over the course of the past > year by various different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time buffer, so if anyone else has any suggestions, > they are free to add them to the RFC. > > Some should be non-controversial, others a bit more. > If such, they might warrant their own dedicated RFC, or be dropped from > the proposal altogether. > > > Best regards, > > Gina P. Banyard >