PHP Wiki

explicit_this_parameter - Update for handling of optional parameters in PFA

timwolla (timwolla@undisclosed.example.com) — 2026-05-31T13:02:54+00:00

2026/04/07 15:29		current
Line 312:		Line 312:
	==== Partial Function Application ====		==== Partial Function Application ====

-	The <php>this:</php> argument may be combined with partial function application to create a partial function where the “object instance” will be filled in at call time. Specifying the <php>this:</php> argument outside the left-most position is particularly useful for partial function application, since it allows to specify the position of the object instance parameter relative to regular parameters. If a variadic placeholder is specified it must come last.	+	The <php>this:</php> argument may be combined with partial function application to create a partial function where the “object instance” will be filled in at call time. Specifying the <php>this:</php> argument outside the left-most position is particularly useful for partial function application, since it allows to specify the position of the object instance parameter relative to regular parameters.

	<PHP>		<PHP>
Line 328:		Line 328:
	$c = static fn (DateTimeImmutable $this, int $timestamp): DateTimeImmutable		$c = static fn (DateTimeImmutable $this, int $timestamp): DateTimeImmutable
	=> $this->setTimestamp($timestamp);		=> $this->setTimestamp($timestamp);
-
-	// and
-
-	$c = DateTimeImmutable::setTimestamp(this: ?, ...);
-	// is effectively equivalent to:
-	$c = static fn (DateTimeImmutable $this, int $timestamp): DateTimeImmutable
-	=> $this->setTimestamp($timestamp, ...array_slice(func_get_args(), 2));

	// but		// but
Line 345:		Line 338:
	</PHP>		</PHP>

-	If the <php>$this</php> parameter is placed after optional parameters, they will become required.	+	Specifying a variadic placeholder when using <php>this:</php> is not allowed.

	<PHP>		<PHP>
-	$c = DateTimeImmutable::setTime(this: ?, ?, ?, ?, ?);	+	$c = DateTimeImmutable::setTimestamp(this: ?, ...); // Not allowed.
-	// is effectively equivalent to:	+
-	$c = static fn (DateTimeImmutable $this, int $hour, int $minute, int $second = 0, int $microsecond = 0): DateTimeImmutable	+
-	=> $this->setTime($hour, $minute, $second, $microsecond);	+
-		+
-	// but	+
-		+
-	$c = DateTimeImmutable::setTime(?, ?, ?, ?, this: ?);	+
-	// is effectively equivalent to:	+
-	$c = static fn (int $hour, int $minute, int $second, int $microsecond, DateTimeImmutable $this): DateTimeImmutable	+
-	=> $this->setTime($hour, $minute, $second, $microsecond);	+
	</PHP>		</PHP>
		+

	=== From Within The Class ===		=== From Within The Class ===
Line 597:		Line 581:
	===== Changelog =====		===== Changelog =====

-	* 2026-03-19: Initial version	+	* 2026-05-31: Initial version

case_sensitive_php

jorg_sowa (jorg_sowa@undisclosed.example.com) — 2026-05-30T21:53:21+00:00

2026/05/29 22:14		current
Line 12:		Line 12:
	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.		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 =====	+	Today, all of these are valid PHP:
-	All the features and examples of the proposal.	+

-	To [[http://news.php.net/php.internals/66051\|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.	+	<code php>
		+	strlen("hello") // canonical
		+	STRLEN("hello") // works
		+	StrLen("hello") // also works
		+	</code>

-	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.	+	Same with classes:

-	Include stubs for newly introduced functions classes and constants, including namespaces and types.	+	<code php>
		+	new MyClass() // canonical
		+	new MYCLASS() // works
		+	new myclass() // also works
		+	</code>

-	<PHP>	+	This RFC proposes emitting ''E_DEPRECATED'' warnings in PHP 8.6 when functions, methods, or classes are referenced with incorrect casing. The goal is to give developers and tools time to adapt before a potential hard break in the next major version.
-	<?php	+

-	namespace Example\Component {	+	==== Case sensitivity in PHP today ====
-	final class NewAddition {	+
-	public static function fromString(string $example): self {}	+
-	}	+
-	}	+

-	?>	+	PHP is already partially case-sensitive. This RFC addresses the remaining inconsistencies. Here is the full picture:
-	</PHP>	+

-	==== Examples ====	+	Case-insensitive (as of PHP 8.5):
-	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:	+	^ Identifier ^ Note ^
-	<PHP>	+	\| Function names (user-defined and built-in) \| deprecated by this RFC \|
-	<?php	+	\| Method names \| deprecated by this RFC \|
		+	\| Class, interface, and trait names \| deprecated by this RFC \|
		+	\| Magic method names (''%%__construct%%'', ''%%__toString%%'') \| deprecated by this RFC \|
		+	\| Namespace names in class references and ''use'' imports \| deprecated by this RFC \|
		+	\| ''namespace'' declarations (inconsistent casing across files) \| deprecated by this RFC \|
		+	\| Keywords (''if'', ''else'', ''for'', ''while'', ''class'', ...) \| \|
		+	\| ''true'', ''false'', ''null'' \| \|

-	echo "First example";	+	Case-sensitive (already enforced):

-	?>	+	^ Identifier ^ Example ^
-	</PHP>	+	\| Variables \| ''$foo'' != ''$Foo'' \|
		+	\| Constants \| ''FOO'' != ''foo'', fatal error on mismatch \|
		+	\| Object properties \| ''$obj->name'' != ''$obj->Name'' \|
		+	\| Array keys \| ''"key"'' != ''"Key"'' \|
		+	\| Enum cases \| ''Color::Red'' != ''Color::red'', fatal error \|
		+	\| Goto labels \| ''myLabel'' != ''MYLABEL'' \|

-	Example showing an edge case:	+	After this RFC is fully enforced in the next major version, all user-defined identifiers in PHP will be case-sensitive. The remaining case-insensitive constructs will all be language-defined: control-flow keywords (''if'', ''while'', ''match'', etc.), built-in type names in type declarations (''int'', ''string'', ''bool'', ''void'', etc.), the special class references ''self'', ''parent'', and ''static'', and the literals ''true'', ''false'', ''null''.
-	<PHP>	+
-	<?php	+

-	echo "Edge case";	+	==== 1.2 Language comparison ====
		+
		+	PHP is one of the few remaining languages that does not enforce case sensitivity for user-defined identifiers.
		+
		+	^ Language ^ Case-sensitive? ^ Notes ^
		+	\| [[https://docs.python.org/3/reference/lexical_analysis.html#identifiers\|Python]] \| Yes \| \|
		+	\| [[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar\|JavaScript]] \| Yes \| \|
		+	\| [[https://www.typescriptlang.org/docs/handbook/2/basic-types.html\|TypeScript]] \| Yes \| \|
		+	\| [[https://ruby-doc.org/docs/ruby-doc-bundle/Manual/man-1.4/syntax.html\|Ruby]] \| Yes \| Capitalized identifiers are constants \|
		+	\| [[https://go.dev/ref/spec#Exported_identifiers\|Go]] \| Yes \| Case determines visibility: uppercase = exported (public), lowercase = unexported (private) \|
		+	\| [[https://doc.rust-lang.org/reference/identifiers.html\|Rust]] \| Yes \| Compiler warns on convention violations (''snake_case'' vs ''CamelCase'') \|
		+	\| [[https://docs.oracle.com/javase/specs/jls/se21/html/jls-3.html#jls-3.8\|Java]] \| Yes \| \|
		+	\| [[https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/lexical-structure\|C#]] \| Yes \| Guidelines discourage names differing only in case (CLR interop) \|
		+	\| [[https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure\|Swift]] \| Yes \| \|
		+	\| [[https://kotlinlang.org/spec/syntax-and-grammar.html\|Kotlin]] \| Yes \| \|
		+	\| [[https://perldoc.perl.org/perlsyn\|Perl]] \| Yes \| \|
		+	\| [[https://www.lua.org/manual/5.4/manual.html#3.1\|Lua]] \| Yes \| \|
		+	\| [[https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Identifiers\|R]] \| Yes \| \|
		+	\| [[https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/declared-elements/declared-element-names\|Visual Basic / VBA]] \| No \| Classic VB (1991) and VB.NET (2002); IDE normalizes casing for display \|
		+	\| [[https://www.freepascal.org/docs-html/ref/refse5.html\|Pascal / Delphi]] \| No \| Case-insensitive since the 1970s \|
		+	\| [[https://www.ibm.com/docs/en/cobol-zos/6.4?topic=structure-user-defined-words\|COBOL]] \| No \| Keywords and identifiers only; string literals are case-sensitive \|
		+	\| [[https://helpx.adobe.com/coldfusion/developing-applications/the-cfml-programming-language/elements-of-cfml/about-cfml-variables.html\|ColdFusion / CFML]] \| No \| 1995; tags, functions, and variable names are case-insensitive \|
		+	\| [[https://learn.microsoft.com/en-us/powershell/scripting/lang-spec/chapter-03?view=powershell-7.4#312-identifiers\|PowerShell]] \| No \| 2006; cmdlets, functions, and variable names are case-insensitive \|
		+	\| PHP (pre-8.6) \| No (partial) \| See section 1.1 \|
		+
		+	Among general-purpose languages with broad industry adoption, case sensitivity is the norm. Go is the most instructive: it did not just enforce consistent casing, it made the first letter semantically meaningful (access control). PHP cannot reasonably do that at this stage, but removing the implicit lowercasing brings it in line with the mainstream.
		+
		+	The case-insensitive languages in the table split into two groups. Pascal, Delphi, COBOL, and classic Visual Basic predate PHP 3 (1997) and established the convention PHP inherited. ColdFusion (1995) and PowerShell (2006) are domain-specific tools — a web templating language and a shell — where the case-insensitive tradition carried over from earlier scripting environments. VB.NET (2002) postdates PHP 3 but is the direct successor of classic Visual Basic and retains the behavior for backward compatibility. None of these languages are the general-purpose, server-side peers PHP competes with today.
		+
		+	==== 1.3 PSR-4 autoloading and filesystem portability ====
		+
		+	PHP's case-insensitive class lookup interacts badly with [[https://www.php-fig.org/psr/psr-4/\|PSR-4 autoloading]] and filesystem case sensitivity in a way that hides bugs during development and surfaces them in production.
		+
		+	PSR-4 maps a fully-qualified class name directly to a file path: ''App\Service\UserService'' → ''app/Service/UserService.php''. The autoloader constructs that path from the class name as written at the call site, then opens the file. Whether that file open succeeds depends entirely on the filesystem.
		+
		+	^ Environment ^ Filesystem ^ ''new app\service\USERSERVICE()'' ^
		+	\| Linux (production) \| ext4, btrfs (case-sensitive) \| Autoloader fails — file not found \|
		+	\| macOS (developer) \| HFS+ / APFS case-insensitive (default) \| Autoloader succeeds — file found \|
		+	\| Windows (developer) \| NTFS (case-insensitive) \| Autoloader succeeds — file found \|
		+
		+	The result is a class of bugs that passes silently on developer machines and breaks only on Linux servers. A wrong-cased ''new APP\SERVICE\USERSERVICE()'' works fine locally, passes CI if CI also runs on macOS or Windows, and then throws a fatal error on the production host.
		+
		+	There is a second subtlety: if the class is already in PHP's class registry (loaded earlier in the same request via a correctly-cased reference), PHP's case-insensitive lookup resolves the wrong-cased reference without ever calling the autoloader. That makes the bug intermittent — it disappears when the class happens to be loaded first by another code path, and reappears when the execution order changes.
		+
		+	This RFC's deprecation warning fires at the PHP engine level regardless of whether the autoloader was involved, which catches both cases.
		+
		+	===== 2. Proposal =====
		+
		+	Emit ''E_DEPRECATED'' when any of the following identifiers are referenced with incorrect casing:
		+
		+	Calls (2.1–2.3)
		+	* Function calls — user-defined and built-in (section 2.1)
		+	* Method calls — instance methods, including dynamic calls (section 2.2)
		+	* Static method calls (section 2.3)
		+
		+	Language constructs (2.4–2.11)
		+	* Class instantiation via ''new'' (section 2.4)
		+	* Namespace segments in class references (section 2.5)
		+	* ''instanceof'' checks (section 2.6)
		+	* Type declarations — parameter types, return types, and property types (section 2.7)
		+	* Catch clauses (section 2.8)
		+	* ''extends'' — wrong-cased parent class name (section 2.9)
		+	* ''implements'' — wrong-cased interface name (section 2.10)
		+	* ''use'' — wrong-cased trait name in a class body (section 2.11)
		+
		+	Callables and dynamic dispatch (2.12–2.13)
		+	* Callable class names — array callables ''["ClassName", "method"]'' and string callables ''"ClassName::method"'' (section 2.12)
		+	* ''Closure::bind()'' and ''bindTo()'' — wrong-cased scope class name (section 2.13)
		+
		+	Class and function introspection (2.14–2.19)
		+	* ''class_exists()'', ''interface_exists()'', ''trait_exists()'', ''enum_exists()'' (section 2.14)
		+	* ''class_alias()'' — wrong-cased original class name (section 2.15)
		+	* ''is_a()'' and ''is_subclass_of()'' — wrong-cased class name argument (section 2.16)
		+	* ''class_parents()'', ''class_implements()'', ''class_uses()'' — wrong-cased class name (section 2.17)
		+	* ''property_exists()'' — wrong-cased class name string (section 2.18)
		+	* ''method_exists()'' — wrong-cased class name string (section 2.19)
		+
		+	Reflection API (2.20–2.31)
		+	* ''ReflectionClass'' constructor — wrong-cased class name argument (section 2.20)
		+	* ''ReflectionAttribute::newInstance()'' — wrong-cased attribute class name (section 2.21)
		+	* ''ReflectionFunction'' constructor — wrong-cased function name (section 2.22)
		+	* ''ReflectionMethod'' constructor — wrong-cased class name (section 2.23)
		+	* ''ReflectionProperty'' constructor — wrong-cased class name (section 2.24)
		+	* ''ReflectionClassConstant'' constructor — wrong-cased class name (section 2.25)
		+	* ''ReflectionClass::isSubclassOf()'' — wrong-cased class name (section 2.26)
		+	* ''ReflectionClass::implementsInterface()'' — wrong-cased interface name (section 2.27)
		+	* ''ReflectionClass::getAttributes()'' with ''IS_INSTANCEOF'' — wrong-cased class name (section 2.28)
		+	* ''ReflectionParameter'' constructor — wrong-cased class name in array callable (section 2.29)
		+	* ''ReflectionProperty::isReadable()'' and ''isWritable()'' — wrong-cased scope class name (section 2.30)
		+	* ''ReflectionClass::getProperty()'' with ''"ClassName::$prop"'' syntax — wrong-cased class name prefix (section 2.31)
		+
		+	Declarations (2.32–2.34)
		+	* Magic method declarations — declaring ''%%__CONSTRUCT%%'', ''%%__toString%%'', ''%%__sleep%%'', etc. with wrong case (section 2.32)
		+	* File-level ''use'' imports — wrong-cased class or namespace path in ''use'', ''use function'', and ''use const'' declarations (section 2.33)
		+	* ''namespace'' declarations — inconsistent namespace casing across files in the same namespace (section 2.34)
		+
		+	Serialization (2.35–2.36)
		+	* ''unserialize()'' — wrong-cased class or enum name in serialized object/enum data (section 2.35)
		+	* ''ArrayObject::%%__unserialize%%()'' — wrong-cased iterator class name in serialized data (section 2.36)
		+
		+	Extensions and SPL (2.37–2.42)
		+	* ''SoapServer''/''SoapClient'' classmap — wrong-cased PHP class name in ''classmap'' option (section 2.37)
		+	* ''ArrayObject::setIteratorClass()'' — wrong-cased iterator class name (section 2.38)
		+	* ''IteratorIterator'' and ''RecursiveIteratorIterator'' — wrong-cased inner iterator class cast (section 2.39)
		+	* ''stream_filter_register()'' — wrong-cased filter class name (section 2.40)
		+	* ''PDO::ATTR_STATEMENT_CLASS'' — wrong-cased statement class name (section 2.41)
		+	* ''PDOStatement::setFetchMode(PDO::FETCH_CLASS)'' — wrong-cased fetch class name (section 2.42)
		+
		+	==== Examples ====

-	?>
	</PHP>		</PHP>

-	===== Backward Incompatible Changes =====	+	===== 3. 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.	+	==== 3.1 Deprecation warnings emitted (not errors) ====

-	For adding new functions, classes or keywords, here are some possibilities to measure potential impact:	+	In PHP 8.6, this is a deprecation warning only. Code continues to work exactly as before. Developers using incorrect casing will see warnings when running with ''error_reporting(E_ALL)''.

-	* A script from nikic that checks the top 1000 Composer packages https://gist.github.com/nikic/a2bfa3e2f604f66115c3e4b8963a6c72	+	^ Version ^ Behavior ^
-	* GitHub regexp search	+	\| PHP 8.5 \| ''STRLEN()'' works silently \|
-	* https://grep.app/	+	\| PHP 8.6 \| ''STRLEN()'' works, but emits ''E_DEPRECATED'' \|
-	* https://about.sourcegraph.com/	+	\| PHP 9.0 \| May become ''E_ERROR'' (not guaranteed; requires separate RFC) \|

-	===== Proposed PHP Version(s) =====	+	==== 3.2 Who is affected? ====
-	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".	+
		+	Only code that calls functions/methods or references classes with non-canonical casing.
		+
		+	Affected: ''STRLEN()'', ''new FOO()'', ''$obj->MyMethod()'' when the method is ''myMethod()'', ''$ex instanceof myexception'', wrong-cased type hints, ''new \myapp\service\UserService()'' with wrong-cased namespace, ''use myapp\Service\UserService;'' imports, and ''namespace MYAPP\Service;'' declarations that conflict with ''MyApp\Service'' declared elsewhere.
		+
		+	Not affected: any code following [[https://www.php-fig.org/psr/psr-12/\|PSR-12]], [[https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/\|WordPress]], [[https://laravel.com/docs/master/contributions#coding-style\|Laravel]], or [[https://symfony.com/doc/current/contributing/code/standards.html\|Symfony]] conventions — and anything written with IDE autocomplete.
		+
		+	==== 3.3 Impact analysis ====
		+
		+	Mixed-casing issues appear primarily in older codebases. Modern frameworks enforce correct casing already, and anything running a recent PHPStan or PHP-CS-Fixer config will have caught these before this RFC fires.
		+
		+	===== 4. Proposed PHP version(s) =====
		+
		+	Target: PHP 8.6
		+
		+	* Emit ''E_DEPRECATED'' warnings
		+	* Gives developers and tools time to adapt
		+
		+	Future evolution (not part of this RFC):
		+
		+	PHP 9.0:
		+	* Consider making case-insensitivity an error
		+	* Requires a separate vote

	===== RFC Impact =====		===== 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?	+	==== Tooling ====
		+
		+	Several tools already flag incorrect casing. Once PHP itself emits ''E_DEPRECATED'', teams have a runtime-backed reason to treat these as CI failures rather than style nits.
		+
		+	PHPStan reports class, function, method, static method, interface, trait, and enum name case mismatches via error identifiers such as [[https://phpstan.org/error-identifiers/class.nameCase\|class.nameCase]] and [[https://phpstan.org/error-identifiers/function.nameCase\|function.nameCase]]. The relevant config options (''checkInternalClassCaseSensitivity'', ''checkFunctionNameCase'') are off by default but enabled by the [[https://github.com/phpstan/phpstan-strict-rules\|phpstan/phpstan-strict-rules]] extension.
		+
		+	PHP-CS-Fixer has two dedicated fixers: [[https://cs.symfony.com/doc/rules/casing/native_function_casing.html\|native_function_casing]] and [[https://cs.symfony.com/doc/rules/casing/class_reference_name_casing.html\|class_reference_name_casing]]. Both are included in the ''@PhpCsFixer'' and ''@Symfony'' rulesets.
		+
		+	PhpStorm has a built-in inspection [[https://www.jetbrains.com/help/inspectopedia/PhpMethodOrClassCallIsNotCaseSensitiveInspection.html\|PhpMethodOrClassCallIsNotCaseSensitiveInspection]] that fires on functions, methods, classes, and namespaces called with different casing than their declarations. It is enabled by default.
		+
		+	Psalm does not yet implement case-sensitivity detection natively ([[https://github.com/vimeo/psalm/issues/1174\|issue #1174]] from 2019 remains open). A sample plugin is available in the Psalm repository for teams that need it sooner.
		+
		+	PHPCS enforces lowercase PHP keywords via [[https://github.com/squizlabs/PHP_CodeSniffer/blob/master/src/Standards/Generic/Sniffs/PHP/LowerCaseKeywordSniff.php\|Generic.PHP.LowerCaseKeyword]] but has no sniff for user-defined identifier casing.
		+
		+	Modern frameworks already enforce consistent casing. Well-maintained libraries and extensions are unaffected. Warnings appear in error logs as usual and behavior is identical across all SAPIs (CLI, CGI, FPM, embedded).
		+
		+	==== Performance ====
		+
		+	PHP currently lowercases function, method, class, and namespace names at every call site before the hash-table lookup. Once case-insensitive lookup is removed in PHP 9.0, that ''tolower'' step disappears from the hot path entirely. The gain per call is small, but it applies to every function, method, and namespaced class reference in every request.

	==== To Existing Extensions ====		==== To Existing Extensions ====
-	Will existing extensions be affected?	+

	==== To SAPIs ====		==== To SAPIs ====
-	Describe the impact to CLI, Development web server, embedded PHP etc.	+

	===== Open Issues =====		===== Open Issues =====
-	Make sure there are no open issues when the vote starts!	+

	===== Future Scope =====		===== 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.	+	Make case-insensitivity an error in PHP 9.0.

	===== Voting Choices =====		===== Voting Choices =====
-	Pick a title that reflects the concrete choice people will vote on.
-
-	Please consult [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting-phase\|the php/policies repository]] for the current voting guidelines.

	----		----
Line 96:		Line 247:
	Primary Vote requiring a 2/3 majority to accept the RFC:		Primary Vote requiring a 2/3 majority to accept the RFC:

-	<doodle title="Implement $feature as outlined in the RFC?" voteType="single" closed="true" closeon="2026-01-01T15:30:00Z">	+	<doodle title="Do you approve of deprecating case-insensitive function, method, namespaces and class references in PHP 8.6?" voteType="single" closed="true" closeon="2026-01-01T15:30:00Z">
	* Yes		* Yes
	* No		* No
Line 108:		Line 259:

	===== Implementation =====		===== Implementation =====
-	After the RFC is implemented, this section should contain:	+	Implementation is in progress.
-	- the version(s) it was merged into	+
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+

	===== References =====		===== References =====
Line 117:		Line 265:

	===== Rejected Features =====		===== Rejected Features =====
-	Keep this updated with features that were discussed on the mail lists.	+	===== 11. Prior art and previous discussions =====
		+
		+	Case sensitivity has come up on php-internals repeatedly since 2003. None of those discussions produced a merged RFC for functions or classes. What they did produce is a clear record of which arguments have been tried, which got traction, and which constraints keep resurfacing.
		+
		+	==== 11.1 PHP Bug #26575 — "Case Sensitive Class Names" (2003) ====
		+
		+	The earliest recorded request. Closed as Won't Fix by Andrey Zmievski: "This will break enormous number of applications." ([[https://bugs.php.net/bug.php?id=26575\|bugs.php.net/bug.php?id=26575]])
		+
		+	==== 11.2 "Complete case-sensitivity in PHP" — php-internals, April 2012 ====
		+
		+	The first serious mailing-list thread. ([[https://externals.io/message/60228\|externals.io/message/60228]])
		+
		+	Key participants: Nikita Popov, Matthew Weier O'Phinney, Yasuo Ohgaki, Galen Wright-Watson.
		+
		+	The thread established several points that still hold: IDE "Go to definition" reliability depends on case sensitivity, Python and Ruby are the correct peer comparisons, and the underlying problem is the ''tolower_map'' in ''zend_operators.c'' which is ASCII-only and would need to be removed rather than extended. Matthew Weier O'Phinney specifically cautioned against runtime ini options that change identifier resolution behavior.
		+
		+	==== 11.3 PHP Bug #62655 — "Request: optional class name case-sensitivity" (2012) ====
		+
		+	A follow-up bug proposing a three-level ''php.ini'' option. Suspended in April 2020 by cmb@php.net as "controversial, requiring internals list discussion." ([[https://bugs.php.net/bug.php?id=62655\|bugs.php.net/bug.php?id=62655]])
		+
		+	==== 11.4 "PHP and case-sensitivity inconsistency" — php-internals, January 2014 ====
		+
		+	([[https://externals.io/message/71592\|externals.io/message/71592]])
		+
		+	Stas Malyshev made the most durable argument from this period: any change must be all-or-nothing. A partial change — deprecating class names but not functions, or vice versa — creates a worse inconsistency than the current uniform behavior. Unicode case-folding was also raised: the ''tolower_map'' is ASCII only, and identifiers using Cyrillic or other scripts behave unpredictably. A ''use strict'' pragma modeled on JavaScript ES5 was proposed as a migration-friendly path; it never advanced.
		+
		+	==== 11.5 RFC: "Make the PHP core case-sensitive" — François Laupretre (2014) ====
		+
		+	([[https://wiki.php.net/rfc/case-sensitivity\|wiki.php.net/rfc/case-sensitivity]])
		+
		+	The only RFC draft ever written on this topic, other than the present one. Proposed making namespaces, classes, interfaces, traits, functions, and non-magic methods all case-sensitive, with keywords becoming lowercase-only. Left incomplete, never voted on, status: Inactive.
		+
		+	==== 11.6 "Proposal for PHP 7: case-sensitive symbols" — php-internals, December 2014 ====
		+
		+	([[https://externals.io/message/79824\|externals.io/message/79824]])
		+
		+	Key participants: François Laupretre (same author as the RFC above), Andrea Faulds, Marco Pivetta, Pierre Joye, Ferenc Kovacs.
		+
		+	Proposed pairing the PHP 7 release with case-sensitivity enforcement (E_STRICT in 7.x, removal in 8.0). The community reaction was mixed: PSR-4 and Linux portability were cited in favor; BC cost and ecosystem disruption dominated the opposition. No change was made in PHP 7.
		+
		+	==== 11.7 RFC: "Deprecate and Remove Case-Insensitive Constants" — Nikita Popov (2018) ====
		+
		+	([[https://wiki.php.net/rfc/case_insensitive_constant_deprecation\|wiki.php.net/rfc/case_insensitive_constant_deprecation]])
		+
		+	The only successful related RFC. Targeted only the ''define()'' third-parameter ''$case_insensitive'' flag. The RFC text explicitly stated: "This is not an attempt to change case sensitivity for other identifiers (functions, classes, etc)." Nikita actively narrowed the discussion to constants when broader changes were proposed in replies. Passed; implemented as PHP 7.3 deprecation and PHP 8.0 removal.
		+
		+	The matching internals thread is at [[https://externals.io/message/100535\|externals.io/message/100535]] (September 2017, Christoph Becker's initial proposal) and [[https://externals.io/message/102389\|externals.io/message/102389]] (June 2018, Nikita's RFC announcement). Sara Golemon supported deprecating constants but said extending the change to functions and classes "would be a much more aggressive movement."
		+
		+	==== 11.8 "Revisiting case-sensitivity in PHP" — php-internals, June 2024 ====
		+
		+	([[https://externals.io/message/123573\|externals.io/message/123573]])
		+
		+	Key participants: Valentin Udaltsov (initiator), Ben Ramsey, Levi Morrison, Gina P. Banyard, Timo Tijhof (Wikimedia).
		+
		+	Udaltsov noted that modern PSR-4 projects and static analyzers already enforce correct casing, so the practical migration burden has shrunk since 2014. Levi Morrison stated PHP 9.0 is the right enforcement target: "This isn't some minor thing squirreled away in a library — this is the core language." Gina P. Banyard raised namespace canonicalization (the class table stores lowercased keys; retrieving the canonical-cased name for the deprecation message requires reading ''ce->name'' rather than the table key).
		+
		+	Two points bear directly on this RFC:
		+
		+	- Serialized PHP 4 data. Timo Tijhof noted that Wikimedia stores PHP 4-era serialized data where class names were written in lowercase. ''class_alias()'' was suggested as a migration path for applications in that situation.
		+	- Nikita Popov's earlier private recommendation. Udaltsov cited Nikita's suggestion to start with "class and class-like names first, then extend to functions" — the same ordering this RFC follows.
		+
		+	No RFC was drafted from this thread. The informal consensus was: PHP 9.0 enforcement, bundling namespaces + classes + functions in a single change rather than staggering them.
		+
		+	==== 11.9 Pull request record ====
		+
		+	Pull requests against [[https://github.com/php/php-src\|php/php-src]] that touch this area. No PR targeting function, method, or class name case has ever been merged; the merged entries all relate to constants.
		+
		+	=== PR #965 — "Output an E_STRICT error on class/function case mismatch" (2014) ===
		+
		+	flaupretre (François Laupretre) · Closed, never merged · [[https://github.com/php/php-src/pull/965]]
		+
		+	A prototype that raised ''E_STRICT'' when a function or class is called with a name that does not match the declaration casing. Explicitly described as "a first step towards deprecating case-insensitive matches for functions and classes (and namespaces)." It was incomplete and closed without review consensus. This is the only prior PR that directly targets function and class name case sensitivity.
		+
		+	=== PR #3321 — "Deprecate case insensitive constants" (2018) ===
		+
		+	nikic (Nikita Popov) · Closed, superseded by a direct commit · [[https://github.com/php/php-src/pull/3321]]
		+
		+	Implements the [[https://wiki.php.net/rfc/case_insensitive_constant_deprecation\|accepted RFC]] deprecating the ''$case_insensitive'' parameter of ''define()''. Scoped strictly to constants; the PR description explicitly excludes functions and classes. Shipped in PHP 7.3 via a separate commit after RFC vote passed.
		+
		+	=== PR #3833 — "Deprecate case-insensitive constants via typelib import" (2019) ===
		+
		+	cmb69 (Christoph M. Becker) · Closed, landed via a different commit · [[https://github.com/php/php-src/pull/3833]]
		+
		+	Extended the PHP 7.3 constant deprecation to the ''com_load_typelib()'' parameter and the ''com.autoregister_casesensitive'' INI setting in ''ext/com_dotnet'', which allowed case-insensitive constant imports from Windows typelibs.
		+
		+	=== PR #3836 — "Remove ability to import case-insensitive constants from typelibs" (2019) ===
		+
		+	cmb69 · Closed · [[https://github.com/php/php-src/pull/3836]]
		+
		+	Companion to #3833 proposing full removal of the ''$case_sensitive'' parameter and INI setting after the behavior was deprecated.
		+
		+	=== PR #9439 — "Do not generate CONST_CS when registering constants" (2022) ===
		+
		+	kocsismate · Merged · [[https://github.com/php/php-src/pull/9439]]
		+
		+	Stopped generating the now-meaningless ''CONST_CS'' flag in stubs when registering constants in extensions. Code-quality cleanup following PHP 8.0 removal.
		+
		+	=== PR #9685 — "Remove unnecessary usage of CONST_CS" (2022) ===
		+
		+	jorgsowa (Jorg Adam Sowa) · Merged · [[https://github.com/php/php-src/pull/9685]]
		+
		+	Cleaned up remaining ''CONST_CS'' flag usage throughout the codebase after case-insensitive constants were removed in PHP 8.0. A follow-up housekeeping PR to the PHP 8 removal.
		+
		+	=== PR #17071 — "Remove unused CONST_CS flag" (2024) ===
		+
		+	DanielEScherzer · Open · [[https://github.com/php/php-src/pull/17071]]
		+
		+	Proposes fully removing the ''CONST_CS'' flag from the API, since it has been unused since PHP 8.0. Still open at the time of writing.
		+
		+	==== Summary ====
		+
		+	^ Year ^ Type ^ Event ^ Outcome ^
		+	\| 2003 \| Bug \| [[https://bugs.php.net/bug.php?id=26575\|#26575]]: request for case-sensitive classes \| Won't Fix \|
		+	\| 2012 \| Thread \| [[https://externals.io/message/60228\|"Complete case-sensitivity in PHP"]] \| No change \|
		+	\| 2012 \| Bug \| [[https://bugs.php.net/bug.php?id=62655\|#62655]]: optional ini-level case-sensitivity \| Suspended \|
		+	\| 2014 \| Thread \| [[https://externals.io/message/71592\|"PHP and case-sensitivity inconsistency"]] \| No change \|
		+	\| 2014 \| RFC \| [[https://wiki.php.net/rfc/case-sensitivity\|"Make the PHP core case-sensitive"]] \| Abandoned, never voted \|
		+	\| 2014 \| Thread \| [[https://externals.io/message/79824\|"Proposal for PHP 7: case-sensitive symbols"]] \| No change in PHP 7 \|
		+	\| 2014 \| PR \| [[https://github.com/php/php-src/pull/965\|#965]]: E_STRICT on class/function case mismatch \| Closed, never merged \|
		+	\| 2018 \| RFC \| [[https://wiki.php.net/rfc/case_insensitive_constant_deprecation\|Deprecate case-insensitive constants]] \| Accepted — PHP 7.3 / 8.0 \|
		+	\| 2018 \| PR \| [[https://github.com/php/php-src/pull/3321\|#3321]]: deprecate case-insensitive constants \| Closed (shipped via commit) \|
		+	\| 2019 \| PR \| [[https://github.com/php/php-src/pull/3770\|#3770]]: WIP remove PHP 8 deprecated features \| Closed WIP \|
		+	\| 2019 \| PR \| [[https://github.com/php/php-src/pull/3833\|#3833]]: deprecate typelib case-insensitive constants \| Closed (merged separately) \|
		+	\| 2019 \| PR \| [[https://github.com/php/php-src/pull/3836\|#3836]]: remove typelib case-insensitive constants \| Closed \|
		+	\| 2022 \| PR \| [[https://github.com/php/php-src/pull/9439\|#9439]]: stop generating CONST_CS in stubs \| Merged \|
		+	\| 2022 \| PR \| [[https://github.com/php/php-src/pull/9685\|#9685]]: remove CONST_CS usages \| Merged \|
		+	\| 2024 \| Thread \| [[https://externals.io/message/123573\|"Revisiting case-sensitivity in PHP"]] \| No RFC drafted \|
		+	\| 2024 \| PR \| [[https://github.com/php/php-src/pull/17071\|#17071]]: remove unused CONST_CS flag \| Open \|
		+	\| 2026 \| RFC \| This RFC \| PHP 8.6 deprecation target \|
		+
		+	PR #965 (2014) is the only prior PR that ever targeted function and class name case sensitivity. It was never merged. Every other merged entry relates to constants.
		+
		+	===== 12. Rejected Alternatives =====
		+
		+	==== 12.1 Make it an error immediately ====
		+
		+	Skipping a deprecation period and going straight to an error would break existing code without warning, which violates PHP's deprecation policy.

	===== Changelog =====		===== 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.		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.

uri_followup

kocsismate (kocsismate@undisclosed.example.com) — 2026-05-30T19:57:09+00:00

2026/05/20 05:11		current
Line 706:		Line 706:
	===== Implementation =====		===== Implementation =====

-	After the RFC is implemented, this section should contain:	+	- https://github.com/kocsismate/php-src/commit/1bf64cee9387bec1fdee84e57ff74bea79311aad
-	- the version(s) it was merged into	+	- https://github.com/kocsismate/php-src/commit/d8a5aec1cc93e0fd41e8641091c32aace2a73059
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+

	===== References =====		===== References =====

exists-magic-method

nicolasgrekas (nicolasgrekas@undisclosed.example.com) — 2026-05-30T12:17:43+00:00

2026/05/30 12:17		current
Line 314:		Line 314:
	in the GH-12695 thread and rejected for concrete behaviour breaks:		in the GH-12695 thread and rejected for concrete behaviour breaks:

-	* Make ''isset()'' call <php>__get()</php> to verify non-null on magic properties. Doubles the userland calls for every ''isset()'' on a magic property. Any class whose <php>__get()</php> has side effects (logging, cache warm-up, counters, lazy init) sees those side effects run at every ''isset()'', where they don't run at all today. Universal BC break.	+	* Make ''isset()'' call ''%%__get()%%'' to verify non-null on magic properties. Doubles the userland calls for every ''isset()'' on a magic property. Any class whose <php>__get()</php> has side effects (logging, cache warm-up, counters, lazy init) sees those side effects run at every ''isset()'', where they don't run at all today. Universal BC break.
-	* Make ''??'' trust <php>__isset()</php> and not check the <php>__get()</php> result for null. ''??'' would now be able to return ''null'', contradicting the documented "set and not null" contract and breaking static analyzers that infer "non-null" from the operator.	+	* Make ''??'' trust ''%%__isset()%%'' and not check the ''%%__get()%%'' result for null. ''??'' would now be able to return ''null'', contradicting the documented "set and not null" contract and breaking static analyzers that infer "non-null" from the operator.

	Both alternatives are one-size changes to constructs that already-existing classes depend on. The		Both alternatives are one-size changes to constructs that already-existing classes depend on. The
Line 500:		Line 500:
	* ''empty($obj->prop)'': always returns ''true''. <php>__get()</php> is not called.		* ''empty($obj->prop)'': always returns ''true''. <php>__get()</php> is not called.

-	This is the "broken isset() on magic properties" path that the **Recommended floor for classes	+	This is the "broken isset() on magic properties" path that the Recommended floor for classes with ''%%__get%%'' example above fixes.
-	with __get** example above fixes.	+

	==== With neither __isset() nor __exists() (and no __get()) ====		==== With neither __isset() nor __exists() (and no __get()) ====

deprecate-return-value-from-construct - Include Juliette's analysis

timwolla (timwolla@undisclosed.example.com) — 2026-05-29T14:17:54+00:00

2026/05/29 14:17		current
Line 141:		Line 141:
	===== Changelog =====		===== Changelog =====

		+	* 2026-05-29: Include top 4000 composer packages analysis in RFC Impact section
	* 2026-05-29: Mention that making __construct and __destruct a Generator will also be deprecated		* 2026-05-29: Mention that making __construct and __destruct a Generator will also be deprecated
	* 2026-05-08: Initial version		* 2026-05-08: Initial version

third_party_ext_documentation

jordikroon (jordikroon@undisclosed.example.com) — 2026-05-29T11:32:47+00:00

2026/05/29 08:17		current
Line 20:		Line 20:

	* Bundled extension: An extension whose source is distributed as part of the ''php-src'' repository (e.g., ''ext/pdo'', ''ext/reflection'', ''ext/curl'', ''ext/mbstring''). These remain in the official PHP manual and are out of scope for this RFC.		* Bundled extension: An extension whose source is distributed as part of the ''php-src'' repository (e.g., ''ext/pdo'', ''ext/reflection'', ''ext/curl'', ''ext/mbstring''). These remain in the official PHP manual and are out of scope for this RFC.
-	* Third-party extension: An extension maintained in a repository outside ''php-src'', typically distributed via PECL, PIE or independently, whose documentation is currently hosted in the official PHP manual (e.g., ''imagick'', ''redis'', ''mongodb'', ''xdebug'', ''memcached'').	+	* Third-party extension: An extension maintained in a repository outside ''php-src'', typically distributed via PECL, PIE or independently, whose documentation is currently hosted in the official PHP manual (e.g., ''imagick'', ''redis'', ''mongodb'', ''memcached'').

	===== Proposal =====		===== Proposal =====

rfc

jordikroon (jordikroon@undisclosed.example.com) — 2026-05-28T19:07:01+00:00

2026/05/26 23:13		current
Line 22:		Line 22:
	This section is for RFCs that have been announced on the PHP "internals" mail list.		This section is for RFCs that have been announced on the PHP "internals" mail list.

		+	* [[rfc: third_party_ext_documentation \|Separation of Third-Party Extension Documentation]] (created 2026-05-27, discussion started 2026-05-28)
	* [[rfc:working_groups\|Working Groups]] (Created 2025-02-17, discussion started 2026-05-26)		* [[rfc:working_groups\|Working Groups]] (Created 2025-02-17, discussion started 2026-05-26)
	* [[rfc:getdisplaykeyword_and_getdisplaykeywordvalue\|Add Locale::getDisplayKeyword and Locale::getDisplayKeywordValue functions]] (created 2026-05-22)		* [[rfc:getdisplaykeyword_and_getdisplaykeywordvalue\|Add Locale::getDisplayKeyword and Locale::getDisplayKeywordValue functions]] (created 2026-05-22)
Line 74:		Line 75:
	This section is for early drafts of RFCs that have NOT been announced on the PHP "internals" mail list.		This section is for early drafts of RFCs that have NOT been announced on the PHP "internals" mail list.

-	* [[rfc: third_party_ext_documentation \|Separation of Third-Party Extension Documentation]] (created 2026-05-27)
	* [[rfc:deprecated_interfaces\|#[\Deprecated] for interfaces]] (created 2026-05-10)		* [[rfc:deprecated_interfaces\|#[\Deprecated] for interfaces]] (created 2026-05-10)
	* [[rfc:switch-case-fallthrough\|Explicit fallthrough for switch]] (created 2026-04-21)		* [[rfc:switch-case-fallthrough\|Explicit fallthrough for switch]] (created 2026-04-21)

working_groups

ramsey (ramsey@undisclosed.example.com) — 2026-05-26T17:02:27+00:00

2026/05/26 16:22		current
Line 303:		Line 303:

	* The first version of this document specified an automatic duration of 1 year for all working groups, unless specified. This required rechartering of each working group every year, or defining the specific duration for a longer period within the charter. Indefinite working groups were not allowed. After off-list discussion with others, it was decided this was cumbersome and would likely lead to confusion, so I have revised the RFC to allow indefinite durations and to explicitly require "duration" as a component of the working group charter.		* The first version of this document specified an automatic duration of 1 year for all working groups, unless specified. This required rechartering of each working group every year, or defining the specific duration for a longer period within the charter. Indefinite working groups were not allowed. After off-list discussion with others, it was decided this was cumbersome and would likely lead to confusion, so I have revised the RFC to allow indefinite durations and to explicitly require "duration" as a component of the working group charter.
		+
		+	==== Changelog ====
		+
		+	* 2025-02-17: Initial draft published on wiki
		+	* 2025-11-26: RFC moved to "Withdrawn" after external discussions
		+	* 2026-05-25: RFC moved back to "Draft" and updated to specify duration as required, allow "indefinite" durations, include an example charter, among minor edits for style
		+	* 2026-05-26: RFC moved to "Under Discussion"

opcache_static_cache - close open issues

zeriyoshi (zeriyoshi@undisclosed.example.com) — 2026-05-26T02:20:44+00:00

2026/05/19 12:20		current
Line 1:		Line 1:
	====== PHP RFC: OPcache Static Cache ======		====== PHP RFC: OPcache Static Cache ======
-	* Version: 1.2.1	+	* Version: 1.3.0
-	* Date: 2026-05-19	+	* Date: 2026-05-26
	* Author: Go Kudo <g-kudo@colopl.co.jp> <zeriyoshi@php.net>		* Author: Go Kudo <g-kudo@colopl.co.jp> <zeriyoshi@php.net>
	* Status: Under Discussion		* Status: Under Discussion
Line 415:		Line 415:
	===== Security and Trust Model =====		===== Security and Trust Model =====

-	OPcache Static Cache is shared memory for one PHP runtime instance. The trust boundary is the OPcache static-cache shared-memory segment established at SAPI startup. Workers that inherit or attach to the same segment share the same explicit key/value namespace and the same attribute-backed static-state namespace. This is not a tenant-isolation boundary. In FPM, the configured static-cache segments are initialized before workers start and are inherited by workers, so multiple pools under the same FPM master share the same cache namespace.	+	OPcache Static Cache is shared memory associated with one PHP runtime instance. The trust boundary is the OPcache static-cache shared-memory segment established at SAPI startup. Workers that inherit or attach to the same segment share both the explicit key/value namespace and the attribute-backed static-state namespace. The static-cache segment should not be treated as a tenant-isolation boundary. In FPM, the configured static-cache segments are initialized before worker processes are started and are inherited by those workers; consequently, multiple pools under the same FPM master process share the same cache namespace.

-	Administrators should leave these directives enabled only when every worker that can access the same OPcache static-cache segment belongs to the same trust domain, for example one application, one tenant, or mutually trusted applications that already coordinate their cache keys. Shared-hosting deployments that run mutually untrusted pools, vhosts, Unix users, chroots, or customers under one PHP master should disable the backends for that master by setting both size directives to <php>0</php>, or run those tenants under separate PHP/FPM master processes, containers, or equivalent OS-level isolation that gives each trust domain its own OPcache and static-cache shared memory. Setting these directives in an individual FPM pool does not create a per-pool static-cache segment once OPcache has been set up.	+	Administrators should enable these backends only when every worker that can access the same OPcache static-cache segment belongs to the same trust domain, such as a single application, a single tenant, or mutually trusted applications that already coordinate their cache keys. Shared-hosting deployments that run mutually untrusted pools, virtual hosts, Unix users, chroots, or customers under a single PHP master process should disable these backends for that master by setting both size directives to <php>0</php>, or should run those tenants under separate PHP/FPM master processes, containers, virtual machines, or equivalent operating-system isolation that gives each trust domain its own OPcache and static-cache shared memory. Setting these directives in pool-specific FPM configuration does not create a per-pool static-cache segment after OPcache has been initialized.

-	The existing <php>opcache.validate_permission</php> and <php>opcache.validate_root</php> directives mitigate script-cache access and chroot key-collision issues by revalidating file access or varying script-cache hashes by root. They do not isolate OPcache Static Cache entries, because explicit cache keys and attribute-backed static-state keys are application data rather than script filenames. This is similar to local shared user caches such as APCu: applications should still namespace keys for correctness, but user-controlled key prefixes are not a security boundary when untrusted code can choose keys or call cache mutation APIs.	+	This RFC does not attempt to make the legacy deployment model of a single PHP master process serving mutually untrusted tenants safe on its own. That model is no longer the common case in modern PHP hosting, where tenant isolation is typically provided by separate FPM masters, containers, virtual machines, or equivalent operating-system boundaries. Hosting providers that still run mutually untrusted tenants under a single OPcache static-cache shared-memory segment should disable these backends in the master-level configuration, in the same way that they would restrict or disable <php>opcache_get_status()</php> when exposing OPcache state would cross a tenant boundary.
		+
		+	This is a deployment configuration responsibility, not a reason to add an application-level namespace or pool primitive to this RFC. The required mitigation is explicit and mechanical: set <php>opcache.static_cache.volatile_size_mb=0</php> and <php>opcache.static_cache.pinned_size_mb=0</php> for PHP master processes that host mutually untrusted tenants, or move those tenants to separate OPcache static-cache shared-memory segments. As with other OPcache configuration changes that affect shared-hosting behavior, documenting the change and announcing it to affected operators is sufficient.
		+
		+	The existing <php>opcache.validate_permission</php> and <php>opcache.validate_root</php> directives mitigate script-cache access and chroot key-collision issues by revalidating file access or varying script-cache hashes by root. They do not isolate OPcache Static Cache entries, because explicit cache keys and attribute-backed static-state keys are application data rather than script filenames. This is similar to local shared-memory user caches such as APCu: applications should still namespace keys for correctness, but user-controlled key prefixes are not a security boundary when untrusted code can choose keys or call cache-mutation APIs.

	===== Implementation Notes =====		===== Implementation Notes =====
Line 498:		Line 502:

	FPM must initialize the configured static-cache shared-memory segments before workers start. If a backend would be initialized too late, the implementation reports the cache as unavailable instead of creating worker-local state.		FPM must initialize the configured static-cache shared-memory segments before workers start. If a backend would be initialized too late, the implementation reports the cache as unavailable instead of creating worker-local state.
-
-	===== Open Issues =====
-
-	* Whether multi-library key-collision concerns should be addressed by an explicit pool/namespace primitive in a future RFC. Class-name and exact-key deletion already cover most "rebuild my library's keys" patterns within a single trust domain, but a separate namespacing mechanism would help when several independent libraries are deployed together and want clear ownership boundaries.

	===== Future Scope =====		===== Future Scope =====
Line 507:		Line 507:
	Possible future directions that this RFC does not commit to but does not prevent:		Possible future directions that this RFC does not commit to but does not prevent:

-	* SAPI-provided trust-domain or pool identity, exposed to OPcache static-cache key resolution, for deployments that want one PHP master to serve mutually untrusted tenants under separate static-cache namespaces.
	* A higher-level attribute over function return values, memoize-style, layered on top of the same static-cache backends and kept distinct from the static-storage semantics that <php>PinnedStatic</php> and <php>VolatileStatic</php> describe.		* A higher-level attribute over function return values, memoize-style, layered on top of the same static-cache backends and kept distinct from the static-storage semantics that <php>PinnedStatic</php> and <php>VolatileStatic</php> describe.
		+	* SAPI-provided trust-domain or pool identity, exposed to OPcache static-cache key resolution, for deployments that intentionally want multiple trusted applications under one PHP master to use separate static-cache namespaces. This is not a security boundary for mutually untrusted tenants; those deployments should use separate OPcache static-cache shared-memory segments or disable the static-cache backends.

	===== Voting Choices =====		===== Voting Choices =====
Line 755:		Line 755:
	===== Changelog =====		===== Changelog =====

		+	* 2026-05-26
		+	* Bumped the RFC document version to 1.3.0 and updated the RFC date to 2026-05-26.
		+	* Removed the Open Issues section. The former pool/namespace item is now covered by the Security and Trust Model and narrowed to Future Scope.
		+	* This does not change the proposed API, INI directives, default values, implementation semantics, or voting choices.
	* 2026-05-19		* 2026-05-19
	* Bumped the RFC document version to 1.2.1.		* Bumped the RFC document version to 1.2.1.
Line 810:		Line 814:
	* Added PHPT coverage for loaded-class attribute deletion, documented exact-key attribute deletion, manual unlock, post-shutdown lock leases, stricter key validation, <php>StaticCacheInfo</php>, and pinned atomic decrement creation.		* Added PHPT coverage for loaded-class attribute deletion, documented exact-key attribute deletion, manual unlock, post-shutdown lock leases, stricter key validation, <php>StaticCacheInfo</php>, and pinned atomic decrement creation.
	* Updated existing PHPT coverage to use <php>StaticCacheInfo</php> object properties instead of array offsets.		* Updated existing PHPT coverage to use <php>StaticCacheInfo</php> object properties instead of array offsets.
-	* benchmark harness from the RFC.	+	* Moved the benchmark harness out of the RFC text and linked it from the Patches and Tests section.
	* Reran the benchmark matrix from clean current NTS FPM, current NTS/ZTS CLI, current ZTS FrankenPHP, and clean <php>43b56c96af5c373a0539bca49bdc568b01a3163c</php> CLI builds, then updated the performance tables and benchmark takeaways.		* Reran the benchmark matrix from clean current NTS FPM, current NTS/ZTS CLI, current ZTS FrankenPHP, and clean <php>43b56c96af5c373a0539bca49bdc568b01a3163c</php> CLI builds, then updated the performance tables and benchmark takeaways.
	* Removed the boilerplate Future Scope text and added an open issue about possible <php>Memoize</php>-style naming.		* Removed the boilerplate Future Scope text and added an open issue about possible <php>Memoize</php>-style naming.

coroutine-lifecycle.svg - created

edmond (edmond@undisclosed.example.com) — 2025-04-16T07:24:46+00:00

	current

supervisor.svg - created

edmond (edmond@undisclosed.example.com) — 2025-03-16T08:38:59+00:00

	current

exception_flow.svg - created

edmond (edmond@undisclosed.example.com) — 2025-03-16T08:38:59+00:00

	current

resume_and_notifier.svg - created

edmond (edmond@undisclosed.example.com) — 2025-02-16T08:40:05+00:00

	current

basic.svg - created

edmond (edmond@undisclosed.example.com) — 2025-02-14T19:39:22+00:00

	current

speed.svg - created

divinity76 (divinity76@undisclosed.example.com) — 2025-01-24T09:50:19+00:00

	current

output_5_.png - created

divinity76 (divinity76@undisclosed.example.com) — 2025-01-24T09:47:20+00:00

	current

iri_venn_diagramm.svg - created

kocsismate (kocsismate@undisclosed.example.com) — 2025-01-23T08:55:06+00:00

	current

105434d8f6ee317dfe.jpg - removed

nielsdos (nielsdos@undisclosed.example.com) — 2023-08-26T11:13:31+00:00

	current

bench.png

nielsdos (nielsdos@undisclosed.example.com) — 2023-08-24T21:45:45+00:00

1692492417	current

imagemagick-configure.gif - created

cmb (cmb@undisclosed.example.com) — 2021-11-03T13:55:20+00:00

	current