Thank you. I'm convinced for the most part. I will probably have to separate this into a separate RFC. I'd like to remove the existing reference to `mt_rand()` from this RFC, and not include the BC break.
Regards, Go Kudo 2021年5月20日(木) 17:46 Rowan Tommins <rowan.coll...@gmail.com>: > On 20/05/2021 05:59, Go Kudo wrote: > > Thanks. > > > > Deprecation will be done only to prevent unintended MT state dependent > > code. We don't plan to go as far as removing the implementation for now. > > > I think every deprecation notice should mean a plan to remove. If you > just want to encourage people to discover the new functions, I'm not > sure a message in their logs every time mt_srand runs is the right way > to do it. > > > > > Firstly, making these functions independent of mt_srand() is a > > breaking change, so cannot happen until PHP 9.0 at the earliest. > > > > To be honest, I don't understand how far PHP is willing to go to > > accept disruptive changes. > > > The official policy is here: https://wiki.php.net/rfc/releaseprocess It > relies on the phrase "backwards compatibility", which is admittedly > quite hard to define. > > You are right that the change from using rand() to using mt_rand() in > 7.1 is arguably not backwards compatible. However, the following code > can be used to reproducibly shuffle two arrays in any version of PHP: > > srand(123456); > shuffle($array1); > shuffle($array2); > > The exact sequence returned will be different in 7.1 from 7.0, but > because srand() is now an alias of mt_srand(), it still affects the > shuffle() function in the expected way. If we switch shuffle() to an > algorithm that can't be seeded at all, this code will simply stop > working, and have to be completely rewritten. > > A "polyfill" of sorts is possible, by storing an instance of the new > RNG\Randomizer in a global or static variable, but it's more than just a > find-and-replace, especially since many users will need to support > version 8.0 and 8.1 in the same code base. > > As I said previously, I'm not convinced these functions need to stop > using the MT algorithm at all, and certainly see no reason to rush the > change. > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
