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 <[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
