Re: [Concept] declare(strict_identifiers=1)

Hey Juris,

To prevent errors? I must admit I don't rly understand all the terms. I assume it implies identifiers should be more visible/readable, right?

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.

Why would anything break if it's per-file?

Nothing breaks. That was bad wording on my part. The survey answers a different question: if a maintainer adds the declare to a file they already have, does it still compile? That is adoption friction, not breakage. It is also a calibration check -- a rule that rejected a lot of legitimate existing code would be the wrong rule, and I wanted to know that before proposing it rather than after.

Do I understand it correctly that by adding that declare to 168604 you would uncover a single risky identifier? Not that convincing...

That number is the cost, not the benefit, and I should have separated the two more clearly. The single Packagist finding is what would stop compiling: symfony/cache declares a class whose entire name is the single byte 0xA9. That is the whole measured adoption cost across the 250 most-installed packages. What the rule catches can only be measured where non-ASCII identifiers actually occur, which is not in the top Packagist packages. In the GitHub corpus, 33 of 136 non-ASCII identifiers fail the rule and 11 contain an invisible character. One is live code: the Alipay OpenAPI SDK has

    $chrtext<U+00A0> = null;
    // ...
    openssl_public_encrypt($block, $chrtext<U+00A0>, $res);

with a no-break space inside the name. It works only because the typo is consistent throughout the function. Anyone who types $chrtext normally gets a different variable, passed by reference, that stays null. Five vendored copies across four unrelated projects in my sample. But you are right that these are small numbers, and I would rather say so than dress them up. The case does not rest on the bug count.

Would it be fair to say that the same constraints can be enforced by linters/cs tooling?

Partly yes, and I will concede that plainly: UTF-8 validity, NFC and UAX #31 conformance are all statically checkable. My survey tool is exactly such a linter, written in PHP, and it is in the repository. Three things it cannot do. It cannot define the language. "What is a valid PHP identifier" currently has no answer other than "whatever bytes the scanner happened to accept", which is why the manual, PHP-Parser, every IDE and every static analyser separately reverse-engineer the same byte class. A declare makes it a versioned, testable statement. It does not travel with the code. A declare is in the source file; a lint configuration is in someone's toolchain. The file keeps its guarantee after composer install, and the rule also covers generated and eval'd code that never reaches a linter. And it cannot touch semantics. Case-insensitive symbol lookup folds ASCII only, so Stra<U+00DF>e and STRA<U+00DF>E are the same class while Stra<U+1E9E>e is not, and Strasse and STRASSE are. No linter can fix that, and I do not think it can sensibly be fixed before there is a definition of what an identifier is. I deliberately kept case folding out of this proposal, but that is the thing underneath it. The same objection would apply to strict_types -- static analysers check types, so why does the engine need a per-file declaration? I do not think the answer there was "it doesn't", though I accept the parallel is not exact, since strict_types changes runtime behaviour and this does not. This is the weakest point of the proposal and you found it on the first reading. If the list's view is that specifying the rule and leaving enforcement to tooling is the right scope, that is a smaller and possibly better RFC, and I would rather establish that now than after writing the patch. Thanks for the questions. Regards, Luca