[RFC] Allow object keys in arrays

Code written to deal with array in a generic way will no longer work
when
invoked through code paths that produce object keys: this is a general
problem with widening types overall, and is a clear BC break.

If you look at levels of BC break, this is on the very low end in my
opinion. No existing code will break when upgrading to this new PHP
version. Only new code written specifically for that PHP version would
be impacted, and frameworks/libraries could, if necessary, add
additional checks without becoming incompatible with older PHP versions.
It helps that currently array keys can be integers or strings, so if the
key type is important, some checking is already necessary.

This is untrue. It's quite possible to have code like this today:

function make_list(array $vals) {
$out = '<select>';
foreach ($vals as $key => $label) {
$out .= sprintf('<option value="%s">%s</option>', $key, $label);
}
return $out . '</select>';
}

That would work just fine today with string or int keys, but would break if on an object-keyed array if the objects did not implement __toString().

Whether the risk of such code breaking in practice is large or small is another question, and I don't have an answer for it. I'm of mixed feelings on this RFC; on the one hand, it would make Enums even easier to work with, which is good. On the other, it pours even more behavior into the kitchen sink data structure whose (mis)use is a known security hole, which is bad. I'd like to see us using naked hash tables less, not more.

Ilija is also correct that minor potential-breaks like this have been introduced in the past, and the world has not ended. Whether that is good or bad, historically, is debatable and likely varies with the specific feature.

I would say that if this RFC moves forward, we would also want to introduce an other array_is_*() function to make adding extra guards easier. I'm not sure what we'd call it, though. array_is_keyed? array_is_assoc? array_is_not_objects? Bikeshed as you wish. :-) But we'd want some easy way to tell what key-style an array uses.

... maybe a function that returns an internal enumeration of List, Assoc, or Object for the 3 key types? :-)

--Larry Garfield

Le 13/01/2021 à 10:08, Rowan Tommins a écrit :

Whether the problem can be mitigated is what should be discussed, but
the
problem is objectively there.

Hi all,

Like others, I like the idea of object keys, but worry about its
practical impact.

A few scatter-gun thoughts on possible approaches, I don't think any
of them is the solution, but maybe they'll spark someone else to
further ideas:

• Only allow objects that are "stringable" (i.e. implement
  __toString), but don't actually call it. This retains the safety of
  code using "(string)$key", but not code passing to a constraint of
  "string|int". (It also means enums will all have to have an
  __toString, which might be a price worth paying.)

• Create a new type, which is like an array but allows object keys,
  with its own literal syntax. e.g.

$hash = hash['foo' => 42, $someObject => 69];
assert(is_array($hash) === false);
assert(is_iterable($hash) === true);

• Invent a syntax for initialising a custom collection object from a
  literal with arbitrary keys and values, but not actually initialise it
  as an array. Even without generics, this would make it much more
  attractive to replace more arrays with specific collection types.

Regards,

Hello,

Instead of trying to restrict types that can be used as keys, may be
this should be the time to have enumerables, lists, maps, vectors, sets,
types, dictionaries, ... in PHP standard library ? A third party tool
such as PHP-DS should be part of core API instead of being a third party
extension.

Arrays are arrays, but the more we add features in a single polymorphic
data structure such as this, the less code is readable and
comprehensible. We use arrays everywhere as soon as we need a list or a
map, a vector, a set, a list, a dictionary, a data structure that's not
an object, etc... that isn't built using a generator, and it becomes a
serious mess. It's weakly typed, it's not explicit about the intent, in
some case, I guess specific data structure would be much faster as well.

I think adding this new feature is really cool, but having a complete
API around iterable with different types for different use cases would
be much better in my opinion.

I know it's not going to happen soon, just saying for the sake of the
conversation, but PHP arrays are really powerful, and insanely
polymorphic, and they do way too much in my opinion.

Regards,

Pierre

On Wed, Jan 13, 2021 at 10:08 AM Rowan Tommins rowan.collins@gmail.com
wrote:

Whether the problem can be mitigated is what should be discussed, but the
problem is objectively there.

Hi all,

Like others, I like the idea of object keys, but worry about its
practical impact.

A few scatter-gun thoughts on possible approaches, I don't think any of
them is the solution, but maybe they'll spark someone else to further
ideas:

• Only allow objects that are "stringable" (i.e. implement __toString),
  but don't actually call it. This retains the safety of code using
  "(string)$key", but not code passing to a constraint of "string|int".
  (It also means enums will all have to have an __toString, which might be
  a price worth paying.)

• Create a new type, which is like an array but allows object keys, with
  its own literal syntax. e.g.

$hash = hash['foo' => 42, $someObject => 69];
assert(is_array($hash) === false);
assert(is_iterable($hash) === true);

• Invent a syntax for initialising a custom collection object from a
  literal with arbitrary keys and values, but not actually initialise it
  as an array. Even without generics, this would make it much more
  attractive to replace more arrays with specific collection types.

I don't think a separate dictionary type would really help (in the context
of this discussion). If you're working with arrays, you already either
treat it as a vector (in which case the keys are irrelevant) or as a
dictionary (in which case you would need to deal with object keys
regardless of whether you call it "array" or "dict"). I think a dedicated
dictionary type can have other benefits (primarily removing numeric string
-> int canonicalization), but I don't think that distinguishing allowed key
types based on it is a good idea. (If we introduced such a type, I would
expect it to have the same key requirements as normal arrays, because both
types would have to be strongly interoperable, and allow mostly seamless
conversions.)

Regards,
Nikita