Re: [PHP-DEV] [Concept] declare(strict_identifiers=1)

در تاریخ پنجشنبه ۲۷ اوت ۲۰۲۶، ۰۲:۵۷ Christian Schneider <
[email protected]> نوشت:

> Am 26.08.2026 um 21:57 schrieb Luca Rodenhäuser <[email protected]>:
> > 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