How about iterator_to_array()? http://php.net/iterator-to-array

Thanks for the quick response. I didn't know that function and it does pretty much what I intend to do, but the problem is: I have to call it manually. I'd love to see that function being invoked automatically when casting to an array, since that's the point of having a cast option after all. In my mind it's not consistent to be able to foreach through an object as expected but getting something completely different when casting it to an array.

iterator_to_array() has two modes: It can either preserve the keys of the iterator, or it can reindex it. It depends on the iterator which of these behaviors is appropriate. Especially with generator functions it's very common that preserving keys will yield a result of limited usefulness, as duplicate keys are overwritten.

If (array) were to automatically invoke iterator_to_array() in one of these modes, you'd probably end up with the wrong behavior half the time.

I see preserving keys could be a problem and there should be a way to create an array out of the values of an object only, like iterator_to_array($foo, false) does, but nevertheless, I think that "losing" duplicate keys can be seen as expected behaviour when casting to an array, since there are by definition no duplicate keys in an array.

Take this example: $a = (int)3.14;

What's $a going to be? Obviously, it'll result in a flat 3, because an integer just does not support decimals, and that's okay, since it is by fact an integer. Arrays in PHP don't support duplicate keys, hence, you won't get them and they'll be "lost". What arrays in PHP do support, are non-numeric keys, which means, you will get them. In my opinion, you have to deal with things like that manually if you're trying to cast one type to another.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

What @nikic might be getting at is that an array cast using iterator_to_array() is not very obvious in how it would work.

With (int)$float there is very clear behavior which can be seen directly on that line of code: the whole part of $float will be kept and any fractional part will be lost. With (string)$object there is also clear behavior: PHP will try to call $object->__toString().

But with (array)$object it is not clear. Will it call iterator_to_array() or use the default properties-to-array behavior? Does the object/collection potentially have duplicate keys? Will values from duplicate keys overwrite, or will the entire array use numeric keys? Answering those questions requires detailed knowledge about $object that may not be easy to see in its code.

If you like this idea and feel it has merit then you should mention it on the internals mailing list (see http://php.net/mailing-lists.php). At the very least this would be a significant addition to how objects work - to the point where it would have an impact on backwards compatibility (what about code that currently uses an array cast on iterable classes?) - and that alone makes it an issue for discussion and possible RFC.

As requinix@php.net said, automatic conversion with iterator_to_array($foo, false) may break backward compatibility if someone rely on current (array) $foo casting.

But if someone adds __toArray() magic method, than he is in charge of dealing with errors caused by (array) $foo typecasting.

Old code will work same as before without any change.

So I wote for request #52807 which is about to add __toArray() magic method.