Re: [Concept] declare(strict_identifiers=1)

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