PHP’s Array Keys Defy Expectation

PHP’s documentation is a constant reminder of how strange the language can be. A quick look at how array keys are handled reveals a surprising tangle of type coercion rules.

Consider an array built with a mix of integer and string keys, including the string "8". According to PHP’s rules, decimal integer strings are converted to integers when used as keys. So the string "8" silently overwrites the integer key 8. But an octal-looking string like "010" is not converted—it stays a string key, independent of the integer 10 (or, for that matter, the integer 8).

The confusion deepens when you access elements. With an array like this:

  • $things[0] returns the element at integer index 0.
  • $things["0"] also returns the same element, because the string "0" is cast to integer 0.
  • $things[8] returns the element stored under the string key "8", not an element with numeric index 8.
  • $things[010]—that’s an octal literal in the source code equal to decimal 8—returns the same element as $things[8].
  • $things["8"] also gives that same element.
  • $things["010"] returns the element stored under the string key "010", not the element at index 8 and not the element at index 10.

So while the string "0" behaves like the integer 0, the string "010" behaves like a pure string. Meanwhile, integer-looking strings with no leading zero do get interpreted as integers. The distinction is entirely dependent on the presence of a leading zero, a detail that is neither obvious nor documented prominently.

This behavior is a textbook example of a language that layers features and implicit conversions to accommodate users who don’t want to track types carefully. The result is a system where a simple array lookup can depend on whether a key looks like a decimal integer, an octal integer, or neither—and where the same value can be accessed through wildly different keys depending on context. It is a lesson in how permissive typing, applied inconsistently, can make even basic operations unpredictable.