[Concept] declare(strict_identifiers=1)

On 26 August 2026 22:24:06 BST, Larry Garfield <larry@garfieldtech.com> wrote:

Is it important enough to have this memory footprint added to each PHP process though?

cheers Derick

در تاریخ پنجشنبه ۲۷ اوت ۲۰۲۶، ۰۰:۵۶ Larry Garfield <larry@garfieldtech.com> نوشت:

------------ Fair point, Larry. Moving to enforce strict UTF-8 identifier rules in PHP 9 would definitely simplify things and eliminate edge cases cleanly. The main goal here was to highlight the current ambiguity and explore whether a transitional path or immediate strictness is preferred. Doing a broader ecosystem check before finalizing the PHP 9 deprecation path makes total sense.

PHP 9

I ran it: the top 5,000 Packagist packages by downloads, 4,863 of them resolvable and non-empty, 520,802 PHP files, 2.4 GB. Raw scanner output, per-identifier CSVs and the corpus manifest are in the repository. It is not one oddball class. 1,447 non-ASCII identifiers across 25 packages. 1,312 of them -- 91 % -- are in markrogoyski/math-php, and they are neither fixtures nor accidents. They are variable names in src/, and they spell the formula:     $n！ = self::factorial($n);     $∑  = 0;     protected $d₁;     $π  = \M_PI;     $│∑│      = $∑->det();     $√⟮2π⟯ᵏ│∑│ = \sqrt((2 * $π) ** $k * $│∑│); 1,247 of the 1,312 are T_VARIABLE. 888 of them would stop compiling: the offenders are U+27EE/U+27EF mathematical flattened parentheses, subscript and superscript digits, U+2211 summation, U+2212 minus. None of those is in XID_Continue. So the honest answer to "99.99 % won't notice" is that one library would notice 888 times, and its author chose that style deliberately and has shipped it for years. The rest of the picture argues the other way, though, and I would rather give you both halves. Outside math-php there are 135 non-ASCII identifiers, and only 25 fail -- 15 of which are one test file in hoa/console with arrow characters in method names (case_move_↑, U+2191). Everything else already conforms:   mjaschen/phpgeo     22, all conforming: $φ, $λ, $sinλ, $cos2σM in                       src/Bearing/BearingEllipsoidal.php -- Vincenty                       geodesy, Greek letters only, no symbols   tracy/tracy         14, all conforming: $ʟ_tmp, $ʟ_tag in Latte                       templates, U+029F as a namespace prefix so internal                       variables cannot collide with user ones   wsdltophp/...       44, all conforming: setСубъектРФ, ApiАдресРФ --                       generated accessors over a Russian WSDL schema,                       where the names come from the schema And across all 520,802 files, zero identifiers are not in NFC. So the cost of making this mandatory is specific and nameable rather than a long tail: it outlaws mathematical symbol notation in identifiers. Two packages do that. Everything else in the top 5,000 that uses non-ASCII identifiers already satisfies the rule and would not notice. That may still be the right call -- "PHP identifiers are letters, not notation" is a defensible position and I am not arguing against it. But it is a decision to withdraw something that works today, not a cleanup of an oddity, and I would rather the list took it with the number in front of it. One correction to something I said in the other subthread: I told Chris there was not one identifier mixing Latin with Cyrillic or Greek. At 250 packages that was true. At 5,000 there are 41 outside math-php, and they are benign -- a code generator putting an ASCII "set" in front of a Cyrillic schema element. My mixed-script metric flags the script pair, not the risk, and I should have said so. Regards, Luca

Correct on both counts. Claude Pache gave me better vocabulary for the first half than I had, and I went and measured the second half rather than guessing at it. PHP distinguishes names from identifiers. An identifier is a lexical token the scanner produces from source text; a name is any string that reaches a symbol table, and that set is far larger -- you can create a variable named "+!" or a class alias named "" today. What I described governs identifiers only. $$name, define(), class_alias() and property names materialised by json_decode() are untouched. That is not a hole I carved out for convenience; it is a line PHP already draws and already enforces syntactically. On your second point: you were right that my scan could not see these, so I extended it. Names built from a run-time string remain unmeasurable by anyone, but the statically visible subset is not -- literals in name-creating and name-looking-up positions: ${'...'}, ->{'...'}, ?->{'...'}, Foo::${'...'}, define(), constant(), class_alias(), property_exists(), method_exists() and friends. Across the same 4,863 packages and 520,802 files, that turns up **five** non-ASCII names, in two packages. All five, in full: halaxa/json-machine, src/TokensWithDebugging.php:39, under the author's own comment "Treat UTF-8 BOM bytes as whitespace":     ${"\xEF"} = ${"\xBB"} = ${"\xBF"} = 0; Three variables named after the individual bytes of the UTF-8 BOM, used as a lookup table alongside ${' '}, ${"\n"}, ${'{'} and so on. None of the three is valid UTF-8 on its own, and none of them could be written as an identifier at all. rowbot/url (vendored into wp-php-toolkit/data-liberation), tests/WhatWg/URLSearchParamsConstructorTest.php:209-210:     $obj3->{"c\u{D83D}"} = '23';     $obj3->{"d\u{1234}"} = 'foo'; WHATWG URL conformance test data. U+D83D is a lone high surrogate, which PHP encodes as ED A0 BD and which is not well-formed UTF-8; U+1234 is ordinary Ethiopic. Four of the five would fail the identifier rule, and that is the point rather than a problem: every one of them is a deliberate use of the name syntax precisely because it is not an identifier. So as far as I can measure it, the existing split is doing its job. People who need non-identifier names reach for the name syntax, rarely and on purpose. I would not have believed that number before running it, and I would not have run it if you had not asked.

This one has a definite answer, which I checked rather than assumed: code passed to eval() does not inherit strict_types from the calling file. It is compiled as its own unit and may carry its own declare; include behaves the same way. So under an opt-in model, PHPUnit, Mockery and Prophecy generating classes at run time sit outside it entirely. Under a mandatory model they would be checked, but a generated mock name derives from the mocked class, so a non-conforming name only appears if the class being mocked already had one.

That is the strongest argument for putting any of this in the engine that anyone has made in this thread, including me, and I do not want to claim more from it than it gives. A linter can never reach run-time names. But the engine as I described it does not reach them either. The difference is that the engine could be extended there and a linter could not -- and extending it means validating every symbol table insertion, a cost paid on every dynamic property write, and json_decode() throwing on untrusted input. I think that is a much larger and probably worse proposal. It is, though, a real option rather than an impossible one, which is more than the tooling route offers. The scanner change and the raw output are in the repository. Regards, Luca

در تاریخ پنجشنبه ۲۷ اوت ۲۰۲۶، ۰۲:۵۷ Christian Schneider < cschneid@cschneid.com> نوشت:

--------- Hi Chris, Thanks for the solid points. Let me clarify the perspective behind these: 1. Lexer simplicity vs. Semantic definition: [a-zA-Z_\x80-\xff] is indeed trivial for the lexer, but it isn't an identifier specification in terms of character semantics—it's essentially "ASCII identifiers plus any high byte". This was originally a pragmatic way to allow Latin-1 / UTF-8 bytes to pass through unchanged. The problem arises when we consider what an identifier semantically is across tooling, ASTs, and static analyzers versus raw byte streaming. 2. Invisible characters and Linters: You're right that linters/LSPs can catch these, but language specifications usually define identifier boundaries (such as TR31 / UAX #31) precisely so that the baseline definition of a valid symbol doesn't require third-party tooling to reject canonically confusing or invisible code points. 3. Case Folding: I completely agree with your assessment here. Extending ASCII case-folding to full Unicode casing (with all the locale subtleties like the dotted/dotless Turkish I) would be opening Pandora's box. The argument wasn't necessarily to expand case-folding to Unicode, but rather to highlight the existing inconsistency: PHP treats identifiers as case-insensitive on the ASCII plane while allowing non-ASCII bytes that are strictly case-sensitive. If the consensus leans toward treating case-insensitivity as historical baggage, clarifying the identifier grammar and transition paths (especially looking ahead to PHP 9 / UTF-8 requirements) is exactly the right discussion to have. Best regards, Sepehr

You are right and I overreached. It is a definition, it is precise, and it is far simpler to implement -- one character class against roughly 13.7 KiB of generated tables. That is a real cost and I should not have written as if PHP had nothing. What I should have said is that it is a complete definition of *bytes* and a silent one about *characters*. It fixes no encoding, so the same file is two different programs depending on how you read it, and it cannot tell a character from half of one. The part that actually bothers me is that PHP does not stay at the byte level. Case-insensitive symbol lookup is defined over characters -- ASCII characters. So there is already one character-level rule bolted onto a byte-level definition, and the seam between them is where Stra<U+00DF>e/STRA<U+00DF>E/Stra<U+1E9E>e/Strasse comes from.

Then nothing here would ever fire for you. The check I described never looks at an identifier whose bytes are all below 0x80, which is every identifier in most codebases. That is not a footnote -- it is why the thing can be considered at all.

real

I answered that at length to Juris and to Rowan and will not repeat it. Two things I did not know then and do now: the measurement is 68 identifiers with an invisible character across 520,802 files, and not all of them are accidents -- math-php puts U+00A0 inside variable names deliberately. That makes it warning-shaped rather than error-shaped, which is closer to your position than to my original one.

PHP has already answered this, which I think settles it in your favour. The 8.2 RFC "Locale-independent case conversion" used precisely the Turkish dotted I as its motivating example: before PHP 8.0 the engine inherited the system locale, so case folding varied by installation. The resolution was to make folding ASCII-only everywhere, deliberately and by vote. So the answer to "which folding" is that PHP tried locale-sensitive folding, found it unworkable, and retreated. I would not want to walk back into it.

Agreed, and I want to be clear I never proposed extending it. I listed it as evidence that the current rule is incoherent, not as something to grow. Incoherent is equally an argument for reducing. Worth saying though that reducing is not cheap either: making class and function names case-sensitive is a far larger break than anything discussed in this thread. I have no proposal there, only the observation that the rule as it stands makes sense only if identifiers are ASCII, and 1,447 of them in the top 5,000 packages are not. Regards, Luca