Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Aleksander Machniak]

On 26.06.2023 20:22, Ben Ramsey wrote:


I voted “no” on `IntlCalendar::set()` because it seems to me that `setDate()` 
and `setDateTime()` could share the same signature if `$hour`, `$minute`, and 
`$second` all default to zero, like this:

 public function setDate(int $year, int $month, int $dayOfMonth, int $hour 
= 0, int $minute = 0, int $second = 0): void {}

In the same way, with `IntlGregorianCalendar::__construct()`, 
`createFromDate()` and `createFromDateTime()` could be combined as:

 public static function createFromDate(int $year, int $month, int 
$dayOfMonth, int $hour = 0, int $minute = 0, int $second = 0): void {}


I also voted No on IntlCalendar and IntlGregorianCalendar changes. The 
proposed solution is not good enough.


IntlGregorianCalendar has already a static fromDateTime() method 
inherited from IntlCalendar, so a new method is not needed, imo.


Also, setTime() method already exists (not the best name), so addition 
of setDate() and setDateTime() will make it worse.


--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Theodore Brown]

On Mon, June 26, 2023, at 14:43 Nikita Popov wrote:
> On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:
> >
> > I voted “no” on `array_keys()` because I do not see these as two different 
> > function signatures. To me, the single signature should look like this:
> >
> > function array_keys(array $array, ?mixed $filter_value = null, bool 
> > $strict = false): array {}
> >
> > I voted “no” on `IntlCalendar::set()` because it seems to me that 
> > `setDate()` and `setDateTime()` could share the same signature if `$hour`, 
> > `$minute`, and `$second` all default to zero, like this:
> >
> > public function setDate(int $year, int $month, int $dayOfMonth, int 
> > $hour = 0, int $minute = 0, int $second = 0): void {}
> >
> > In the same way, with `IntlGregorianCalendar::__construct()`, 
> > `createFromDate()` and `createFromDateTime()` could be combined as:
> >
> > public static function createFromDate(int $year, int $month, int 
> > $dayOfMonth, int $hour = 0, int $minute = 0, int $second = 0): void {}
> 
> So commonality here is that these are all arity overloads.
> 
> I think there's three different kinds of overloads in involved in the RFC:
> 
> 1. static/non-static overloads. Support for this was dropped in PHP 8, but 
> had to be retained internally just for that one usage in FII, so getting rid 
> of that seems quite high value.
> 
> 2. type/meaning overloads, where certain parameters change meaning entirely 
> across overloads. These are incompatible with named parameters and result in 
> very unclear function signatures. They only become intelligible once split 
> into separate signatures, which is not something PHP supports. Removing these 
> is also fairly high value.
> 
> 3. arity overloads, where behavior depends on number of parameters, or 
> certain parameter counts are forbidden, but the actual meaning of the 
> parameters does not change. Equivalent to a func_num_args() check in userland 
> code. I think these arity overloads are pretty harmless. The function 
> signature is meaningful and compatible with named arguments.
> 
> My overall inclination here is to vote No on all the deprecations that 
> involve arity overloads and vote Yes on the remainder.
> 
> Possibly I'm missing some kind of complication that the arity overloads are 
> causing?


Currently the following code returns only the array keys that loosely equal 
null [1]:

array_keys($array, null)

If the function is changed to a single signature with $filter_value defaulting 
to null (with an argument count check to preserve the above functionality), its 
behavior becomes a lot more surprising/unexpected. If a parameter defaults to 
null, as a user I don't expect the function to work differently when I 
explicitly pass the default value.

To prevent confusion, the function would at least still need to be documented 
with two separate signatures in the PHP manual, which goes against one of the 
RFC goals of automatically updating signatures based on stubs.

So from my perspective there is value in deprecating arity overloads: it avoids 
confusing behavior changes and the need to manually keep the overloaded 
signatures documented and in sync in the manual.

Regards,
Theodore

[1]: https://3v4l.org/Sld4S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

[G. P. B.]

On Tue, 17 Jan 2023 at 14:28, G. P. B.  wrote:

> Hello Internals,
>
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> The goal of this RFC is to reduce language complexity by making $v++
> behave like $v += 1 and $v-- behave like $v -= 1;
>
> I am expecting the contentious part of the proposal to be the deprecation
> of the PERL string increment feature to achieve the aforementioned goal.
> However, I believe the benefits of aligning the behaviour of the
> increment/decrement operators with addition/subtraction are larger than
> keeping support for the PERL increment, which in its current state has
> various shortcomings.
>

I have added a section about impact on the PERL increment deprecation to
the RFC.
https://wiki.php.net/rfc/saner-inc-dec-operators

I am also planning on opening the vote on this on Wednesday the 28th of
June.

Best regards,

George P. Banyard

Re: [PHP-DEV] RFC [Concept] - Interface Properties

[Mike Schinkel]

With "Interface Default Methods" potentially becoming a thing, it begs the 
question for the need to have Interface Properties, at least `private` ones and 
`private static` ones. 

How can we have default getters and default setters in an interface if there 
are no private interface properties to get or set? Ignoring special cases, that 
is.

Of course if the RFC for "Interface Default Methods" fails to pass then this 
point is moot.

-Mike

> On May 28, 2023, at 1:51 PM, Erick de Azevedo Lima  
> wrote:
> 
> As others have said: the interface/contract makes available public stuff
> that is what the implementers will make available. So it should not matter
> if those are methods or properties.
> In the case of a public property, the difference from the method-only
> approach is that it's already implicit that the read and write operations
> are available (for non-readonly properties, of course).
> I like it. It can eliminate a lot of boilerplate and make things more
> obvious to the final user of the class that implements the interface.
> 
> --
> Erick
> 
> Em dom., 28 de mai. de 2023 às 14:37, David Gebler 
> escreveu:
> 
>> On Sun, May 28, 2023 at 5:03 PM Larry Garfield 
>> wrote:
>> 
>>> On another level, I'd redefine properties and methods slightly.  (Public)
>>> Properties are not "raw data" but "aspects of the object I can
>> manipulate"
>>> and methods are "behaviors I can ask the object to perform."
>>> 
>> 
>> I just wanted to pull out this sentence in particular because I think it's
>> very much true of the property hooks RFC where you can attach behaviours to
>> what are from the outside accessed as if they were fields - and yes
>> properties on interfaces makes at least more sense in that case...but I
>> don't think it's true of the RFC Nick is proposing, which would very much
>> allow interface designs where a property is simply a (maybe typed) public
>> property and does represent a "raw data" value.
>> 
>> I suppose the difficulty for me is that I appreciate "people could abuse
>> it" isn't a reason in itself to exclude a feature, where it could prove
>> useful in a non-abusive way. But languages have ecosystems and frameworks
>> and conventions and idioms around them which go beyond what the language
>> strictly does and doesn't permit. People who like Laravel will say you can
>> write poor PHP code in any framework and good PHP code in Laravel, and
>> they're right, but personally I'd argue Laravel encourages you to write PHP
>> code in a way which is commonly and conventionally considered to not be a
>> best practice. And I don't like it very much for that reason. It's the same
>> for me with properties on interfaces; I think it will encourage people to
>> do things that some of the conventional wisdom out there says they probably
>> shouldn't.
>> 
>> Anyway, apologies I'm not replying in depth to your comments; I'm just wary
>> of descending into a philosophical wayside about principles of programming
>> and "best practices". And my views on those things are probably quite
>> anodyne, but the margin for difference in good opinions is more than enough
>> that I don't want to go there.
>> 
>> -Dave
>> 
>> On Sun, May 28, 2023 at 5:03 PM Larry Garfield 
>> wrote:
>> 
>>> On Sun, May 28, 2023, at 6:52 AM, David Gebler wrote:
 On Sun, May 28, 2023 at 10:33 AM Rowan Tommins <
>> rowan.coll...@gmail.com>
 wrote:
 
> I don't follow. If a property is public, then code outside the class
>> can
> rely on being able to access it. That seems to me to be a contract
>>> between
> the class and its users, not an implementation detail - e.g. removing
>>> the
> property, or changing its type, would be a compatibility break. A
>>> property
> can also be inherited from a base class, at which point there is a
>>> contract
> that all descendants of that base class will have the property
>>> available.
> So it seems logical that that contract could also be included in an
> interface.
> 
> 
 That's why you can declare constants in an interface (a static final
 property, to use the lexicon of Java) which we can already do in PHP.
>> At
 the point you want to bring mutable state into an interface, it's a
>>> design
 smell that what you want, really, is an abstract class or perhaps
 composition.
>>> 
>>> Almost never is an abstract class what you want, frankly.  An abstract
>>> class unnecessarily conflates "is a special case of" and "reuses code
>> from"
>>> into a single syntax.  "Making one thing do two things" is a design flaw
>> in
>>> most of computer science, and one that PHP has been bitten by multiple
>>> times.
>>> 
>>> cf: https://www.garfieldtech.com/blog/beyond-abstract
>>> 
 A couple of languages do allow mutable properties on interfaces,
>>> TypeScript
 being one of them, so yes it's not an unheard of feature - but in TS/JS
 it's a lot more idiomatic to directly access properties than it is in
>>> PHP.
 I'm not 

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Nikita Popov]

On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:
> > On Jun 26, 2023, at 08:36, Máté Kocsis  wrote:
> > 
> > Hi Everyone,
> > 
> > As previously announced on the list, I have just started the vote about the
> > "Deprecate functions with overloaded signatures".
> > 
> > Link to the RFC:
> > https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
> > Link to the discussion thread: https://externals.io/message/120146
> > 
> > The vote is open until 2023-07-10 16:00:00 UTC.
> > 
> > Regard,
> > Máté
> 
> 
> Clarifying my “no” votes…
> 
> I voted “no” on `array_keys()` because I do not see these as two different 
> function signatures. To me, the single signature should look like this:
> 
> function array_keys(array $array, ?mixed $filter_value = null, bool 
> $strict = false): array {}
> 
> I voted “no” on `IntlCalendar::set()` because it seems to me that `setDate()` 
> and `setDateTime()` could share the same signature if `$hour`, `$minute`, and 
> `$second` all default to zero, like this:
> 
> public function setDate(int $year, int $month, int $dayOfMonth, int $hour 
> = 0, int $minute = 0, int $second = 0): void {}
> 
> In the same way, with `IntlGregorianCalendar::__construct()`, 
> `createFromDate()` and `createFromDateTime()` could be combined as:
> 
> public static function createFromDate(int $year, int $month, int 
> $dayOfMonth, int $hour = 0, int $minute = 0, int $second = 0): void {}

So commonality here is that these are all arity overloads.

I think there's three different kinds of overloads in involved in the RFC:

1. static/non-static overloads. Support for this was dropped in PHP 8, but had 
to be retained internally just for that one usage in FII, so getting rid of 
that seems quite high value.

2. type/meaning overloads, where certain parameters change meaning entirely 
across overloads. These are incompatible with named parameters and result in 
very unclear function signatures. They only become intelligible once split into 
separate signatures, which is not something PHP supports. Removing these is 
also fairly high value.

3. arity overloads, where behavior depends on number of parameters, or certain 
parameter counts are forbidden, but the actual meaning of the parameters does 
not change. Equivalent to a func_num_args() check in userland code. I think 
these arity overloads are pretty harmless. The function signature is meaningful 
and compatible with named arguments.

My overall inclination here is to vote No on all the deprecations that involve 
arity overloads and vote Yes on the remainder.

Possibly I'm missing some kind of complication that the arity overloads are 
causing?

Regards,
Nikita

Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests

[Ben Ramsey]

> On Jun 20, 2023, at 06:06, Rowan Tommins  wrote:
> 
> On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo  wrote:
> 
>> Introduce a new function (currently named populate_post_data()) to
>> read the input stream and populate the $_POST and $_FILES
>> superglobals.
>> 
> 
> 
> My initial instinct was to discuss how this could be made more flexible in
> terms of input and output; but looking at how simple the implementation is,
> this seems like a really quick win, and anything else can be future scope.
> 
> To bikeshed the name a bit:
> 
> * We should probably avoid the word "post"; although it populates $_POST,
> that's really misnamed anyway, what we're really talking about is "form
> data"
> * Even if there isn't a current category prefix where it belongs, it should
> probably follow the "category_specific" naming scheme
> * We might in future add some related functions, such as returning the data
> rather than populating globals
> 
> How about "request_form_populate_globals"?


Another option for the name: `populate_multipart_form_data()`.

Cheers,
Ben





signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Ben Ramsey]

> On Jun 26, 2023, at 08:36, Máté Kocsis  wrote:
> 
> Hi Everyone,
> 
> As previously announced on the list, I have just started the vote about the
> "Deprecate functions with overloaded signatures".
> 
> Link to the RFC:
> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
> Link to the discussion thread: https://externals.io/message/120146
> 
> The vote is open until 2023-07-10 16:00:00 UTC.
> 
> Regard,
> Máté


Clarifying my “no” votes…

I voted “no” on `array_keys()` because I do not see these as two different 
function signatures. To me, the single signature should look like this:

function array_keys(array $array, ?mixed $filter_value = null, bool $strict 
= false): array {}

I voted “no” on `IntlCalendar::set()` because it seems to me that `setDate()` 
and `setDateTime()` could share the same signature if `$hour`, `$minute`, and 
`$second` all default to zero, like this:

public function setDate(int $year, int $month, int $dayOfMonth, int $hour = 
0, int $minute = 0, int $second = 0): void {}

In the same way, with `IntlGregorianCalendar::__construct()`, 
`createFromDate()` and `createFromDateTime()` could be combined as:

public static function createFromDate(int $year, int $month, int 
$dayOfMonth, int $hour = 0, int $minute = 0, int $second = 0): void {}


Cheers,
Ben




signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

On Tue, Jun 20, 2023 at 9:46 PM Levi Morrison  wrote:
>
> On Tue, Jun 20, 2023 at 6:29 AM David Gebler  wrote:
> >
> > On Tue, 20 Jun 2023, 04:10 Levi Morrison,  wrote:
> >
> > > > I like the idea of this RFC - in fact it's one which has been near top 
> > > > of
> > > > my wishlist for PHP language features for a long time - but I think this
> > > is
> > > > an issue with the proposed implementation which at the very least
> > > warrants
> > > > highlighting and discussion.
> > >
> > > I understand your concern but personally believe it's overblown. This
> > > problem already exists with abstract classes, but doesn't seem to be
> > > that much of an issue in practice. I hope static analysis can fill the
> > > gap here, but don't think these checks are necessary to ship this
> > > feature.
> > >
> >
> >
> > Yeah I suppose I'm just saying "Interface default methods" can be
> > interpreted a few different ways and there's key differences between
> > Java-style, versus syntax sugar for mixing an interface and a trait in to
> > one unit, versus a user can effectively extend multiple abstract classes
> > but with interface keyword.
>
> I will update the RFC soon. In my head it was so obvious that it would
> be similar to regular inheritance and less like traits, to the extent
> I didn't even realize I'd need to specify it. This is why discussion
> periods can be valuable; the RFC doesn't always say what's in the RFC
> author's head :)


I have significantly updated the RFC. There's one more topic that
needs to go in there, tentatively called 'default cancelling':

```php
interface Interface1 { function m1() { /* ... */ } }
interface Interface2 extends Interface1 {
function m1(); // may or may not change signature
}
```

For various reasons which I'll put in the RFC, this will "cancel" the
default, meaning any class which implements Interface2 instead of
Interface1 will not receive that default.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] PHP 8.3 deprecations

[Larry Garfield]

On Mon, Jun 26, 2023, at 6:45 AM, Go Kudo wrote:
> 2023年6月24日(土) 22:56 Nikita Popov :
>
>> On Thu, Jun 22, 2023, at 12:14, Máté Kocsis wrote:
>> > Hi Everyone,
>> >
>> > As previously announced on the list, we have just started the vote about
>> > the annual PHP deprecation RFC.
>> >
>> > Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3
>> > Link to the discussion thread: https://externals.io/message/120422
>> >
>> > The vote is open until 2023-07-06 12:00:00 UTC.
>>
>> I've voted No on the mt_rand() deprecation proposal. This is a high impact
>> deprecation without sufficient justification.
>>
>> I believe this proposal would have been much better served deprecating
>> only the srand() and mt_srand() functions, as I previously suggested. Going
>> through the arguments against mt_rand() in the RFC:
>> > They are not cryptographically secure.
>>
>> This is a feature, not a bug. Not everything needs or wants
>> cryptographically secure random numbers. There's a reason we support both.
>>
>> > They are not properly reproducible, because the state could be changed
>> unpredictably by any function call, e.g. when a library is updated and adds
>> additional calls to `mt_rand ()`.
>>
>> This is addressed by deprecating mt_srand() only, making Randomizer the
>> only way to get reproducible random number sequences, and relegating
>> mt_rand() to only the cases where reproducibility is not required.
>>
>> > Any function calling `mt_srand ()` with a
>> fixed seed for whatever reason, will ruin randomness for the remainder of
>> the request.
>>
>> Deprecating (and removing) mt_srand() address this one trivially.
>>
>> > PHP's Mt19937 implementation only supports passing a single 32 bit
>> integer as the initial seed. Thus there are only ~4 billion possible
>> sequences of random integers generated by Mt19937. If a random seed is
>> used, collisions are expected with 50% probability after roughly 2**16
>> seeds (as per the birthday paradox). In other words: After roughly 8
>> requests without explicit seeding it is likely that a seed and thus a
>> sequence is reused.
>>
>> Deprecating (and removing) allows us to address this as well, as we are no
>> longer bound to a specific PRNG algorithm or seeding procedure.
>>
>> > Both the quality of the returned randomness as well as the generation
>> performance of Mt19937 is worse than that of the Xoshiro256StarStar and
>> PcgOneseq128XslRr64 engines that are provided in the object-oriented API.
>>
>> Same as previous point: If we don't allow seeding we can change the
>> algorithm however we like.
>>
>> > They are functions with overloaded signatures <
>> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures>,
>> which are problematic for the reasons outlined in the “Deprecate functions
>> with overloaded signatures <
>> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures>”
>> RFC.
>>
>> While this is technically true, the particular overload in question here
>> is a very mild and unproblematic one. It only enforces that the function is
>> called with zero or two arguments, forbidding one argument. It does not
>> require accepting different combinations of argument types, or change the
>> meaning of arguments, which is what makes overloads problematic.
>>
>>
>> I think the only somewhat sound motivation for this deprecation is that
>> programmers may use the non-cryptographic mt_rand() in a context where
>> cryptographic numbers are required. This is a legitimate concern, but I
>> don't think it's sufficient to deprecate such a widely used function.
>>
>> For the longest time, we only had mt_rand(), and no easy access to a
>> CRPRNG. A lot of mt_rand() misuse dates back to that time. Since the
>> introduction of random_int() and random_string(), getting cryptographic
>> randomness is no harder than getting non-cryptographic randomness (easier,
>> in the case of strings).
>>
>> Regards,
>> Nikita
>
>
> Hi.
>
> Thank you for your valuable input. I would like to ask you a few questions.
>
> I think you are right that deprecating `srand()` / `mt_srand()` achieves
> the goal of making it unavailable for reproducible uses. But why keep the
> function name `mt_rand()`?
>
> It is certainly true that by prohibiting seeding, the PRNG algorithm can be
> modified at will. But then the `mt` in `mt_rand()` would be out of touch
> with reality. If this is done merely to maintain code compatibility, then
> it is not a good idea to keep naming only for compatibility.
>
> Also, `mt_rand()` has the problem of depending on the global state of the
> PHP VM. This is very dangerous in forked use cases such as Swoole, where
> implicitly seeded random numbers can return the exact same result in the
> post-fork process. To avoid this, the sequence must be reseeded again after
> the fork is executed. If only `srand()` / `mt_srand()` is deprecated, this
> cannot be avoided.
>
> The only way 

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

[G. P. B.]

On Wed, 31 May 2023 at 13:08, G. P. B.  wrote:

> Hello internals,
>
> I would like to start the discussion about deprecating various remains
> from the now removed string code evaluated assertions functionality of
> assert().
>
> The RFC is located on the wiki at the following address:
> https://wiki.php.net/rfc/assert-string-eval-cleanup
>
> Initially, this was part of the mass PHP 8.3 deprecation RFC, but only the
> assert_options() function was part of it.
>

Head's up, I'm planning on opening the vote on this on Wednesday the 28th
of June.

Best regards,

George P. Banyard

>

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

[G. P. B.]

On Wed, 31 May 2023 at 23:20, Claude Pache  wrote:

> Although your RFC says that the `zend.assertions` ini setting has
> superseded `assert.active` for a while, the “official” php.ini file still
> advises to modify the value of `assert.active` rather than the one of
> `zend.assertion` in order to switch behaviour at runtime:
>
>
> https://github.com/php/php-src/blob/91fd5641cde138b8894a48c921929b6e4abd5c97/php.ini-development#L1604
>
> I bet that many people (myself included) follows the advice given in
> `php.ini`.
>

This talks about run-time modification, which is something that I don't
think should be done in practice, nor is often done.


> Another point: Your RFC is missing `assert.quiet_eval`...
>

I have clarified that this was indeed removed in PHP 8.0.
https://wiki.php.net/rfc/assert-string-eval-cleanup

Best regards,

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Marco Pivetta]

Hey Máté,

Only voted "NO" for `ReflectionProperty#setValue()`, mostly because any
kind of pre-existing subtype will be kinda broken, but it isn't a major
issue.

It's fine if libraries drop support for PHP 8.2 before PHP 9.0 is out.

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/


On Mon, 26 Jun 2023 at 15:37, Máté Kocsis  wrote:

> Hi Everyone,
>
> As previously announced on the list, I have just started the vote about the
> "Deprecate functions with overloaded signatures".
>
> Link to the RFC:
> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
> Link to the discussion thread: https://externals.io/message/120146
>
> The vote is open until 2023-07-10 16:00:00 UTC.
>
> Regard,
> Máté
>

[PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Máté Kocsis]

Hi Everyone,

As previously announced on the list, I have just started the vote about the
"Deprecate functions with overloaded signatures".

Link to the RFC:
https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
Link to the discussion thread: https://externals.io/message/120146

The vote is open until 2023-07-10 16:00:00 UTC.

Regard,
Máté

Re: [PHP-DEV] Request to create a RFC for const args

[Ilija Tovilo]

Hi Sam!

> Hello php internals team,
> I would like to put forward an RFC for a new feature. I am a long time user, 
> but have never participated as yet to the RFC.

Sorry for the late reply.

Thanks for your suggestion! If you'd like RFC karma, we'll need to
know your username on the wiki.

Ilija

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] PHP 8.3 deprecations

[Go Kudo]

2023年6月24日(土) 22:56 Nikita Popov :

> On Thu, Jun 22, 2023, at 12:14, Máté Kocsis wrote:
> > Hi Everyone,
> >
> > As previously announced on the list, we have just started the vote about
> > the annual PHP deprecation RFC.
> >
> > Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3
> > Link to the discussion thread: https://externals.io/message/120422
> >
> > The vote is open until 2023-07-06 12:00:00 UTC.
>
> I've voted No on the mt_rand() deprecation proposal. This is a high impact
> deprecation without sufficient justification.
>
> I believe this proposal would have been much better served deprecating
> only the srand() and mt_srand() functions, as I previously suggested. Going
> through the arguments against mt_rand() in the RFC:
> > They are not cryptographically secure.
>
> This is a feature, not a bug. Not everything needs or wants
> cryptographically secure random numbers. There's a reason we support both.
>
> > They are not properly reproducible, because the state could be changed
> unpredictably by any function call, e.g. when a library is updated and adds
> additional calls to `mt_rand ()`.
>
> This is addressed by deprecating mt_srand() only, making Randomizer the
> only way to get reproducible random number sequences, and relegating
> mt_rand() to only the cases where reproducibility is not required.
>
> > Any function calling `mt_srand ()` with a
> fixed seed for whatever reason, will ruin randomness for the remainder of
> the request.
>
> Deprecating (and removing) mt_srand() address this one trivially.
>
> > PHP's Mt19937 implementation only supports passing a single 32 bit
> integer as the initial seed. Thus there are only ~4 billion possible
> sequences of random integers generated by Mt19937. If a random seed is
> used, collisions are expected with 50% probability after roughly 2**16
> seeds (as per the birthday paradox). In other words: After roughly 8
> requests without explicit seeding it is likely that a seed and thus a
> sequence is reused.
>
> Deprecating (and removing) allows us to address this as well, as we are no
> longer bound to a specific PRNG algorithm or seeding procedure.
>
> > Both the quality of the returned randomness as well as the generation
> performance of Mt19937 is worse than that of the Xoshiro256StarStar and
> PcgOneseq128XslRr64 engines that are provided in the object-oriented API.
>
> Same as previous point: If we don't allow seeding we can change the
> algorithm however we like.
>
> > They are functions with overloaded signatures <
> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures>,
> which are problematic for the reasons outlined in the “Deprecate functions
> with overloaded signatures <
> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures>”
> RFC.
>
> While this is technically true, the particular overload in question here
> is a very mild and unproblematic one. It only enforces that the function is
> called with zero or two arguments, forbidding one argument. It does not
> require accepting different combinations of argument types, or change the
> meaning of arguments, which is what makes overloads problematic.
>
>
> I think the only somewhat sound motivation for this deprecation is that
> programmers may use the non-cryptographic mt_rand() in a context where
> cryptographic numbers are required. This is a legitimate concern, but I
> don't think it's sufficient to deprecate such a widely used function.
>
> For the longest time, we only had mt_rand(), and no easy access to a
> CRPRNG. A lot of mt_rand() misuse dates back to that time. Since the
> introduction of random_int() and random_string(), getting cryptographic
> randomness is no harder than getting non-cryptographic randomness (easier,
> in the case of strings).
>
> Regards,
> Nikita


Hi.

Thank you for your valuable input. I would like to ask you a few questions.

I think you are right that deprecating `srand()` / `mt_srand()` achieves
the goal of making it unavailable for reproducible uses. But why keep the
function name `mt_rand()`?

It is certainly true that by prohibiting seeding, the PRNG algorithm can be
modified at will. But then the `mt` in `mt_rand()` would be out of touch
with reality. If this is done merely to maintain code compatibility, then
it is not a good idea to keep naming only for compatibility.

Also, `mt_rand()` has the problem of depending on the global state of the
PHP VM. This is very dangerous in forked use cases such as Swoole, where
implicitly seeded random numbers can return the exact same result in the
post-fork process. To avoid this, the sequence must be reseeded again after
the fork is executed. If only `srand()` / `mt_srand()` is deprecated, this
cannot be avoided.

The only way to completely solve this problem is to have no random number
states in the global area. For this reason, I think everything should be
deprecated. If you need pure random