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

 > What problem would this restriction solve?
 > Is it about an code smuggling attack vector using code obfuscation with
 > indistinguishable Unicode sequences?

No, and I would rather decline that framing than borrow it.

I did look for it. Across both corpora -- 168,604 files -- there is not
one identifier mixing Latin with Cyrillic or Greek, and not one that maps
to a plausible ASCII identifier under homoglyph substitution. The
proposal does not reject confusables and the draft says so explicitly.
UAX #31 takes the same position: for programming languages, spoofing is
better addressed by higher-level diagnostics than in the lexer.

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.

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.

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.

Taken alone, (2) is thin. Juris made the same point in the other
subthread and he is right; I am not going to inflate it.

Which leaves the question I think has to be answered before this is worth
either of our time:

PHP accepts non-ASCII identifiers today, and not by decision. The manual
says outright that PHP "doesn't support Unicode variable names" and that
they work because of how UTF-8 happens to encode. So either they are a
supported feature, in which case they need a definition and (3) is an
inconsistency in the engine -- or they are not, in which case that ought
to be a decision somebody made rather than a note explaining an accident,
and I will drop this.

I would rather have a clear answer than a favourable one, because
anything else I might propose in this area depends on it.

If your -1 rests on "not supported, and we are not going to build on it",
I would sooner have that now than after writing a patch. It is a
legitimate answer and it settles the question.


Regards,
Luca