Re: [RFC] [Discussion] PHP 8.3 deprecations

2023年5月30日(火) 0:42 Nikita Popov <nikita.ppv@gmail.com>: > On Mon, May 29, 2023, at 08:05, Máté Kocsis wrote: > > Hi Everyone, > > > > Together with multiple authors, we'd like to start the discussion of the > > usual > > deprecation RFC for the subsequent PHP version. You can find the link > below: > > https://wiki.php.net/rfc/deprecations_php_8_3 > > > > Regards: > > Máté Kocsis > > I don't think we should deprecate mt_rand(). > > There are plenty of use-cases that require neither a seedable > (predictable) RNG sequence, nor a cryptographically-secure RNG. For those > use-cases (and especially one-off uses), mt_rand() is perfect, and going > through Randomizer is an entirely unnecessary complication. > > I think I could get on board with deprecating srand/mt_srand to make > rand/mt_rand non-seedable, directing people who need a seedable RNG to use > Randomizer, which is much better suited to that use-case. However, we > should retain rand/mt_rand themselves for non-seeded use-cases. > > With srand/mt_srand removed, we also would not have to produce any > particular sequence, and would be free to switch the internal RNG to > something other than Mt19937. > > The same extends to array_rand(), shuffle() and str_shuffle() -- in fact > the RFC is missing an important voting option, which is "leave them alone", > or rather "convert to some non-seedable non-CSPRNG" if you prefer. > > Regards, > Nikita +1 I too feel that the Randomizer is overkill for many applications. However, I believe that there is a suitable alternative to mt_rand() / rand() : random_int() It probably makes the most sense to use it. On the other hand, there is no suitable alternative for lcg_value(). The simpler Randomizer::getFloat() would be fine, but on the other hand, floating-point random numbers are very hard to handle, so some say that the Randomizer class should be used. I would like to hear your opinion on this. Best Regards, Go Kudo