PHP RFC: Case-sensitive PHP

• Version: 1.0
• Date: 2026-06-01
• Author: Jorg Sowa jorg.sowa@gmail.com
• Status: Draft
• Implementation: https://github.com/...
• Discussion thread: TBD
• Voting thread: TBD

PHP has always treated function, method, and class names as case-insensitive. That was a reasonable early design decision, but it now creates inconsistency without much benefit.

All the features and examples of the proposal.

To paraphrase Zeev Suraski, explain how the proposal brings substantial value to be considered for inclusion in one of the world's most popular programming languages.

Please clearly specify the desired syntax and semantics of your proposal, for example the interactions with existing PHP functionality, and please mention all edge cases, including potential gotchas.

Include stubs for newly introduced functions classes and constants, including namespaces and types.

<?php
 
namespace Example\Component {
    final class NewAddition {
        public static function fromString(string $example): self {}
    }
}
 
?>

Remember that the RFC contents should be easily reusable in the PHP Documentation. This means, if at all possible, they should be runnable as standalone, self-contained code with the proof-of-concept implementation.

Simple example:

<?php
 
echo "First example";
 
?>

Example showing an edge case:

<?php
 
echo "Edge case";
 
?>

What breaks, and what is the justification for it?

Please include all breaking changes, no matter how minor they might appear. All research you did on potential impact should be listed in this section.

For adding new functions, classes or keywords, here are some possibilities to measure potential impact:

• A script from nikic that checks the top 1000 Composer packages https://gist.github.com/nikic/a2bfa3e2f604f66115c3e4b8963a6c72
• GitHub regexp search
• https://grep.app/
• https://about.sourcegraph.com/

List the proposed PHP versions that the feature will be included in. Use relative versions such as “next PHP 8.x” or “next PHP 8.x.y”.

What effect will the RFC have on IDEs, Language Servers (LSPs), Static Analyzers, Auto-Formatters, Linters and commonly used userland PHP libraries?

Will existing extensions be affected?

Describe the impact to CLI, Development web server, embedded PHP etc.

Make sure there are no open issues when the vote starts!

This section should outline areas that you are not planning to work on in the scope of this RFC, but that might be iterated upon in the future by yourself or another contributor.

This helps with long-term planning and ensuring this RFC does not prevent future work.

Pick a title that reflects the concrete choice people will vote on.

Please consult the php/policies repository for the current voting guidelines.

Primary Vote requiring a 2/3 majority to accept the RFC:

Links to proof of concept PR.

If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.

After the RFC is implemented, this section should contain:

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

Links to external references, discussions, or RFCs.

Keep this updated with features that were discussed on the mail lists.

If there are major changes to the initial proposal, please include a short summary with a date or a link to the mailing list announcement here, as not everyone has access to the wikis' version history.