Regarding array_shift()/array_unshift()

But from all this I do agree with you that just returning an array would likely be acceptable.

This would not be a great solution for really large arrays, but then we can't eliminate the need for a developer to have a reasonable level of knowledge, right? So:

$unshifted = $array->unshift($new_element);
$shifted = $array->shift();

But, we could also possibly use better names for these:

$right_shifted = $array->shift_right(...$new_element(s));
$left_shifted = $array->shift_left([element_count]);

IMO for unshift() it'd be fine to return a new array, but when processing a list of things in a FIFO pattern I often used array_shift() to get the first "job" out of the array. If $array->shift() returns a new array then how do I access the first item?

That is a really excellent point, something I did not think to consider given how rarely I use array_shift().

But your comment causes me to ponder a number of follow up questions, some of which are tangential. If any reader feels these tangents are worth discussing please make another email and quote my relevant comments so we can have a dedicated thread for each.

1.) Given Nikita's position that it would only be viable to offer a syntax that simulates method calling for arrays if the methods themselves are immutable can you envision a solution for allowing $array->shift() functionality that would address getting both element and shifted array without resorting to by-reference parameters?

2.) One approach I can envision is to add functionality to PHP that would allow the returning multiple values from a function or method — NOT to be confused with returning an array that can be destructured with list() or []. There is certainly precedence in other languages to prove the validity of the programming model, and they solve some thorny issues quite nicely.

I have wanted to bring this up on the list for eons but have feared not having my use-cases written up well enough to keep people from immediately having a negative reaction and thus prejudicing too many on the list for it ever to be viable. But I am going to risk it and hope this use-case is sufficient to peak people's interest, or at least not have them summarily dismiss the idea with prejudice.

If PHP were to allow multiple returns then we could have one of the following (not sure which would be best):

$element, $shifted = $array->shift();
OR
$shifted, $element = $array->shift();

Following the lead of another language, we could use an underscore placeholder to indicate not to capture the return value if we don't need it:

$element, _ = $array->shift();
_, $shifted = $array->shift();

Again, this is NOT the same as array destructuring where the function would need to return an array containing the array.

3.) When you have used an array to contain a list of "jobs", are you creating that array in your code or have you gotten the array from a function within PHP that provides the array such as scandir() or glob()?

4.) Given Nikita's comments on the O(<n>) performance of array_shift() have you considered instead simulating a FIFO queue using an array as a stack? Any reason that would not work for your needs?

5.) Alternately given Nikita's comments on array_shift() have you considered using SqlQueue: https://www.php.net/manual/en/book.spl.php? It seems a perfect fit for your FIFO use-case to the extent you've explained it. Honest question, not a challenge. Wouldn't that work better than an array?

6.) More broadly, this made me wonder about the SPL data structure classes in general. I honestly did not think of SplQueue at first because I so rarely use any of the SPL classes. I was not until I started to ponder what "different data-structure or construction approach" might be appropriate, referencing Nikita's comment. Then I wondered why I don't think to use those classes more often, and I came up with these hypotheses, in ascending order of likelihood in my opinion:

A.) Admittedly superficial but the Spl class names make code look more complicated. I'd much rather see Queue than SplQueue, or more specifically — while ignoring the still-raging debate over the best way tonamespace built-in PHP classes — I'd much rather use an \SPL\Queue than an SplQueue. Maybe PHP could create aliases for these classes but within a namespace?

B.) Out-of-sight, out-of-mind. I rarely see people use the SPL functions in open-source code, discussed on StackExchange, written about in articles or on mailing lists.

C1.) The SPL data structure classes do not have anywhere near the functionality that arrays have built-in functions for, such as: array_combine(), array_fill(), array_map(), array_reduce(), array_slice(), array_splice(), array_search(), array_filter(), array_walk(), etc. etc. Maybe PHP could add more of that kind of functionality for these data structures?

C2.) Also there are no performant ways to convert one related data structure to another. You can't easily convert a SplStack to a SplQueue, or a SqlQueue to a SplPriorityQueue, and there may be other appropriate conversions that PHP obviously does not provide.

D.) Few if any built-in PHP functions or methods accept instances of these classes as parameters, nor return instances of these classes. Examples include: sort(), file(), glob(), scandir(), iterator_to_array(), str_split(), str_replace(), preg_match_all(), str_getcsv(), fputcsv()/fgetcsv(), func_get_args(), call_user_func_array(), implode()/explode(), sprintf(), file_put_contents(), var_dump(), var_export(), filter_input_array(), mysql_fetch_row(), get_defined_constants(), get_defined_vars(), debug_backtrace(), etc. etc. So if you are always being handed an array, no wonder you rarely ever use the SPL classes, right?

If we were to address any or all of A-to-D maybe PHP developers would be more inclined to use different data-structure and/or construction approaches that better fit their use-cases?

So in summary the tangential topics I addressed were:

1.) PHP potentially supporting multiple return values, and
2.) Renewed focus on SPL data structures.

Again, if anyone is interested in these tangential topics and wants to discuss further, please create a new thread and quote my applicable comments from this email.

-Mike