Table of Contents

PHP RFC: Case-sensitive PHP

Introduction

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.

Proposal

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 {}
    }
}
 
?>

Examples

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";
 
?>

Backward Incompatible Changes

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:

Proposed PHP Version(s)

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”.

RFC Impact

To the Ecosystem

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

To Existing Extensions

Will existing extensions be affected?

To SAPIs

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

Open Issues

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

Future Scope

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.

Voting Choices

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:

Implement $feature as outlined in the RFC?
Real name Yes No Abstain
Final result: 0 0 0
This poll has been closed.

Patches and Tests

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.

Implementation

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

References

Links to external references, discussions, or RFCs.

Rejected Features

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

Changelog

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.