https://stitcher.io/blog/new-in-php-83#changes-to-the-range()-function-breaking

Changes to the range() function breaking
From the changelog:

• A TypeError is now thrown when passing objects, resources, or arrays as the boundary inputs
• A more descriptive ValueError is thrown when passing 0 for $step
• A ValueError is now thrown when using a negative $step for increasing ranges
• If $step is a float that can be interpreted as an int, it is now done so
• A ValueError is now thrown if any argument is infinity or NAN
• An E_WARNING is now emitted if $start or $end is the empty string. The value * continues to be cast to the value 0.
• An E_WARNING is now emitted if $start or $end has more than one byte, only if it is a non-numeric string.
• An E_WARNING is now emitted if $start or $end is cast to an integer because the other boundary input is a number. (e.g. range(5, 'z')
• An E_WARNING is now emitted if $step is a float when trying to generate a range of characters, except if both boundary inputs are numeric strings (e.g. range('5', '9', 0.5); does not produce a warning)
• range() now produce a list of characters if one of the boundary inputs is a string digit instead of casting the other input to int (e.g. range('5', 'z')

Required

As far as I can tell, most of these would not have provided desirable results anyway, but now cause warnings or errors to be thrown instead of silently failing.

We have approx 80 uses in core.
Most of these can be immediately excluded as they are using fixed ints
The remainder can be manually checked but I can't foresee any issues in any of these with a quick eyeball.

gg -I ' range(' | grep -v '\.js:'

1. Confirm my assessment of this