>
> shouldn't it be possible to return null as new key? That way you say:
> Use the next free integer index.
>
> Not sure if returning null is wanted (as it could hide errors in the
> callback) or needed in some real world use cases. But it would be more
> in sync with $a[] = ...
>
That's an interesting idea, but it would go against how other array
functionality works.
For example, if you ran this:
var_dump( array_combine([null, null], ['foo', 'bar']) );
You'd get the following output:
array(1) { [""]=> string(3) "bar" }
The null you intended to be a key becomes an empty string instead, and the
latter value of "bar" overrides the former one.
You'll see this same behavior if you did the following:
$a = [];
$a[null] = 'foo';
$a[null] = 'bar';
So that's one way nulls are handled. The other way is to raise a warning
and skip that element, which is what array_flip (and this proposal) does:
var_dump( array_flip(['foo' => 'null']) );
Output:
Warning: array_flip(): Can only flip STRING and INTEGER values! in
/in/7bBvO on line 3 array(0) { }
Implementing the feature you mentioned would introduce a third approach,
which is something I'd like to avoid. Perhaps a future RFC could implement
this feature, either for just this one function or others as well?
Colin
