> Le 26 août 2026 à 17:15, [email protected] a écrit : > > Hi internals, > > I would like to gauge reaction before writing an RFC. > > PHP's scanner defines identifiers on bytes rather than code points: > > LABEL [a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]* > > Every byte >= 0x80 is accepted, so UTF-8 identifiers work by accident; > the manual says as much. There is no encoding validation, no > normalisation requirement and no UAX #31 conformance. As a result > ${"\xFF\xFE"} is a valid variable name, and $x and $x<U+00A0> are two > distinct variables that render identically.
Hi, There is some confusion here: A valid name is made up of any string, not just strings that are identifiers. Example of use of a variable named "+!" : https://3v4l.org/QSJmh Example of use of a class (more precisely a class alias) named "" (yes, the empty string): https://3v4l.org/TQL18 Of course, names that are not identifiers cannot appear in constructs that accept an identifier only, such as an `extends` clause. > > (...). I am proposing a per-file declare under which the accepted > set is specified: well-formed UTF-8, UAX31-R1-2 with the standard > Default-Ignorable Exclusion Profile, and NFC required rather than > applied. (...) I don’t think that a per-file declare is a reasonable option. I would love if the PHP compiler could complain with a clearer error whenever I type accidentally a non-breaking space. But I wouldn’t add a declare clause at the top of each and every file just for that. —Claude
