[Concept] declare(strict_identifiers=1)

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.

If this is so rarely seen in the wild (something that should be verified with more than 250 packages), why make it an option? Just plan that PHP 9 will enforce UTF-8-or-GTFO rules on identifiers, Symfony updates one oddball class, and we move on with life. 99.99% of developers won't notice anything happened.

--Larry Garfield

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

About 13.7 KiB of generated tables

cheers
Derick

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

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.

If this is so rarely seen in the wild (something that should be verified
with more than 250 packages), why make it an option? Just plan that PHP 9
will enforce UTF-8-or-GTFO rules on identifiers, Symfony updates one
oddball class, and we move on with life. 99.99% of developers won't notice
anything happened.

--Larry Garfield

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.

If this is so rarely seen in the wild (something that should be verified
with more than 250 packages), why make it an option?  Just plan that
PHP 9
will enforce UTF-8-or-GTFO rules on identifiers, Symfony updates one
oddball class, and we move on with life.  99.99% of developers won't
notice anything happened.

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

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.

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.

I imagine "on the fly" class creation, like when mocking code may also
run into issues with this up to a point ?

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.

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).

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> نوشت:

Am 26.08.2026 um 21:57 schrieb Luca Rodenhäuser otzelot2021@outlook.de:

What it does solve, ordered by how much I think each is actually worth:

1. PHP has no definition of an identifier. The only answer to "what is a
   valid PHP identifier" is "whatever bytes the scanner accepted", which
   is why the manual, PHP-Parser, every IDE and every static analyser
   each copy out the same byte class. That is a language-definition gap,
   not a bug report.

I'm not sure why you consider a formal definition like
LABEL [a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*
not a definition. Personally I find this a simpler definition (and easier
to implement in a parser) than something like
UTF-8, UAX31-R1-2 with the standard Default-Ignorable Exclusion
Profile

But then again I'm not really using non-ASCII identifiers today.

2. Identifiers that render identically are different identifiers. A
   no-break space or a decomposed umlaut inside a name is invisible in
   every editor. Real, but rare: 11 instances in 168,604 files.

I understand your point. But I'm not so worried about accidental mixups
here. And this is also something an LSP or Linter can help you with if it a
real concern for you.

3. Case-insensitive lookup folds ASCII only. Stra<U+00DF>e and
   STRA<U+00DF>E are the same class; Stra<U+1E9E>e is not, and Strasse is
   not. That rule is coherent only if identifiers are ASCII.

Case-insensitive folding adds another problem: Would you be using
IntlChar::FOLD_CASE_DEFAULT or IntlChar::FOLD_CASE_EXCLUDE_SPECIAL_I to
fold "I"? Or would you base it on a language setting?

In general I think most people consider the case-folding for identifiers
nowadays to be a bug, not a feature, so I would probably rather try to
reduce than extend it.

Regards,

• Chris

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

I'm not sure why you consider a formal definition like
         LABEL  [a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*
not a definition. Personally I find this a simpler definition (and easier
to implement in a parser) than something like
         UTF-8, UAX31-R1-2 with the standard Default-Ignorable Exclusion
         Profile

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.

But then again I'm not really using non-ASCII identifiers today.

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.

And this is also something an LSP or Linter can help you with if it a
real
concern for you.

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.

Case-insensitive folding adds another problem: Would you be using
IntlChar::FOLD_CASE_DEFAULT or IntlChar::FOLD_CASE_EXCLUDE_SPECIAL_I to
fold "I"? Or would you base it on a language setting?

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.

In general I think most people consider the case-folding for identifiers
nowadays to be a bug, not a feature, so I would probably rather try to
reduce than extend 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