hi, On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > >> I would prefer something like random_fast_int() == mt_rand() == rand(), >> with clear documentation on when to use random_fast_int() instead of >> random_int(), and a note on the others that "since 7.2, mt_rand() is an >> alias for random_fast_int()" etc. (Not wedded to the name >> random_fast_int, we can bikeshed that later.) > > That sounds to me like a good way to proceed too. I don't think it's a > big deal it mt_rand won't be using specific MT algorithm anymore, I see > very small number of places where it would matter. > > One thing to consider is that there might be test scenarios, sequences, > etc. that depend on specific seed and will be broken by changing the > implementation (tests relying on specific rand are not the very best > idea, but they do happen), but I think this kind of thing may be > acceptable for a major version. Would like to hear thoughts on this though.
fast_int or fast whatever looks bad to me. But we know that. Also, about mt_rand, it costs nothing to have a compat mode for the cases where the current (standard or not is not relevant) implementation is being relied on. More generally about the random APIs, there are many good non crypto safe RNGs, and there will be more. Each of them have their own use cases. I do not think that arbitrary choose, change, actualized them, in major versions or not, is a good thing. I would rather prefer to have a more flexible API allowing to choose one algorithm for a run. It is also good to have a default per category (strong, weak, fast for example) so one can use the current default for a given need. A good API for RNG is https://bitbucket.org/haypo/hachoir/wiki/Home. It allows flexibility while having default and the ability to choose a specific implementation if desired. My main point is to do not penalize valid uses because some code will never ever do the right thing (tm). A language cannot prevent bad behaviors but do not have to punish good cases by removing useful features for the "good of all". Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
