Re: [Concept] declare(strict_identifiers=1)

در تاریخ پنجشنبه ۲۷ اوت ۲۰۲۶، ۰۱:۲۳ Derick Rethans <derick@php.net> نوشت: > 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 ------------ Hi Derick, Good point. The ~13.7 KiB footprint comes from the static lookup tables generated for fast classification. A couple of aspects regarding how this is handled / can be optimized: 1. Shared Memory (.rodata): Since these tables are declared as `static const`, in standard multi-process setups (e.g. PHP-FPM), they reside in read-only memory pages shared across processes rather than allocating per-process heap memory. 2. Compacting / Range Encoding: We can definitely look into compressing the lookup tables (e.g., using run-length/interval encoding or two-stage lookup tables) to bring the table size well under a few kilobytes if the raw table footprint is a concern. I’m happy to explore compressing the tables or benchmarking the memory impact across different setups to ensure the footprint remains negligible. Best regards, Sepehr >