[wp-trac] [WordPress Trac] #55105: Introduce a polyfill for `array_is_list()`.

WordPress Trac noreply at wordpress.org
Wed Apr 6 05:36:21 UTC 2022

#55105: Introduce a polyfill for `array_is_list()`.
 Reporter:  costdev                   |       Owner:  (none)
     Type:  feature request           |      Status:  closed
 Priority:  normal                    |   Milestone:
Component:  General                   |     Version:
 Severity:  minor                     |  Resolution:  maybelater
 Keywords:  has-patch has-unit-tests  |     Focuses:
Changes (by costdev):

 * keywords:  has-patch has-unit-tests dev-feedback => has-patch has-unit-
 * status:  new => closed
 * resolution:   => maybelater
 * milestone:  6.0 =>


 Yeah, let's close this one as `maybelater` so it can be picked up, with
 unit tests, if use cases are found.

 For some futureproofing, I'll close the PR and upload a `.diff` to the
 ticket, which will include an additional dataset for `array( NAN )`.

 Some history for contributors who may look at this in future:
 1. The patch uses `foreach ( $arr...` instead of `array_keys( $arr )` or
 `array_keys($arr) === range(count($arr)-1)` to avoid creating new arrays
 unnecessarily. This means only one pass over the array, and is in line
 with the example given in the [https://wiki.php.net/rfc/is_list RFC's
 Proposal section].
 2. An early return for an empty array is not included because an empty
 array will skip on the `foreach()` and return `true`.
 An alternative implementation] used by Symfony has an early return on
 `$array === array_values($array)`. The performance improvement from this
 early return is negligible, but importantly, performance is inconsistent
 across different versions of PHP, so I think the current implementation is
 the simplest and most effective polyfill for `array_is_list()`.

Ticket URL: <https://core.trac.wordpress.org/ticket/55105#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list