[RFC] Case sensitive PHP

On Wed, 17 Jun 2026 at 01:04, Jorg Sowa <jorg.sowa@gmail.com> wrote:

have collected the points raised in previous discussions, and browsed all affected language features and functionalities.

benchmarks. I will add them to the RFC and inform in the thread when I complete it.

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

I would be fully in favour of this RFC, but there is 1 hurdle which cant be ignored. What should the PHP naming convention be for these? Without deciding on what it should be we would be creating a new issue of mix-mash of uppercase, lowercase and camelcase classes for example Few examples - DateTime is documented as Camelcase - https://www.php.net/manual/en/class.datetime.php - PDO is documented as uppercase - https://www.php.net/manual/en/class.pdo.php - mysqli is documentated as lowercase - https://www.php.net/manual/en/set.mysqlinfo.php - ArrayAccess is documented as camelcase - https://www.php.net/manual/en/class.arrayaccess.php PHP mixing case of definitions, at least with current system, users can choose their preferred convention and it will work. If we change to be case sensitive, we risk introducing a giant headache for devs, as they need to remember what different casing each different builtin class is. It will become a the new `($haystack, $needle)` - `($needle, $haystack)` problem, and won't gain love from the community. On Wed, 17 Jun 2026 at 01:03, Jorg Sowa <jorg.sowa@gmail.com> wrote:

On 2026-06-17 03:03, Jorg Sowa wrote:

Hey, 1. I don't think it's necessary to mess with ::class here. People are used to it not doing any checks. If it started doing some checks it would get confusing: why does it tell me if the case is wrong but says nothing if the class doesn't exist? And the warning is fired conditionally on whether the class is already loaded or not, which, according to RFC, is not a cool behaviour. Besides that wrong case warning would disappear and go back to silent in PHP 9.0, right? 2. Is the end goal in PHP 9.0 such that ActivityLog and Activitylog could both be defined as separate classes? And I can define my own StdClass? Or would definitions that only differ by case still be separate? BR, Juris

On Tue, Jun 16, 2026, at 7:03 PM, Jorg Sowa wrote:

Is there a practical, real-world issue this solves? I have never in my life seen someone write STRLEN(). Drupal used to use TRUE/FALSE instead of true/false, but I don't know if they've ever changed that and it doesn't hurt anything. Class names everyone should already be treating as case sensitive because of the file system. And IDEs and SA tools have been pushing toward the "standard" casing of things for decades. I don't really see this as an issue to solve. But I can see where it could cause issues when making dynamic method calls, like $controller->$httpMethod($request), which is something a number of smaller frameworks have done for years. So I'm -1 at this point. --Larry Garfield

I think this is a good idea, however I think some care needs to be taken so that it doesn't impose a significant burden on end users compared to the benefit returned. In respect to the exact detail: * 2.9: As already noted by Juris, I also disagree with changing `::class` resolution to have magic behaviour based on if the class exists or not (at the time of the usage) - I would prefer keeping that as a static transformation and raising the deprecation if the string is used. * 2.37: The example is a little unclear; could the example be updated to include the actual class instantiation / function call; and confirm if the error message references the line of the call site / the line of the use statement / both? Further to this, just to confirm it is correct; there is no difference in the error message when a use statement is/isn't present? * 2:37: When I read 'The as alias itself is not checked: use MyApp\Service\UserService as US is fine regardless of what US is. Only the namespace path being imported is validated.' then I interpreted that as it would mean that in the code the developer could do `new us();` - is that correct? If not, it might be worth just reviewing the wording. * 2.39 / 2.40: I don't agree with this in the initial version - it makes sense to do but I would prefer this as a future change. Initially I would suggest that unserialize continues to work without a deprecation / error - the update that a developer would need to do in response to the deprecation occurring (for data still serialized) would either be having a script that unserializes and then reserializes the data just to correct the case, manual editing the data, or ignoring/suppression the deprecation; none of which seem particularly useful against the harm by having a special case when unserialzing data. (Note this relies on prohibiting multiple items with the same name but different case for a period from my general feedback) * 2.41: My SOAP knowledge is a bit rusty; but from memory then naming on the SOAP side are case sensitive; but if I am incorrect here then I would not enforce case sensitivity on the PHP side either (as the types could change on the server side with no ill effect) General: * What change is there to the default implementation for `__autoload` (https://www.php.net/manual/en/function.spl-autoload.php)? Currently this will load class names with any case as long as the PHP files are lowercase in the file system (or a case insensitive file system is used). * Would a function that can normalize the case of items currently case insensitive be useful to introduce alongside this (where the item exists in the symbol tables of course)? My thoughts are for compatibility with code you don't control - if a third party library intends to change their internal casing following this change; a developer may want to be able to use a proxy for accessing their resources that allows the old casing to work without raising the deprecations (or errors in PHP9) once the update is released without needing to immediate update the first party code. (This could be done in userland, but I would expect it would be more efficient to do in the engine) * For some internal classes/functions which don't follow the expected rules, should aliases be introduced (or the deprecations suppressed during the deprecation stage). Although I rarely use it myself, I only realised when reviewing this RFC that 'stdClass' is not 'StdClass' for instance. * I would suggest that for PHP9.0 then having multiple items (or at a minimum then autoloadable items) with the same name but with different casing is prohibited. I would be concerned of much harder to detect issues if PHP8.6 introduces the deprecation and then PHP9.0 (assuming that was the next release after 8.6) then removed the deprecation and allowed you to define the classes 'Foo' and 'foo' that a significant number of users would upgrade from PHP8.5 to PHP9.0 and manage to end up with different items that they expect are the same. I wouldn't have an issue allowing it in PHP10; or given the motivations given so far for the change keeping this prohibted. Robert On Thu, Jun 18, 2026 at 8:14 AM Jorg Sowa <jorg.sowa@gmail.com> wrote:

Hi Jorg, thank you for the RFC, and for taking the time to identify a whole list of things that should be looked at for normalising. It looks like a useful reference.

This is objectively terrible behaviour. But changing it would break so much code, in such subtle ways that I don't think it would be acceptable for the current distribution to change. The current distribution is also somewhat terrible. Not even through bad design, just through choices made in an era where software was still often shipped on disk, and compiling PHP took overnight. So you get things happen such, as setting the "C" locale to France results with invalid SVG files being generated. I think it's probably worth discussing a new distribution, which would be an opportunity for cleanups like this. I also think that PHP is not a good "my first programming language". I find it hard to imagine newbies pushing through the difficult bit of getting started, to build something cool to show their friends. cheers Dan Ack