Re: [RFC Discussion] array_change_keys()

> > 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