Re: [Concept] declare(strict_identifiers=1)

From: Date: Wed, 26 Aug 2026 21:58:03 +0000
Subject: Re: [Concept] declare(strict_identifiers=1)
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-132352@lists.php.net to get a copy of this message
در تاریخ پنجشنبه ۲۷ اوت ۲۰۲۶، ۰۰:۵۶ Larry Garfield <larry@garfieldtech.com> نوشت: > 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 > ------------ Fair point, Larry. Moving to enforce strict UTF-8 identifier rules in PHP 9 would definitely simplify things and eliminate edge cases cleanly. The main goal here was to highlight the current ambiguity and explore whether a transitional path or immediate strictness is preferred. Doing a broader ecosystem check before finalizing the PHP 9 deprecation path makes total sense.

« previous php.internals (#132352) next »