On 09.07.2016 at 10:18, Leigh wrote: > On Sat, 9 Jul 2016 at 08:48 Pierre Joye <pierre....@gmail.com> wrote: > >> So, I voted no then as it is clear that you do not see a problem to >> break codes without a single warning or time to adapt before. >> >> The other sections are fine and voted yes. > > For the part where you voted no. Still nobody has presented (publicly > available) source that makes legitimate use of mt_srand (yes it's mt_srand > that is "broken" here, not mt_rand) for deterministic streams of random > numbers. I can only assume by this that almost nobody does. However, for > those that do, they can still use the old algorithm. > > For all of the other sections where you voted yes, they are mostly bug > fixes, but all change the output of mt_rand AND more functions (without a > single warning, like you wanted). I'm not trying to encourage you to change > any votes, but I need to make sure you understand what you're voting for.
Thanks, Leigh, for the RFC. In my opinion, all sections except "Alias rand() to mt_rand()" and maybe "Make array_rand() more efficient" are *bug* *fixes*, and even though they might cause BC breaks, deploying them with a minor release seems to be a sensible compromise. Aliasing rand() to mt_rand() should better be postponed to PHP 8.0 (if at all). I'm aware of rand()'s limitations and platform specific behavior, but I'd prefer to leave the choice to nonetheless use it to userland (at least for now). I would suggest to improve the documentation of rand() wrt. to the note in the description section and the warning in the notes section (which are mutually contradicting themselves). Assuming that "Make array_rand() more efficient" is indeed only about performance (and not about fixes for the broken implementation), it wouldn't be a bug fix, but as array_rand()'s behavior would change anyway as noted by the RFC, it makes sense to do it as well. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
