On 26-8-2026 21:42, [email protected] wrote:
Not readability -- unambiguity. Three concrete things, no jargon:
1. Two identifiers that look identical on screen are currently two
different identifiers. $x and $x followed by U+00A0 NO-BREAK SPACE
are separate variables. So are "a" plus a combining diaeresis and the
single character U+00E4; both display as a-umlaut.
2. Text that is not valid UTF-8 at all is currently a valid identifier.
${"\xFF\xFE"} = 1; compiles.
3. Nobody can state what a PHP identifier is except by copying the byte
class out of the scanner. The manual does exactly that, and so does
PHP-Parser.
The declare says: in this file, an identifier is well-formed UTF-8, is a
Unicode identifier in the sense of UAX #31 (the Unicode annex that
defines this for programming languages), and is written in one canonical
spelling. Anything else is a compile error.
Hi Luca & list,
Reading this and seeing you talk about making it a compile time error,
raises the question for me of how this will interact with variable
variables which don't comply with the proposed rules - AFAICS those
wouldn't be able to be a compile time error and they also wouldn't have
been found in the scan of Packagist files.
I imagine "on the fly" class creation, like when mocking code may also
run into issues with this up to a point ?
Those are also the things which static analysis of code would not be
able to find or flag (if this were left to static analysis).
Curious to hear your thoughts on this.
Smile,
Juliette
