Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114531
MIME-Version: 1.0
References: <CABTDVhAd8r_OPsdbzxrFeZTZEHuZjKyPfcYhNcdfdSZWbUJ-Lw@mail.gmail.com>
 <72767cd7-ffc5-c84b-523c-123ff6ef30fa@gmail.com> <CABTDVhBD_D-UF-c6=5sce=p8QsOaFZ36jK1cgz9Gy0SW3JrF2g@mail.gmail.com>
 <d1611452-e061-bbac-3ebe-e1d65e521546@gmail.com>
In-Reply-To: <d1611452-e061-bbac-3ebe-e1d65e521546@gmail.com>
Date: Thu, 20 May 2021 21:46:38 +0900
Message-ID: <CABTDVhC-aC6fz2807TnZ_PKpmE5iCN3QsvDay0GUdOdm9b=oZA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000036215d05c2c256a6"
Subject: Re: [PHP-DEV] [RFC] [Draft] Add RNG extension and deprecate mt_srand()
From: zeriyoshi@gmail.com (Go Kudo)

--00000000000036215d05c2c256a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E5=B9=B45=E6=9C=8820=E6=97=A5(=E6=9C=A8) 17:46 Rowan Tommins <rowan.co=
llins@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
>
>

--00000000000036215d05c2c256a6--