Re: [Concept] declare(strict_identifiers=1)
| From: | Derick Rethans | Date: | Wed, 26 Aug 2026 21:51:08 +0000 |
| Subject: | Re: [Concept] declare(strict_identifiers=1) | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132351@lists.php.net to get a copy of this message | ||
On 26 August 2026 22:24:06 BST, Larry Garfield <larry@garfieldtech.com> wrote:
>On Wed, Aug 26, 2026, at 2:42 PM, otzelot2021@outlook.de wrote:
>
>> 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