Either allow literal ints as shape keys, or require class constant shape keys to be strings

[fredemmott]

class MyClass {
  const int FOO = 123;
}

type MyShape = shape(
  MyClass::FOO => string, // this is fine
  123 => string, // expected string literal or class constant
}

Discovered while looking into why Shapes::toArray() returns array<arraykey, mixed> instead of array<string,mixed>

[JoelMarcey]

"returns array instead of array" ???

[Orvid]

It's there, but apparently is detected as part of the markup. What he actually said is array<string,mixed> not array<arraykey,mixed>, the markup is just hiding some of it.

[lexidor]

The reason why this rule exists (I believe) is because shape()s were backed by PHP arrays in 2015.
PHP arrays performed integral type coercion on keys.
['0' => 'zero'] would become [0 => 'zero'].
The typesystem could not model shapes like this, because it wouldn't know about this runtime "helpful" behavior.

type MyShape = shape(
  '0' => string,
  0 => int
);

This shape is impossible to create in hhvm versions back shapes with PHP arrays.

Since hhvm 4.2.0 PHP arrays (and darrays, the backing type behind shapes), nolonger perform integral key coercion.
However the typechecker still shields you from this dead runtime behavior.

type MyShape = shape(
    '1' => string,
);

Parsing[1002] Shape field name must not be an int-like string (i.e. "123")
   --> file.hack
 11 |     '1' => string,
    |     ^^^

1 error found.

The blogpost for hhvm 3.28.3 states this directly.
Because shapes are darrays under the hood, we are still disallowing user-defined shapes to define integer keys due to intish string array key coercion.

I think we can safely allow int keys in shapes now.

[fredemmott]

Yeah, they’re used in regex matches without issues, but aren’t permitted in user defined types.