php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #76865 RFC: make `array_*` functions handling `iterable`, not only `array`
Submitted: 2018-09-12 01:04 UTC Modified: 2021-03-03 11:51 UTC
Votes:2
Avg. Score:3.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: scif-1986 at ya dot ru Assigned:
Status: Suspended Package: Arrays related
PHP Version: Next Minor Version OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: scif-1986 at ya dot ru
New email:
PHP Version: OS:

 

 [2018-09-12 01:04 UTC] scif-1986 at ya dot ru 
Description:
------------
The `iterable` pseudo-type has been introduced for a while and is very useful. While `array_*()` core functions are still doesn't support `iterable` as argument and works with `array` only. Obviously, I'm talking about `array_map()/array_column()/array_diff(),array_chunk()/array_combine()…` which don't change an argument by pointer.
Sorry, don't know C, so it's just an idea :)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-09-12 01:20 UTC] carusogabriel@php.net 
This is something I'd love to see implemented, but, I don't know if we should change the `array_*` functions. By they starting with "array_", we presume that one of the arguments is gonna be an array, not an iterable.

I can try to create POC within the next weeks and open for discussion on internals@ :)
 [2018-09-12 01:29 UTC] scif-1986 at ya dot ru 
Actually, these functions will still return an array as a result :) Also, I can't find any suitable name for such functions. `iterable_diff()`? Looks ugly. And array will still be the valid input.
 [2018-09-12 04:18 UTC] requinix@php.net 
Some comments that will likely arise:
* The single-pass functions (eg, map, column, chunk, combine) could benefit from this
* The more complicated functions (eg, diff) would need iterator_to_array
* iterator_apply would presumably be made an alias of array_map
* These functions can be called multiple times on arrays but not necessarily so on iterators
* What happens when the iterator is exhausted?

That last point is the main reason why this question tends to be resolved one way: using iterator_to_array is a benefit, not a hindrance, as it reminds the developer that the source was not a simple array that can be easily reused.
 [2018-11-19 14:53 UTC] zhujinxuan at gmail dot com 
Personally, I think it is better to provide a namespace like `STD` and then, in that namespace, implement functions polyfilled for array. iterator and all possible foldable interfaces.

For that library, we can use an PHP implementation as the first release, and then make it to C and merge it to main PHP branch when the API seems stable, For a long time, we are in a lack of standard library with consistency.
 [2019-02-28 23:45 UTC] scif-1986 at ya dot ru 
Hi guys, is there any update on this proposal? It sounds reasonable, doesn't it?

Thanks!
 [2021-03-03 11:51 UTC] cmb@php.net
-Status: Open +Status: Suspended
 [2021-03-03 11:51 UTC] cmb@php.net 
Please pursue the RFC process[1].  For the time being, I'm
suspending this ticket.

[1] <https://wiki.php.net/rfc/howto>
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Mar 14 15:01:30 2025 UTC