PHP Wiki

case_sensitive_php - created

jorg_sowa (jorg_sowa@undisclosed.example.com) — 2026-05-29T22:14:01+00:00

2026/05/30 01:13	current
Line 1:	Line 1:
	+	====== 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

	+	===== 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 [[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.
	+
	+	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>
	+	<?php
	+
	+	namespace Example\Component {
	+	final class NewAddition {
	+	public static function fromString(string $example): self {}
	+	}
	+	}
	+
	+	?>
	+	</PHP>
	+
	+	==== 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>
	+	<?php
	+
	+	echo "First example";
	+
	+	?>
	+	</PHP>
	+
	+	Example showing an edge case:
	+	<PHP>
	+	<?php
	+
	+	echo "Edge case";
	+
	+	?>
	+	</PHP>
	+
	+	===== 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:
	+
	+	* 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/
	+
	+	===== 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 [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting-phase\|the php/policies repository]] for the current voting guidelines.
	+
	+	----
	+
	+	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">
	+	* Yes
	+	* No
	+	* Abstain
	+	</doodle>
	+
	+	===== 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:
	+	- 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 =====
	+	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.

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.

bound_erased_generic_types - Runtime enforcement of substituted contracts tightened; document type-argument erasure as a limitation (v0.22)

azjezz (azjezz@undisclosed.example.com) — 2026-05-24T06:02:11+00:00

2026/05/24 06:02		current
Line 2137:		Line 2137:
	* 2026-05-13: ''ReflectionGenericVariance'' is now a unit enum (v0.20).		* 2026-05-13: ''ReflectionGenericVariance'' is now a unit enum (v0.20).
	* 2026-05-14: ''getGenericArgumentsForParentInterface()'' returns ''list<list<ReflectionType>>'' (v0.21).		* 2026-05-14: ''getGenericArgumentsForParentInterface()'' returns ''list<list<ReflectionType>>'' (v0.21).
-	* 2026-05-14: Runtime enforcement of substituted contracts tightened; document type-argument erasure as a limitation (v0.22).	+	* 2026-05-24: Runtime enforcement of substituted contracts tightened; document type-argument erasure as a limitation (v0.22).

override_constants - vote was successful

daniels (daniels@undisclosed.example.com) — 2026-05-24T04:47:45+00:00

2026/05/08 02:03		current
Line 3:		Line 3:
	* Date: 2026-03-13		* Date: 2026-03-13
	* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com		* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com
-	* Status: Voting	+	* Status: Pending implementation / landing
	* Implementation: https://github.com/php/php-src/pull/20478		* Implementation: https://github.com/php/php-src/pull/20478
	* Discussion thread: https://news-web.php.net/php.internals/130505		* Discussion thread: https://news-web.php.net/php.internals/130505

template - Add discussion thread link “template” and voting thread entry

timwolla (timwolla@undisclosed.example.com) — 2026-05-23T11:22:22+00:00

2026/05/10 16:29		current
Line 5:		Line 5:
	* Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")		* Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")
	* Implementation: https://github.com/...		* Implementation: https://github.com/...
-	* Discussion thread:	+	* Discussion thread: https://news-web.php.net/php.internals/… (The email should appear on https://news-web.php.net/php.internals/ a few minutes after sending it)
		+	* Voting thread: tbd

	This is the suggested template for PHP Request for Comments (RFCs). Change this template to suit your RFC. Not all RFCs need all the sections below.		This is the suggested template for PHP Request for Comments (RFCs). Change this template to suit your RFC. Not all RFCs need all the sections below.

partial_function_application_optional_placeholder - Accepted

timwolla (timwolla@undisclosed.example.com) — 2026-05-23T10:33:43+00:00

2026/05/06 14:22		current
Line 3:		Line 3:
	* Date: 2026-04-20		* Date: 2026-04-20
	* Author: Tim Düsterhus (timwolla@php.net), Arnaud Le Blanc (arnaud.lb@gmail.com), Larry Garfield (larry@garfieldtech.com)		* Author: Tim Düsterhus (timwolla@php.net), Arnaud Le Blanc (arnaud.lb@gmail.com), Larry Garfield (larry@garfieldtech.com)
-	* Status: Voting	+	* Status: Accepted
	* Implementation: https://github.com/...		* Implementation: https://github.com/...

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

-	<doodle title="Make all ? placeholders in PFA required parameters?" voteType="single" closed="false" closeon="2026-05-20T10:30:00Z">	+	<doodle title="Make all ? placeholders in PFA required parameters?" voteType="single" closed="true" closeon="2026-05-20T10:30:00Z">
	* Yes		* Yes
	* No		* No

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