RE: [PHP-DEV] [Concept] declare(strict_identifiers=1)
| From: | Juris Evertovskis | Date: | Wed, 26 Aug 2026 16:10:17 +0000 |
| Subject: | RE: [PHP-DEV] [Concept] declare(strict_identifiers=1) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132345@lists.php.net to get a copy of this message | ||
> -----Original Message-----
> From: otzelot2021@outlook.de <otzelot2021@outlook.de>
> Sent: Wednesday, August 26, 2026 6:15 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [Concept] declare(strict_identifiers=1)
>
> [..] I am proposing a per-file declare under which the accepted set
> is specified: well-formed UTF-8, UAX31-R1-2 with the standard Default-
> Ignorable Exclusion Profile, and NFC required rather than applied. Identifiers
> consisting only of bytes below 0x80 are never examined, so existing code
> pays nothing.
Hey Luca,
To prevent errors? I must admit I don't rly understand all the terms.
I assume it implies identifiers should be more visible/readable, right?
> To find out what this would break I surveyed the 250 most-downloaded
Why would anything break if it's per-file?
> Packagist packages and 250 GitHub repositories -- 168,604 PHP files -- using
> ext/tokenizer. The Packagist corpus contains exactly one non-ASCII identifier,
> and no identifier in either corpus is non-NFC.
Do I understand it correctly that by adding that declare to 168604 you would uncover
a single risky identifier? Not that convincing...
Would it be fair to say that the same constraints can be enforced by linters/cs tooling?
BR,
Juris