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
On Wed, 17 Jun 2026 at 01:04, Jorg Sowa <jorg.sowa@gmail.com> 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:
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
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:
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
On 17/06/2026 13:30, fennic log wrote:
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 - PHP: Preface - Manual class.datetime.php <https://www.php.net/manual/en/class\.datetime\.php>
- PDO is documented as uppercase - PHP: Preface - Manual class.pdo.php <https://www.php.net/manual/en/class\.pdo\.php>
- mysqli is documentated as lowercase - PHP: Preface - Manual set.mysqlinfo.php <https://www.php.net/manual/en/set\.mysqlinfo\.php>
- ArrayAccess is documented as camelcase - PHP: Preface - Manual en/class.arrayaccess.php <PHP: Preface - Manual 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.
There are already policies for that:
As for the existing stuff that you mention, we already have this casing salad anyway even if we simply follow IDE autocomplete
--
Anton
On Wed, Jun 17, 2026, at 12:30, fennic log wrote:
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:
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
I honestly can’t think of anything good that this RFC would bring. It would bring this cased salad into every code base and require changing code if you use a consistent casing throughout your code base. Just so that person and Person are different? That just sounds confusing to me.
I’m not sure the gain — which I’m also unsure what the gain even is — is worth it.
— Rob
On 2026-06-17 03:03, Jorg Sowa 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
Hey,
Besides that wrong case warning would disappear and go back to silent
in PHP 9.0, right?
BR,
Juris
On 17/06/2026 16:59, Juris Evertovskis wrote:
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?
I agree, that #2.9.2 is basically a string constant not really related to the class itself, adding a check is not beneficial. If that string is used to initiate a class, there will be some another warning from this RFC about it anyway.
--
Anton
On Wed, 17 Jun 2026 at 11:47, Anton Smirnov <sandfox@sandfox.me> wrote:
As for the existing stuff that you mention, we already have this casing
salad anyway even if we simply follow IDE autocomplete
Yes we do, hence why I would love for this RFC to pass and the standard library be unified by the standards you linked.
However, unless compromise is made to do so this RFC would cause more problems than it solves.
I think this is really down to a case where PHP has held onto too much legacy problems, and attempts to fix those problems cause more problems.
For userland definitions I think this can be adapted quickly to that subsection, because ideally developers should be following the documentation.
It doesn’t break PHP, it breaks incorrect implementations of userland code and helps enforce good developer behaviour, such as following the definition
Eg, if the developer defines \Movies\ILike\Moneyball and then the implementer uses \movies\ilike\MoneyBall` then I can agree, that should generate an error
Implementations like this: https://3v4l.org/FQKLq I 100% agree, should not be possible.
But for internal PHP definitions I’m not sure what a solution would be which does not completely havoc.
On Tue, Jun 16, 2026, at 7:03 PM, Jorg Sowa 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: PHP: rfc:case_sensitive_php
Kind regards,
Jorg
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
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.
I think end users see no problem being solved here. And that's okay.
However, this change helps the engine (and any tool that deals with
PHP symbol definitions, analyzers, LSPs, etc.) by making symbol
management easier, as it removes the need for a folding pass required
on every identifier encountered.
This also helps make PHP more consistent, first, with other
programming languages, and secondly, with itself, since constants in
PHP are already case-sensitive, so making everything behave the same
is a win.
And as you said, no one writes `STRLEN`, and people write code
assuming that the casing they are using is correct per definition, not
for style reasons. The deprecation phase would help people spot
incorrect casings in their application for now, until the 9.0 upgrade.
Cheers,
Seifeddine.
Thanks for all opinions. I will apply all changes in coming days to the RFC content.
Is there a practical, real-world issue this solves?
Portability of the autoloading. I had a case in the past where my wrongly cased namespace didn’t cause any problem locally, but it failed in the production because of different OS. This is real world-issue.
However, this problem touches only namespaces and class names. If the RFC would be only for namespaces and classes would you be in favor of this RFC? It appeared in previous discussions to put all or nothing into such RFC, so I went along the lines, but I’m okay with dropping methods and functions. However, if RFC function autoloading would pass, we would have the same problem with functions.
Kind regards,
Jorg
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`
(PHP: spl_autoload - Manual)? 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:
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: PHP: rfc:case_sensitive_php
Kind regards,
Jorg
On Wed, Jun 17, 2026 at 10:11 PM Larry Garfield <larry@garfieldtech.com> wrote:
Is there a practical, real-world issue this solves? I have never in my life seen someone write STRLEN().
I've seen quite a few casing mismatches in practice, intentionally
added for readability, especially in calls to GD functions.
`ImageColorAllocateAlpha()` does read better than
`imagecolorallocatealpha()`.
--
Best regards,
Bruce Weirdan mailto:weirdan@gmail.com
On Thu, Jun 18, 2026, 08:15 Bruce Weirdan <weirdan@gmail.com> wrote:
I’ve seen quite a few casing mismatches in practice, intentionally
added for readability, especially in calls to GD functions.
ImageColorAllocateAlpha()does read better than
imagecolorallocatealpha()
I would love to see normalizing function and class name casing (functions in camelCase, classes in PascalCase) happen at the same time as case sensitivity.
If we are forcing devs to search and replace in their codebases, it would make sense to get the most value we can out of it.
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.
Array keys “key” != “Key”
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
On Wed, 17 Jun 2026 at 11:33, fennic log <fenniclog@gmail.com> wrote:
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?
I absolutely can ignore that.
While consistency is nice, it is not valuable by itself.
Most people who are still writing code by hand, use IDEs with autocomplete. And I doubt LLMs care.
Just leaving whatever TyPoGraphy that is currently in the source code, and ignoring any inconsistency is almost certainly the correct choice.
cheers
Dan
Ack
On Thursday 18 June 2026 08:55:10 (+02:00), Jorg Sowa wrote:
> Thanks for all opinions. I will apply all changes in coming days to the RFC
> content.
> > > Is there a practical, real-world issue this solves?
> > Portability of the autoloading. I had a case in the past where my wrongly
> cased namespace didn't cause any problem locally, but it failed in the
> production because of different OS. This is real world-issue.
>
Well, not in PHP AFAIK.
SPL class autoloading was designed under portability
principles and properly vetted in this regard, from top
of my head since it's incarnation in PHP 5.1.
So I'd be highly interested where PHP's standard class
autoloading has this "real world-issue" in its collation.
E.g. did you use a specific PHP script to generate the
dynamic include instructions?
Or were those templated by some specific PHP script, or
were you implementing or inheriting a specific framework
that makes use of PHP scripts etc. that undermined
standard stability and portability principles in software
and system design?
More context warmheartly appreceated.
Best,
--hakre
E.g. did you use a specific PHP script to generate the
dynamic include instructions?
Yes, I used composer packager.
I’m sorry, but I’m going to stop work on this RFC. I see very little chance it passing,
so I want to spend time more efficiently. I spent already a lot of time on it, and if anyone
wants to continue it, feel free to do it. I hope you understand.
Kind regards,
Jorg