Not sure this is worth it, especially due to the BC break. Gets solved by union types: int|string, so I'd prefer those. 😊

@Majkl578, from Hack lang docs :

Values of array or collection type can be indexed by int or string. Suppose, for example, an operation was performed on an array to extract the keys, but we didn't know the type of the key. As such, we are left with using mixed (which is way too loose) or doing some sort of duplicative code. Instead, we can use arraykey.

see : https://docs.hhvm.com/hack/types/arraykey

also : #1887

aside from that, i'll be trying to implement generics in the future ( not any time soon though ), mixed, arraykey and num ( that would be another RFC, that also tries to fix float from being float|int to just float ) would be needed in multiple situation for type constrain.

specially on existing functions / interfaces.

e.g :

// `Tv` has no type constrain = `as mixed`
ArrayAccess<Tk as arraykey, Tv>  { 
  abstract public offsetExists ( Tk $offset ) : bool
  abstract public offsetGet ( Tk $offset ) : Tv
  abstract public offsetSet ( ?Tk $offset , Tv $value ) : void
  abstract public offsetUnset ( Tk $offset ) : void
}

// same behavoir as now,
// same as implements ArrayAccess<arraykey, mixed>
class UntypedStorage implements ArrayAccess { /* */ }

// ok, `string` is `arraykey`
class StringFooStorage implements ArrayAccess<string, Foo> { /* */ }
$storage['foo'] = new Foo();

// ok, `int` is `arraykey`
class IntBarStorage implements ArrayAccess<int, Bar> { /* */ }
$storage[1] = new Bar();

// type error, `Baz` is not `arraykey`
// you can't do `$storage[new Baz] = new Qux` anyway ( Illegal offset )
// so we raise a type error at declaration.
class BazQuxStorage implements ArrayAccess<Baz, Qux> { /* */ }

Not sure this is worth it, especially due to the BC break. Gets solved by union types: int|string, so I'd prefer those.

Even if we'd like to introduce arraykey as an alias for int|string, we'd still have to make sure that the behavior is consistent with union types. In particular this requires resolving the question of how exactly int|string will behave under weak typing (which will very likely not match what is implemented in this PR). This is something we can only reasonably do given a full union types proposal.

As such, I don't think we can really introduce arraykey, or even meaningfully discuss the concept, until after a union types RFC has been accepted.

@azjezz as Nikic said, this might be difficult to get passed in an RFC. Before spending much time on drafting an RFC, gauging the reaction of people to the idea on the internals would probably be a good thing to do, though it would probably get the same sort of response.

If nothing else, this would be a useful push to show how the union types https://wiki.php.net/rfc/union_types should probably be re-visited.

@azjezz Are you planning on proposing an RFC for this? We have union types now, which seem to handle this case reasonably.

@iluuu1994 no, union is good enough, and handles the int|string vs string|int problem better.