On Wed, 17 Jun 2026 at 01:04, Jorg Sowa <[email protected]> wrote: > > Hello internals, > I would like to revive the discussion about fully case-sensitive PHP. I have collected the points raised in previous discussions, and browsed all affected language features and functionalities. > > I still need to perform the impact analysis and the performance benchmarks. I will add them to the RFC and inform in the thread when I complete it. > > RFC: https://wiki.php.net/rfc/case_sensitive_php > > Kind regards, > Jorg
Hi Jorg, I am in favor of this RFC. Case sensitivity in PHP is particularly challenging from a static analysis perspective, as it currently requires us to perform normalization and maintain tracking for both normalized and original names for error reporting. It is also an issue for Zend itself, and I see little benefit in maintaining it when the majority of languages listed in the RFC do not. Existing codebases could resolve these issues using migration tools, and a deprecation period until 9.0 is a good approach. However, I would like some clarification regarding the plan for 9.0 to "Promote deprecations to E_ERROR." This could be interpreted in two ways: 1. Replacing E_DEPRECATED with E_ERROR everywhere, which I believe would be incorrect. 2. Removing the deprecation and tolower in the engine so that a case mismatch results in an error as if the symbol does not exist. This seems like the correct path, but describing it as "promoting deprecations to E_ERROR" might be misleading. For example, a call like is_a($foo, 'FOO'); that previously emitted E_DEPRECATED and returned true would now return false. Cheers, Seifeddine Gmati
