Re: Make iterator_to_array() accept all iterables

On Fri, Jun 17, 2022 at 9:28 AM G. P. B. <george.banyard@gmail.com> wrote: > > On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus <tim@bastelstu.be> wrote: > > > Hi Internals > > > > I've come across a case where it would've been useful if > > iterator_to_array() would accept iterable instead of > > Traversable to > > avoid checking whether the input variable already is an array. > > > > To not repeat what I've already written in my proposed PR, please see: > > > > https://github.com/php/php-src/pull/8819 > > > > for more details. > > > > In response to my question whether this would require an RFC or whether > > this is simple enough, cmb pointed to a previous RFC that proposed > > *adding* a new function iterable_to_array() which was > > declined: > > > > > > https://wiki.php.net/rfc/iterable_to_array-and-iterable_count > > > > cmb also suggested that for this reason this topic should at least be > > shortly discussed on the list, which I intend to do with this email: > > > > - Do you believe that my PR requires an RFC / do you want to see an RFC > > for this? > > - Would you object to extending 'iterator_to_array' from Traversable to > > iterable (i.e. to Traversable|array)? > > > > Best regards > > Tim Düsterhus > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > Considering the other RFC has been declined, and I can see the value of it > and the change is rather minimal, if no one has any objections I think this > is fine to land without any RFC. Personally, I take the opposite view. This has already been declined; why should it be able to avoid the RFC process when something so similar was declined recently?