PHP Wiki

native_markup_expressions

liam (liam@undisclosed.example.com) — 2026-07-14T23:43:33+00:00

2026/07/14 23:09		current
Line 6:		Line 6:
	* Target version: PHP 9.0		* Target version: PHP 9.0
	* Implementation: https://github.com/php/php-src/pull/22661		* Implementation: https://github.com/php/php-src/pull/22661
-	* Discussion thread: tbd	+	* Discussion thread: https://news-web.php.net/php.internals/131925
	* Voting thread: tbd		* Voting thread: tbd

direction_aware_property_resolution

kalle (kalle@undisclosed.example.com) — 2026-07-14T18:12:26+00:00

rfc - Added direction_aware_property_resolution

thecodelorax (thecodelorax@undisclosed.example.com) — 2026-07-14T15:36:45+00:00

2026/07/13 10:10		current
Line 77:		Line 77:
	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:direction_aware_property_resolution\|Direction Aware Property Resolution]] (Created 2026-07-14)
	* [[rfc:extension_methods\|Extension Methods]] (created 2026-07-11)		* [[rfc:extension_methods\|Extension Methods]] (created 2026-07-11)
	* [[rfc:extension_methods_scalars\|Scalar Extension Methods]] (created 2026-07-11)		* [[rfc:extension_methods_scalars\|Scalar Extension Methods]] (created 2026-07-11)

serializable_closures

nicolasgrekas (nicolasgrekas@undisclosed.example.com) — 2026-07-14T14:57:41+00:00

2026/07/14 10:10		current
Line 102:		Line 102:
	* including when nested in further closures declared there.		* including when nested in further closures declared there.

-	The payload is a reference to the declaration site, made of the declaring class name, an	+	The payload is a reference to the declaration site, made of the declaring class name and an
-	element-scoped id, and a hash of the closure's code (a staleness check), wrapped in a	+	element-scoped id that embeds a hash of the closure's code (a staleness check), wrapped
-	tagged union (see below):	+	in a tagged union (see below):

	<code php>		<code php>
Line 114:		Line 114:

	$closure->__serialize();		$closure->__serialize();
-	// [ [], ['const-expr', ['Order', '$billingAddress@0', 24167]] ]	+	// [ [], ['const-expr', ['Order', '$billingAddress@0#4a3f']] ]
	</code>		</code>

Line 123:		Line 123:
	<php>ReflectionAttribute::getArguments()</php> return two instances today.		<php>ReflectionAttribute::getArguments()</php> return two instances today.

-	The id is element-scoped and deterministic. It is an opaque ''"<site>@<rank>"'' string:	+	The id is element-scoped and deterministic. It is an opaque ''"<site>@<rank>#<hash>"''
-	''<site>'' names the declaring reflection element (the empty string for the class itself, a	+	string: ''<site>'' names the declaring reflection element (the empty string for the class
-	constant or enum-case name, ''$prop'' for a property, ''$prop::get()'' / ''$prop::set()'' for a	+	itself, a constant or enum-case name, ''$prop'' for a property, ''$prop::get()'' /
-	property hook, ''name()'' for a method, with a method's parameters folded into the method), and	+	''$prop::set()'' for a property hook, ''name()'' for a method, with a method's parameters folded
-	''<rank>'' is the closure's position among the closures of //that one element//, counted in a	+	into the method), ''<rank>'' is the closure's position among the closures of //that one
-	fixed declaration-order traversal (attributes first, then parameter default values, nesting	+	element//, counted in a fixed declaration-order traversal (attributes first, then parameter
-	depth-first). It is derived from the compiled class alone, never from runtime state, evaluation	+	default values, nesting depth-first), and ''<hash>'' verifies the closure's code. It is derived from the compiled class alone, never from runtime state, evaluation
	order or caches: every process running the same source computes the same id, with or without		order or caches: every process running the same source computes the same id, with or without
	opcache. Because each element is numbered independently, adding, removing or reordering a closure		opcache. Because each element is numbered independently, adding, removing or reordering a closure
Line 146:		Line 146:
	resolve to a //different// closure after the surrounding declarations are edited. This is the		resolve to a //different// closure after the surrounding declarations are edited. This is the
	one guarantee a positional id alone cannot make (see the Rationale for the failure it closes).		one guarantee a positional id alone cannot make (see the Rationale for the failure it closes).
		+	Because it rides inside the id, every consumer of an id gets the same protection: both
		+	''unserialize()'' and <php>Closure::fromConstExpr()</php> verify it, and a producer that cannot
		+	compute it (see the Rationale) may omit the ''#<hash>'' suffix, in which case resolution is
		+	positional and unverified.

	When the class's source changes, a stored reference either stops resolving or is rejected by the		When the class's source changes, a stored reference either stops resolving or is rejected by the
Line 228:		Line 232:
	==== Security model ====		==== Security model ====

-	The payload contains a class name, a site id and, for anonymous closures, a code hash**: never	+	The payload contains a class name and a site id, embedding for anonymous closures a hash of**
-	code**. Resolution can only ever produce a closure that the named class's own source	+	their code: never code itself**. Resolution can only ever produce a closure that the named class's own source
	declares in one of its constant expressions: there is nothing else a payload can express.		declares in one of its constant expressions: there is nothing else a payload can express.
	''unserialize()'' is not a closure factory over the code base; it is a lookup into the fixed,		''unserialize()'' is not a closure factory over the code base; it is a lookup into the fixed,
Line 260:		Line 264:
	<code>		<code>
	Invalid serialization data for Closure object (constant-expression closure "$billingAddress@3" of class Order not found)		Invalid serialization data for Closure object (constant-expression closure "$billingAddress@3" of class Order not found)
-	Invalid serialization data for Closure object (constant-expression closure "$billingAddress@0" of class Order changed)	+	Invalid serialization data for Closure object (constant-expression closure "$billingAddress@0#4a3f" of class Order changed)
	Invalid serialization data for Closure object (cannot load class "Order")		Invalid serialization data for Closure object (cannot load class "Order")
	</code>		</code>
Line 269:		Line 273:
	recreates the closure, rather than a binary payload. Three additions support this:		recreates the closure, rather than a binary payload. Three additions support this:

-	* <php>ReflectionFunction::getConstExprId(): ?string</php> returns the element-scoped declaration-site id (''"<site>@<key>"'') of a closure declared in a constant expression, or ''null'' for any other closure.	+	* <php>ReflectionFunction::getConstExprId(): ?string</php> returns the element-scoped declaration-site id (''"<site>@<key>[#<hash>]"'') of a closure declared in a constant expression, or ''null'' for any other closure.
	* <php>ReflectionFunction::getConstExprClass(): ?string</php> returns the declaring class. This is a distinct accessor because for first-class callable references no existing one carries it: a ''Validators::check(%%...%%)'' reference declared by ''Order'' has <php>getClosureScopeClass()</php> and <php>getClosureCalledClass()</php> both pointing at ''Validators'', a ''parent::'' reference has both pointing at the parent class, and a function reference (''strlen(%%...%%)'') has neither, while all of them are declared, and serialized, by ''Order''. The existing accessors describe the closure's runtime semantics (visibility scope, ''static::'' binding); <php>getConstExprClass()</php> describes where it was declared.		* <php>ReflectionFunction::getConstExprClass(): ?string</php> returns the declaring class. This is a distinct accessor because for first-class callable references no existing one carries it: a ''Validators::check(%%...%%)'' reference declared by ''Order'' has <php>getClosureScopeClass()</php> and <php>getClosureCalledClass()</php> both pointing at ''Validators'', a ''parent::'' reference has both pointing at the parent class, and a function reference (''strlen(%%...%%)'') has neither, while all of them are declared, and serialized, by ''Order''. The existing accessors describe the closure's runtime semantics (visibility scope, ''static::'' binding); <php>getConstExprClass()</php> describes where it was declared.
-	* <php>Closure::fromConstExpr(string $class, string $id): Closure</php> recreates the closure from such a reference. It throws an <php>Error</php> if the class cannot be loaded and a <php>ValueError</php> if the id does not resolve.	+	* <php>Closure::fromConstExpr(string $class, string $id): Closure</php> recreates the closure from such a reference, verifying the id's embedded code hash exactly like ''unserialize()'' does, so generated cache files get the same staleness protection as serialized payloads. It throws an <php>Error</php> if the class cannot be loaded and a <php>ValueError</php> if the id does not resolve or no longer matches the closure's code.

	An exporter then emits self-contained, opcache-friendly code:		An exporter then emits self-contained, opcache-friendly code:
Line 277:		Line 281:
	<code php>		<code php>
	// generated cache file		// generated cache file
-	return \Closure::fromConstExpr(\App\Order::class, '$billingAddress@0');	+	return \Closure::fromConstExpr(\App\Order::class, '$billingAddress@0#4a3f');
	</code>		</code>

Line 566:		Line 570:
	===== Changelog =====		===== Changelog =====

-	* 0.2: Scoped the declaration-site id to the reflection element (''"<site>@<key>"''); ''getConstExprId()'' and the ''$id'' argument of ''fromConstExpr()'' become strings. First-class callable references are keyed by the callable's name (''"<site>@Called::method"'', no rank, no staleness field) and normalize to their first declaring element. Anonymous references are verified by a hash of the closure's code, so a positional reference cannot silently resolve to a different closure after declarations are reordered. The serialization payload is a tagged union (''[<properties>, [<tag>, <reference>]]'') so the format can grow further reference kinds. Expanded the security model (inert creation vs substitution on call) and the reflection rationale (provenance and faithful reconstruction versus ''ReflectionMethod::getClosure()''); added the "Version migration" and "Why a single RFC" rationale sections.	+	* 0.2: Scoped the declaration-site id to the reflection element (''"<site>@<key>"''); ''getConstExprId()'' and the ''$id'' argument of ''fromConstExpr()'' become strings. First-class callable references are keyed by the callable's name (''"<site>@Called::method"'', no rank, no staleness field) and normalize to their first declaring element. Anonymous references are verified by a hash of the closure's code, embedded in the id (''"<site>@<rank>#<hash>"'', optional for producers that cannot compute it) so that ''fromConstExpr()'' verifies it like ''unserialize()'' does and a positional reference cannot silently resolve to a different closure after declarations are reordered. The serialization payload is a tagged union (''[<properties>, [<tag>, <reference>]]'') of ''[class, id]'' references. Expanded the security model (inert creation vs substitution on call) and the reflection rationale (provenance and faithful reconstruction versus ''ReflectionMethod::getClosure()''); added the "Version migration" and "Why a single RFC" rationale sections.
	* 0.1: Initial draft.		* 0.1: Initial draft.

pipe_assignment_operator

cdwhite3 (cdwhite3@undisclosed.example.com) — 2026-07-14T11:32:37+00:00

2026/07/14 11:31		current
Line 222:		Line 222:

	===== Changelog =====		===== Changelog =====
-	* 1.0.2 (2026-07-14): Corrected precedence wording, added implicit move optimisation reference and future scope, addressed reviewer feedback.	+	* 1.0.2 (2026-07-14): Corrected precedence wording, added implicit move optimisation reference and future scope.
	* 1.0.1 (2026-07-13): Added associativity and precedence examples.		* 1.0.1 (2026-07-13): Added associativity and precedence examples.
	* 1.0.0 (2026-07-09): Initial draft.		* 1.0.0 (2026-07-09): Initial draft.

ext-gd-2.4

pajoye (pajoye@undisclosed.example.com) — 2026-07-14T03:13:04+00:00

2026/07/11 10:49		current
Line 291:		Line 291:
	{{ :rfc:textcurve.png?direct \|}}		{{ :rfc:textcurve.png?direct \|}}

		+	===== content aware resize =====
		+
		+
		+	{{ :rfc:scale_entropy_visual_check.png?direct&600 \|}}

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====

scale_entropy_visual_check.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-14T03:12:03+00:00

	current

readonly_property_defaults - Added constructor property promotion to non-goals.

nicksdot (nicksdot@undisclosed.example.com) — 2026-07-13T17:41:40+00:00

2026/07/09 19:09		current
Line 1:		Line 1:
	====== PHP RFC: Readonly Property Defaults ======		====== PHP RFC: Readonly Property Defaults ======

-	* Version: 0.9	+	* Version: 0.9.3
	* Date: 2026-07-04		* Date: 2026-07-04
	* Author: Nick Sdot, php@nicksdot.dev		* Author: Nick Sdot, php@nicksdot.dev
Line 308:		Line 308:
	* how readonly interacts with property hooks		* how readonly interacts with property hooks
	* how readonly interacts with static properties		* how readonly interacts with static properties
		+	* that a default value on a promoted constructor parameter is a parameter default only

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====
Line 362:		Line 363:
	* 2026-07-04: Initial version.		* 2026-07-04: Initial version.
	* 2026-07-09: Improved examples & formatting.		* 2026-07-09: Improved examples & formatting.
-	* 2026-07-09: Improved un-/serialisation	+	* 2026-07-09: Improved un-/serialisation section.
		+	* 2026-07-14: Added constructor property promotion to non-goals.

deprecations_php_8_6 - Remove example deprecation block

girgias (girgias@undisclosed.example.com) — 2026-07-13T15:48:18+00:00

2026/07/13 15:48		current
Line 539:		Line 539:
	</blockquote>		</blockquote>

-	And if an object is encountered during traversalm the following deprecatioin will be emitted:	+	And if an object is encountered during traversal the following deprecatioin will be emitted:
	<blockquote>		<blockquote>
	Deprecated: object values within argument #1 $data to http_build_query() being interpreted as arrays is deprecated, instead the $data argument should be preprocessed with get_object_vars()		Deprecated: object values within argument #1 $data to http_build_query() being interpreted as arrays is deprecated, instead the $data argument should be preprocessed with get_object_vars()

const_object_property_write - Sync “Status”

timwolla (timwolla@undisclosed.example.com) — 2026-07-13T14:06:30+00:00

2026/07/11 10:34		current
Line 3:		Line 3:
	* Date: 2026-06-28		* Date: 2026-06-28
	* Author: Khaled Alam, khaledalam.net@gmail.com		* Author: Khaled Alam, khaledalam.net@gmail.com
-	* Status: Draft	+	* Status: Under Discussion
	* Implementation: https://github.com/php/php-src/pull/20903		* Implementation: https://github.com/php/php-src/pull/20903

limit-maximum-number-of-filter-chains - Accepted

sjoerd (sjoerd@undisclosed.example.com) — 2026-07-13T10:09:35+00:00

2026/06/05 07:13		current
Line 1:		Line 1:
	====== PHP RFC: Limit maximum number of filter chains ======		====== PHP RFC: Limit maximum number of filter chains ======

-	* Version: 1.6	+	* Version: 1.7
	* Date: 2026-05-05		* Date: 2026-05-05
	* Author: Sjoerd Langkemper <sjoerd-php@linuxonly.nl>		* Author: Sjoerd Langkemper <sjoerd-php@linuxonly.nl>
-	* Status: Voting	+	* Status: Accepted
	* Implementation: https://github.com/php/php-src/pull/22110		* Implementation: https://github.com/php/php-src/pull/22110
	* Discussion: https://news-web.php.net/php.internals/130813		* Discussion: https://news-web.php.net/php.internals/130813
Line 200:		Line 200:
	* 1.5 2026-06-02 Remove "Open issues", add stream context examples		* 1.5 2026-06-02 Remove "Open issues", add stream context examples
	* 1.6 2026-06-05 Open voting		* 1.6 2026-06-05 Open voting
		+	* 1.7 2026-07-13 Accepted

php86 - Soft/Hard feature freeze

mbeccati (mbeccati@undisclosed.example.com) — 2026-07-13T07:51:19+00:00

2026/07/02 17:14		current
Line 17:		Line 17:
	\| Jul 16 2026 \| Alpha 2 \|		\| Jul 16 2026 \| Alpha 2 \|
	\| Jul 30 2026 \| Alpha 3 \|		\| Jul 30 2026 \| Alpha 3 \|
-	\| Aug 13 2026 \| Feature freeze \|	+	\| Aug 11 2026 \| Soft feature freeze: all RFCs must have their voting concluded, and should have been merged. \|
	\| Aug 13 2026 \| Beta 1 \|		\| Aug 13 2026 \| Beta 1 \|
	\| Aug 27 2026 \| Beta 2 \|		\| Aug 27 2026 \| Beta 2 \|
	\| Sep 10 2026 \| Beta 3 \|		\| Sep 10 2026 \| Beta 3 \|
		+	\| Sep 22 2026 \| Hard feature freeze: features — whether requiring an RFC or not — must be merged only with approval from the RMs. \|
	\| Sep 24 2026 \| RC1 \|		\| Sep 24 2026 \| RC1 \|
	\| Oct 08 2026 \| RC2 \|		\| Oct 08 2026 \| RC2 \|

catchable_memory_error

ramsey (ramsey@undisclosed.example.com) — 2026-07-12T15:31:08+00:00

2026/07/12 01:50		current
Line 234:		Line 234:
	* ''[[https://github.com/search?type=code&q=%2Fclass_alias%5Cs%5C%28.MemoryError%2F+language%3APHP\|/class_alias\s\(.MemoryError/ language:PHP]]''		* ''[[https://github.com/search?type=code&q=%2Fclass_alias%5Cs%5C%28.MemoryError%2F+language%3APHP\|/class_alias\s\(.MemoryError/ language:PHP]]''

-	Findings:	+	=== Findings ===

	* Zero global-namespace declarations of ''%%MemoryError%%''.		* Zero global-namespace declarations of ''%%MemoryError%%''.

extension_methods_autoload - created

thecodelorax (thecodelorax@undisclosed.example.com) — 2026-07-12T02:04:21+00:00

2026/07/15 00:33	current
Line 1:	Line 1:
	+	====== PHP RFC: Extension Method Autoloading ======
	+	* Version: 1.1
	+	* Date: 2026-07-11
	+	* Author: Holly Schilling, holly.a.schilling@outlook.com
	+	* Status: Draft
	+	* Depends on: [[rfc:extension_method_visibility\|PHP RFC: Extension Method Visibility]]
	+	* Implementation: https://github.com/hollyschilling/php-src/tree/extension-methods-autoload
	+	* Discussion thread: tbd
	+	* Voting thread: tbd
	+
	+	===== Introduction =====
	+
	+	The [[rfc:extension_method_visibility\|visibility RFC]] draws a line it inherits from every other ''use'' statement: importing is not loading. ''use extension Vendor\Name;'' grants visibility, but the declaring file must still be executed by something — a ''require_once'', or the declaring package's Composer ''autoload.files'' entry. This RFC removes that residue: an imported-but-unloaded named extension is resolved through the ordinary class autoloader at first use, exactly as an unloaded class is. The ''use extension'' line becomes the only line a consumer writes:
	+
	+	<code php>
	+	// vendor/acme/dom-kit/src/DomTraversal.php (PSR-4 / classmap addressable)
	+	namespace Acme\DomKit;
	+
	+	extension DomTraversal on \DOMElement $el {
	+	public function firstByClass(string $class): ?\DOMElement { /* ... */ }
	+	}
	+	</code>
	+
	+	<code php>
	+	// app/render.php — nothing else loads DomTraversal.php
	+	use extension Acme\DomKit\DomTraversal;
	+
	+	$el->firstByClass('hero'); // first use: autoloaded, resolved, called
	+	</code>
	+
	+	The ecosystem half of this pipeline already exists: [[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]] (draft) teaches Composer's class-map generator to map named extension declarations to their files. PSR-4 itself needs no amendment — its "classes, interfaces, traits, and other similar structures" wording covers extension declarations, as it covered enums. This RFC supplies the engine half.
	+
	+	===== Proposal =====
	+
	+	==== Named extensions become class-table symbols ====
	+
	+	The visibility RFC left open "what artifact the autoloader maps the name to." This RFC answers: the named extension's synthetic class entry, registered in the class table under the extension's own name at bind time (when the declaring statement executes). Consequences, stated plainly:
	+
	+	* ''class_exists('Vendor\Name')'' is ''true'' once the declaration has executed — and ''class_exists('Vendor\Name', true)'' triggers autoloading, exactly as for a class. This is deliberate: "is this extension available?" now has the same answer mechanism as every other symbol.
	+	* Extension names share the class symbol namespace. Declaring an extension under a name already taken by a class, interface, trait, enum, or another extension is a fatal error ("Cannot declare extension %s, because the name is already in use"), symmetric with class redeclaration. One name, one symbol — the property every autoloader (and every reader) already assumes.
	+	* The symbol is inert as a class. The CE is final and uninstantiable: ''new Vendor\Name'' throws ("Cannot instantiate abstract class Vendor\Name" — see Open Issues for the message), ''extends'' fails against ''final'', and the CE carries the extension's real qualified name, which is what reflection and diagnostics display.
	+	* Anonymous extension blocks are unchanged: they declare no symbol, participate in no autoloading, and keep their base-RFC semantics.
	+
	+	==== Autoload triggering ====
	+
	+	Resolution stays lazy — the same moment a class is autoloaded is the moment an extension is: first use. When extension-method resolution misses (object or scalar receiver), the engine takes each name in the calling code's import set that has no class-table entry and hands it to the class autoloader (''zend_lookup_class_ex'', i.e. the ''spl_autoload'' chain), then retries the lookup once. Semantics:
	+
	+	- The autoloader receives the original-case name as written in the ''use extension'' statement (or in the declaring position, for self-imports). Import sets store the original spelling alongside the lowercased gating key, because PSR-4 file resolution is case-sensitive.
	+	- At most one attempt per name per request. An imported-but-unloadable extension is //not// an error — an unused import is legal, mirroring ''use'' of a class that is never mentioned — so, unlike the class case (where failure throws and naturally stops repetition), nothing else would bound re-attempts. A per-request negative cache does. No attempt is consumed while no autoloader is registered at all, so bootstrap order cannot permanently poison a name.
	+	- Autoloader exceptions propagate. If the loader throws, the call site reports that exception, not "Call to undefined method" — matching class autoloading.
	+	- Autoloading never widens visibility. Loading and gating remain orthogonal: the loaded extension resolves only in frames whose op_array imported it, exactly per the visibility RFC. A non-importing file's miss can still trigger the load (its own imports only), and an importing file's successful load grants nothing to anyone else.
	+	- Functions that resolve methods through the engine's method lookup (''method_exists'', ''is_callable'' on objects) can consequently trigger the autoload from an importing frame — the same way ''class_exists($n, true)'' triggers class loading. Since these already observe extension methods (base RFC open issue), this adds no new observability, only earlier loading.
	+
	+	=== Why the import set is the resolution key ===
	+
	+	Note what the trigger does //not// do: it never maps the missing method to a specific extension. That mapping (method name + receiver type → extension name) does not exist anywhere before the declaring file executes — a PHP source file's contents are not queryable without running it, and the class map knows names→files, nothing more. So the engine uses the only sound key available: the calling file's import set. All unloaded imports are loaded on a miss, then the lookup retries once.
	+
	+	This is precisely where extension autoloading escapes the fate of function autoloading. An unqualified function call has an unbounded candidate space (current namespace, global fallback, any loader's guess); an extension method call, by the visibility RFC's own rules, can only be satisfied by an extension the file explicitly imported by fully-qualified name. The candidate list is finite, explicit, and sitting in the op_array — typically a handful of names.
	+
	+	The trade-off is stated honestly: the engine over-loads. A miss that turns out to be a genuine typo loads //all// of the file's unloaded imports before the undefined-method error is raised. Three bounds keep this cheap: it happens on the error/first-touch path only; each name is attempted at most once per request; and extension declaring files are declaration-only by construction. The end state after the first miss is deterministic — the file's imports are simply all loaded, the same world its ''autoload.files'' entries would have created at bootstrap, arrived at lazily (never earlier, often never). One coupling worth recording: the visibility RFC's group-use and re-export open issues exist to grow import sets cheaply; accepting either later fattens this load batch, so those decisions and this trigger are linked.
	+
	+	==== The end state for consumers ====
	+
	+	With this RFC accepted and Composer support merged, the loading story of the visibility RFC's FAQ ("do I need ''use extension'' and a ''require_once''?") collapses to its final form: no. The package maps its extension files via PSR-4/classmap as it maps classes; the consumer writes ''use extension Vendor\Name;'' and calls methods. ''autoload.files'' entries and manual ''require_once'' become what they are for classes today: unnecessary.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	None for code without extensions. Within the extension-methods family (not yet released, so these are proposal-internal changes):
	+
	+	* Redeclaring a named extension — or naming one after an existing class — was silently tolerated by the registry's first-wins rule; it is now a fatal error, consistent with classes.
	+	* ''class_exists()'' answers ''true'' for loaded named extensions.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	Same release as the base Extension Methods RFC; meaningful only if the [[rfc:extension_method_visibility\|visibility RFC]] is accepted (anonymous extensions have no names to load).
	+
	+	===== RFC Impact =====
	+
	+	==== To the Ecosystem ====
	+
	+	This is the RFC Composer has been waiting on: [[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]] maps ''extension Name on Target $recv { }'' declarations into the class map and is held as draft only until this family's grammar is final. Static analyzers gain a stronger property: an unimported extension call is now //provably// unresolvable (before, a global ''require'' anywhere could have loaded an anonymous extension), and IDE "missing import" quick-fixes can offer ''use extension'' exactly as they offer ''use''.
	+
	+	==== To Existing Extensions ====
	+
	+	One new executor-global (the per-request attempted-names table, lazily allocated) — an ABI change of the routine minor-version kind. The class-table entries for named extensions are alias-typed (''IS_ALIAS_PTR''), the same mechanism ''class_alias()'' uses, so C code iterating the class table must already tolerate them.
	+
	+	==== To SAPIs ====
	+
	+	None. The negative cache is request-scoped and resets with the executor.
	+
	+	==== To Opcache ====
	+
	+	Import sets simply carry one more interned string per import (the original-case name), persisted through the exact machinery the visibility RFC already uses — the persistence code iterates elements and needed no changes. The synthetic CE's name and uninstantiable flag are set at compile time, preserving the family invariant that the persisted script image is never mutated at runtime; the class-table binding at execution writes only to the per-request class table, never to shared memory. Verified green: full Zend suite under ''opcache.protect_memory=1'' and under tracing and function JIT.
	+
	+	===== Open Issues =====
	+
	+	- The instantiation error message. ''new Vendor\Name'' currently reports "Cannot instantiate abstract class" (the CE reuses the abstract-class instantiation guard). A bespoke "Cannot instantiate extension %s" needs either a spare CE flag or an extension-CE discriminator; cosmetic, but worth fixing before final vote.
	+	- Reflection classification. ''ReflectionClass'' works today (''getName()'' returns the extension name, ''isInstantiable()'' is ''false''), but the synthetic CE also reports ''isAnonymous() === true'' — an artifact of its construction. The family's deferred reflection surface (''ReflectionExtension''-style first-class API) should subsume this.
	+	- Negative-cache staleness. A loader registered //after// a failed attempt for a name will not be re-consulted for it that request (registering loaders before first use is the universal practice, and Composer's bootstrap guarantees it — but the asymmetry with classes, which retry every time because failure throws, deserves a sentence in the docs).
	+
	+	===== Unaffected PHP Functionality =====
	+
	+	Class autoloading itself is untouched — extensions ride the existing chain; no new autoloader hook, no new callback signature, no changes to ''spl_autoload_register''. Anonymous extensions, gating semantics, and everything listed in the prior RFCs' unaffected sections.
	+
	+	===== Future Scope =====
	+
	+	* Target-hint accelerated loading. If extension-heavy frameworks materialize, the load-all-imports batch can be narrowed without new syntax and without trusting external metadata for dispatch. Composer's class-map generator already parses the declaration's target token ([[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]]); it can emit a ''name → target'' map from that single source of truth, and Composer's bootstrap pushes it into the engine through a small registration API (the ''spl_autoload_register'' idiom — there is deliberately no query protocol in the autoload chain, so hints must be pushed, not fetched). At miss time the engine loads ancestry-matching (and unhinted) imports first, and the remainder only if the miss persists: a stale or missing hint costs a fallback pass, never correctness. Three design constraints are recorded now, in advance: (1) //omit on uncertainty// — a textual generator cannot fully reimplement PHP's name resolution for aliased targets, so it must emit a hint only when the target resolves trivially, and an absent hint means always-candidate; (2) //no per-request copy// — registration must hold a reference to the opcache-shared array (or a lazy provider), not rebuild an engine table each request, per this family's own rejection of per-request setup work; (3) //prerequisite:// import-set-aware conflict resolution (visibility RFC Open Issue 1) must land first — under first-wins registration, hint-driven load order would let generated metadata select conflict winners, and only ambiguity-is-an-Error makes load order semantically inert.
	+	* Moving the method registry into executor globals (per-request lifetime) — this RFC makes the class-table half of extension state per-request already; the registry keeps the prototype's process-global caveat.
	+	* A ''use extension'' quick-fix diagnostic ("did you forget to import?") remains as proposed in the visibility RFC.
	+
	+	===== Voting Choices =====
	+
	+	Primary vote requiring a 2/3 majority (per the [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting-phase\|php/policies voting guidelines]]); void if the visibility RFC is declined:
	+
	+	> Autoload named extensions through the class autoloader as outlined in the RFC? Yes / No
	+
	+	===== Patches and Tests =====
	+
	+	Implemented on the [[https://github.com/hollyschilling/php-src/tree/extension-methods-autoload\|extension-methods-autoload]] branch, stacked on the visibility RFC's ''extension-methods'' branch — [[https://github.com/hollyschilling/php-src/compare/extension-methods...extension-methods-autoload\|the diff between the two branches]] is exactly this proposal. ''Zend/tests/extension_methods/'' adds: first-use autoload with a one-invocation loader (''autoload_basic.phpt''), the scalar dispatch path (''autoload_scalar.phpt''), ''class_exists''/instantiation/reflection of the class-table symbol (''autoload_class_symbol.phpt''), name collision fatality (''autoload_collision.phpt''), negative caching of unloadable imports (''autoload_negative_cache.phpt''), autoloader exception propagation on both object and scalar paths (''autoload_throw.phpt''), and gating unaffected by autoloading (''autoload_gating.phpt''). Full matrix green: plain, ''opcache.protect_memory=1'', tracing and function JIT.
	+
	+	===== Implementation =====
	+
	+	After acceptance: link to the merged commit(s), PHP version, and documentation.
	+
	+	===== References =====
	+
	+	* Visibility RFC (dependency): [[rfc:extension_method_visibility\|PHP RFC: Extension Method Visibility]]
	+	* Base RFC: [[rfc:extension_methods\|PHP RFC: Extension Methods]]
	+	* Composer class-map support (draft PR): https://github.com/composer/class-map-generator/pull/43
	+	* PSR-4 ("other similar structures"): https://www.php-fig.org/psr/psr-4/
	+
	+	===== Rejected Features =====
	+
	+	* A dedicated extension-autoloader hook (''spl_autoload_register_extension'' or a new callback signature) — a second autoload chain doubles the bootstrap surface of every framework for zero expressive gain; the class chain already delivers name→file resolution, and Composer needs one map, not two.
	+	* Eager loading at the ''use extension'' statement — would make one ''use'' form a runtime construct (the visibility RFC's rejected activation opcode, one layer up), punish speculative imports, and break the position-independence consumers expect from imports.
	+	* A registry-only symbol (no class-table entry) — a parallel name table would need its own collision policy against classes, its own ''class_exists'' analog, and its own autoload recursion guards; the class table already has all three, and sharing it is what makes the collision rule enforceable rather than advisory.
	+	* Import-site target claims (''use extension Vendor\Name for Target;'') — proposed to narrow the load-all-imports batch, but the claim is unverifiable at the moment it steers loading: the declaration is, by definition, not loaded yet, so the claim can only be checked //after// the load it was meant to optimize. A claim stale in the narrow direction — the library widened ''on DOMElement'' to ''on DOMNode'', or the consumer named the class where the extension targets its interface — makes the engine skip a load it needed, producing a wrong "Call to undefined method" for a correctly imported, correctly published extension: silent misbehavior, the worst failure class. Preventing it requires a load-time ''Error'' on mismatch, which turns every import into a contract on the library's target choice and breaks consumers whenever a library performs the //good// refactor of widening its target. And since a claim can be wrong, correctness still requires the load-the-rest fallback — the syntax only reorders work the engine must be able to do anyway. The target-hint design in Future Scope achieves the same filtering from the declaration itself, with no consumer-side contract.
	+	* Method-indexed autoload metadata as a resolution key — an external index of extension names to targets and methods, consulted to decide //dispatch//. The engine would be trusting a generated, stale-able artifact for language-semantics decisions. External metadata is acceptable only as a load-ordering hint with a full fallback pass (Future Scope), never as the thing that decides whether a method exists.
	+
	+	===== Changelog =====
	+
	+	* 1.1 (2026-07-11): added "Why the import set is the resolution key" (no method→extension map exists before load; the finite import set is what distinguishes this from function autoloading); rejected import-site target claims (''use extension ... for Target'') and method-indexed metadata as a resolution key; specified the target-hint loading optimization in Future Scope with its three design constraints, including the conflict-resolution prerequisite.
	+	* 1.0 (2026-07-11): initial draft, written alongside the phase-3 implementation.

extension_method_visibility - created

thecodelorax (thecodelorax@undisclosed.example.com) — 2026-07-12T02:01:57+00:00

2026/07/15 00:33	current
Line 1:	Line 1:
	+	====== PHP RFC: Extension Method Visibility (use extension) ======
	+	* Version: 1.5
	+	* Date: 2026-07-07
	+	* Author: Holly Schilling, holly.a.schilling@outlook.com
	+	* Status: Draft
	+	* Depends on: [[rfc:extension_methods\|PHP RFC: Extension Methods]]
	+	* Implementation: https://github.com/hollyschilling/php-src/tree/extension-methods
	+	* Discussion thread: tbd
	+	* Voting thread: tbd
	+
	+	===== Introduction =====
	+
	+	The [[rfc:extension_methods\|Extension Methods RFC]] gives extensions //load-gated// visibility: once a file declaring ''extension Target { }'' has executed, its methods are resolvable from anywhere in the request, exactly like a declared function. That is the right default for application-local helpers, but it is a poor fit for libraries: two Composer packages extending the same vendor class become visible to each other and to all application code, whether wanted or not, and the consumer has no way to see where a method came from.
	+
	+	This RFC adds the opt-in scoping layer: named extension blocks and ''use extension'' imports. A named extension's methods resolve only in files that imported it. This follows Kotlin's model (extension functions must be imported to be callable) rather than C#'s namespace-scoped variant, because PHP's natural scoping unit — like Kotlin's — is the file.
	+
	+	<code php>
	+	// vendor/acme/dom-kit/src/traversal.php
	+	namespace Acme\DomKit;
	+
	+	extension DomTraversal on \DOMElement $el {
	+	public function firstByClass(string $class): ?\DOMElement { /* ... */ }
	+	}
	+	</code>
	+
	+	<code php>
	+	// app/render.php
	+	use extension Acme\DomKit\DomTraversal;
	+
	+	$el->firstByClass('hero'); // resolves here
	+	</code>
	+
	+	<code php>
	+	// app/other.php — no import
	+	$el->firstByClass('hero'); // Error: Call to undefined method DOMElement::firstByClass()
	+	</code>
	+
	+	===== Proposal =====
	+
	+	==== Syntax ====
	+
	+	Two additions to the base RFC's grammar:
	+
	+	* Named declaration: ''extension Name on Target $recv { methods }'' (the receiver variable is required, as in the base RFC's anonymous form). ''Name'' follows class-declaration rules: an unqualified identifier, namespaced by the file's current namespace. ''on'' is a contextual identifier (not a reserved word) validated by the grammar; any other word in that position is a compile error. The anonymous form ''extension Target $recv { }'' remains valid and keeps its globally-visible semantics.
	+	* Import: ''use extension Vendor\Name;'' as a dedicated top-level ''use'' form. Multiple comma-separated names are allowed. Two deliberate restrictions:
	+	* No aliasing. ''use extension Foo as Bar;'' is a compile error. The import is //activation//, not renaming — there is no local identifier to alias, and method names must match the declaration regardless.
	+	* No group-use form. ''use extension Vendor\{A, B};'' is not supported in this RFC. (Besides being marginal, admitting ''extension'' inside group-use braces measurably degrades existing parse-error messages by overflowing the parser's expected-token reporting; see Open Issues.)
	+
	+	==== Semantics ====
	+
	+	- Imports are per compilation unit and position-sensitive. ''use extension'' makes the named extension visible to code compiled //after// it in the current file — exactly the rule every other ''use'' import follows. Each ''eval()'' chunk is its own compilation unit: it may import independently, and its imports do not leak into the surrounding file. (One lenient corner: a file's top-level code is a single unit and receives the file's full import set; functions and methods snapshot the set as of their declaration point. PSR-12 places imports at the top of the file, where the distinction never arises.)
	+	- Resolution is gated by the executing frame. When the base RFC's fallback finds a method belonging to a named extension, it is returned only if the nearest user-code frame's file has activated that extension; otherwise the walk continues (a parent class or interface may still supply a visible method). Consequences:
	+	* Visibility follows //where the code was written//, not who called it: a helper function defined in an importing file can use the extension even when invoked from a non-importing file.
	+	* Indirect calls (''call_user_func'' et al., inherited from the base RFC's open issue) are gated from the nearest user frame, so an internal-function trampoline does not widen visibility.
	+	- The declaring position imports itself. A named extension is visible to its own methods and to code below its declaration in the declaring file, without a self-import (matching Kotlin: same-file extensions need no import).
	+	- Scalar targets gate identically (if the [[rfc:extension_methods_scalars\|Scalar Extension Methods RFC]] is accepted). A named extension on a built-in value type (''extension Str on string'') is gated exactly like a class-targeted one — which is what makes competing userland scalar APIs coexist: each file imports the string vocabulary it wants. The gating test (''scalar_named_gating.phpt'') ships with this RFC's branch.
	+	- Importing is not loading — the same rule as every other ''use'' statement. A plain ''use A\B;'' does not load class ''B'' either; it only affects name resolution, and the class is loaded later, on first use, by the autoloader. ''use extension'' follows the first half of that model: it only grants visibility, and is inert until the extension's declaring file has executed (''require'', Composer ''files'' — the base RFC's load-gating). What it does //not// yet do is the second half — trigger autoloading on first use: calling a method of an imported-but-never-loaded extension is simply the ordinary "Call to undefined method" error, and no autoloader is consulted. Two consequences worth stating explicitly: importing an extension that never loads is not an error (like an unused ''use'' import), and the relative order of import and load does not matter — resolution works as soon as both have happened. So, to answer the recurring question directly — //"do I need the ''use extension'' statement and a ''require_once''?"// — yes, both must happen, but usually not both by you. Loading is the declaring package's job: in a Composer project it lists its extension files under its ''autoload.files'' directive, which Composer executes once at bootstrap (exactly how function files ship today), so consumer code writes only the ''use extension'' line. A manual ''require_once'' is needed only when no bootstrap loads the declaring file for you — the same situation in which a plain function from that file would also be undefined. And this answer has an expiry date: both halves of the fix exist. The ecosystem half is [[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]] (draft), which teaches Composer's class-map generator to map named extension declarations to their files exactly as it maps classes; the engine half is the companion [[rfc:extension_methods_autoload\|Extension Method Autoloading RFC]], implemented on its own branch. With both accepted, no ''require_once'' — and no package-side ''files'' entry — is required at all: the ''use extension'' line alone both grants visibility and, on first use, loads the declaring file, because the named form exists precisely so extension names are PSR-4 addressable.
	+	- Precedence is unchanged from the base RFC: real method → ''<nowiki>__call</nowiki>'' → extension lookup. Anonymous (global) and named (imported) extensions live in one registry; within a target, the first registered method still wins (but see Open Issues).
	+
	+	==== Implementation notes ====
	+
	+	''ZEND_BIND_EXTENSION'' gains the lowercased fully-qualified extension name as the literal following the target-name literal (consecutive-literal pattern, presence flagged via ''extended_value''); registry entries carry their extension name. Import sets are a compile-time property of the ''zend_op_array'' itself: a small packed table of lc names, shared (copy-on-write per import statement) between the op_arrays of one file, snapshotted by pointer as each function is compiled, and persisted by opcache exactly like attributes. Resolution reads the set directly off the nearest user frame's op_array — there is no global activation state of any kind. The grammar factors the shared ''T_EXTENSION'' prefix of the anonymous and named forms into one nonterminal (an LALR requirement, not a design choice).
	+
	+	==== Performance ====
	+
	+	Gating adds, on the extension-resolution slow path only, one walk to the nearest user frame plus a linear scan of that op_array's import set (import sets are a handful of interned names; the scan is cheaper than a hash lookup). Ordinary method calls remain untouched, and there is zero per-request setup cost — imports are read-only compiled data. For the future inline-cache phase, this design is load-bearing: call-site caches are per-''op_array'', an ''op_array'' belongs to exactly one file, and its import set is immutable after compilation, so a cached resolution can never leak across visibility boundaries — op_array-resident imports make call-site caching //inherently// scope-correct.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	None beyond the base RFC. The named form and ''use extension'' were syntax errors under the base RFC (and under current PHP). ''use extension;'' — importing a class literally named ''extension'' — continues to parse as a class import, because ''T_EXTENSION'' is only lexed when followed by another identifier.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	Same release as the base Extension Methods RFC; this RFC is only meaningful if that one is accepted.
	+
	+	===== RFC Impact =====
	+
	+	==== To the Ecosystem ====
	+
	+	Tooling that learned the base RFC's ''extension'' blocks needs two additions, both static: the named declaration form, and per-file visibility driven by ''use extension'' lines. The latter is the same shape of analysis IDEs and static analyzers already perform for ''use'' imports, and it makes extension-call resolution //more// tractable for tools than the base RFC alone: instead of "any loaded extension might apply", a file's candidate set is enumerable from its imports. Analyzers should flag calls to named-extension methods in files that did not import them — mirroring the engine's behavior at analysis time.
	+
	+	==== To Existing Extensions ====
	+
	+	None; the changes are confined to the extension-methods registry and its resolution path.
	+
	+	==== To SAPIs ====
	+
	+	None. (Import visibility carries no per-request or per-process state at all; only the base RFC's registry retains the prototype's process-global lifetime caveat.)
	+
	+	==== To Opcache ====
	+
	+	Import sets are part of the compiled artifact, so opcache correctness falls out by construction. Because the set lives in the ''zend_op_array'' (like attributes, literals, or static variables), it is persisted to shared memory with the script, serialized by ''file_cache'', and preserved by ''opcache.preload'' — the three modes in which a file executes without being recompiled. There is no side-band activation state to restore, no per-request replay work, and nothing keyed by filename identity (symlinks, phars, and same-file-different-path cannot split visibility). The cost is one pointer field on ''zend_op_array'' (an ABI change for extensions inspecting op_arrays, routine for a minor version) plus contained additions to ''zend_persist'' and ''zend_file_cache'' following the existing ''attributes'' pattern.
	+
	+	Two designs were considered and rejected (see Rejected Features): a runtime activation opcode repopulating per-request state — disqualified because preloaded files' top-level code never executes in a request, recreating the very compile-versus-execute split this design must eliminate — and opcache-persisted side tables replayed on cache load, which touch every load path (SHM, file_cache, preload) for strictly less benefit.
	+
	+	This RFC preserves the base RFC's invariant that the persisted script image is never mutated at runtime. Bind-time registration and call-time gating only //read// the cached image (the CE, the target-name/extension-name literal pair, and the import set); the only writable state — the registry with its provenance entries — lives in engine-owned memory outside shared memory. Because the named form stores the extension name as the literal //following// the target name, opcache's literal-compaction pass must relocate the pair together; the implementation registers ''ZEND_BIND_EXTENSION'' with the compaction pass exactly as ''ZEND_INIT_METHOD_CALL'' registers its paired method-name literals. Verified against ''opcache.enable_cli=1 + opcache.protect_memory=1'', ''opcache.jit=tracing'', ''opcache.file_cache_only'' round-trips across processes, and ''opcache.preload''.
	+
	+	===== Open Issues =====
	+
	+	- Import-set-aware conflicts. Registration is first-wins per (target, method) across //all// extensions. If two named extensions supply the same method for the same target, the later one loses even in files that import only the later one. Correct behavior needs per-extension method lists consulted against the caller's import set, with ambiguity (two //imported// extensions supplying one method) becoming an ''Error'' at the call site. This issue now gates future work: the companion [[rfc:extension_methods_autoload\|autoloading RFC]]'s target-hint optimization requires load order to be semantically inert, which only ambiguity-is-an-Error provides — first-wins plus autoloading would otherwise let load order (and eventually generated metadata) select conflict winners.
	+	- Group-use form. Excluded here; admitting it later requires either accepting degraded parse-error messages in group-use states or custom syntax-error reporting.
	+	- Re-export. Should a file be able to re-export its imports (Kotlin has no equivalent; ES modules do)? Currently: no, every consumer imports explicitly.
	+
	+	===== Unaffected PHP Functionality =====
	+
	+	Everything listed in the base RFC, plus: anonymous extension blocks keep their exact base-RFC semantics — this RFC is purely additive, and code that never writes ''on'' or ''use extension'' cannot observe it.
	+
	+	===== Future Scope =====
	+
	+	* Autoload triggering has graduated from future scope to a proposal: the companion [[rfc:extension_methods_autoload\|Extension Method Autoloading RFC]] resolves an unloaded ''use extension Vendor\Name'' through the class autoloader at first use, registering the synthetic CE in the class table under its extension name (the "leading candidate" design, now implemented). PSR-4 itself requires no amendment (its "other similar structures" wording covers extensions, as it did enums), and Composer's class-map generator already has a draft PR — [[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]] — held as draft only until this RFC family's grammar is final.
	+	* Inline-cache and JIT fast path for gated resolution (per-op_array caches, as noted under Performance).
	+	* Diagnostics: a "did you forget ''use extension Vendor\Name''?" hint on the undefined-method error when a loaded-but-unimported extension would have matched.
	+
	+	===== Voting Choices =====
	+
	+	Primary vote requiring a 2/3 majority to accept the RFC (per the [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting-phase\|php/policies voting guidelines]]); void if the base Extension Methods RFC is declined:
	+
	+	> Add named extension blocks and use extension visibility as outlined in the RFC? Yes / No
	+
	+	===== Patches and Tests =====
	+
	+	Implemented on the [[https://github.com/hollyschilling/php-src/tree/extension-methods\|extension-methods]] branch as a single commit atop the ''extension-methods-scalars'' branch (which in turn stacks on the base RFC's ''extension-methods-phase1'') — [[https://github.com/hollyschilling/php-src/compare/extension-methods-scalars...extension-methods\|the diff between the two adjacent branches]] is exactly this proposal (including its opcache literal-compaction support for the named form's paired literals). Verified on a debug build with the full Zend test suite green. ''Zend/tests/extension_methods/'' covers: named declaration with declaring-file auto-activation (''named_basic.phpt''), imports (''use_extension.phpt''), gating across files, helper-function frames, and independent ''eval()'' scopes (''lexical_gating.phpt''), and the ''on''/alias syntax errors (''named_syntax_errors.phpt'').
	+
	+	===== Implementation =====
	+
	+	After acceptance: link to the merged commit(s), PHP version, and documentation.
	+
	+	===== References =====
	+
	+	* Base RFC: [[rfc:extension_methods\|PHP RFC: Extension Methods]]
	+	* Companion (depends on this RFC): [[rfc:extension_methods_autoload\|PHP RFC: Extension Method Autoloading]]
	+	* Kotlin extension imports (per-file visibility precedent): https://kotlinlang.org/docs/extensions.html#scope-of-extensions
	+	* C# extension methods (namespace-scoped alternative): https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods
	+	* Composer class-map support for named extensions (draft PR): https://github.com/composer/class-map-generator/pull/43
	+
	+	===== Rejected Features =====
	+
	+	* Aliasing extension imports (''use extension Foo as Bar'') — imports activate, they do not name; there is nothing an alias would refer to.
	+	* Namespace-scoped visibility (C# model) — PHP namespaces span files and vendors; the file is the unit a reader can actually see, and it is the unit call-site caches naturally respect.
	+	* Runtime activation opcode (per-request executor-globals table repopulated by an op emitted for each ''use extension'') — it would make one ''use'' form a runtime construct, add per-request setup work of exactly the kind opcache exists to eliminate, and — decisively — break under ''opcache.preload'': preloaded files' top-level code never executes in a request, so their activations would silently never fire, reproducing the original compile-versus-execute bug one layer down.
	+	* Opcache-persisted activation side tables (import sets stored alongside the cached script and replayed on load) — requires cooperation from every load path (SHM hit, ''file_cache'' deserialization, preload) and keeps activation keyed by filename identity; op_array-resident sets achieve the same persistence through machinery opcache already has, with none of the replay surface.
	+
	+	===== Changelog =====
	+
	+	* 1.5 (2026-07-11): autoload triggering moved from Future Scope to the companion [[rfc:extension_methods_autoload\|Extension Method Autoloading RFC]] (implemented on the ''extension-methods-autoload'' branch); loading discussion and References updated accordingly; noted under Open Issues that first-wins conflict resolution now gates the companion RFC's planned load optimizations.
	+	* 1.4 (2026-07-11): referenced the Composer class-map generator draft PR ([[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]]) in the loading discussion, Future Scope, and References; stated the end state of the loading story — once that PR and the engine-side autoload trigger land, ''use extension'' alone suffices and no ''require_once'' or ''autoload.files'' entry is needed.
	+	* 1.3 (2026-07-10): named form updated for the base RFC's declared receiver variable (''extension Name on Target $recv''); clarified that importing is not loading, mirroring the semantics of every other ''use'' statement (reader feedback).
	+
	+	* 1.2 (2026-07-08): resolved the activation-persistence open issue — import sets are now a compile-time property of the ''zend_op_array'', persisted by opcache (SHM, ''file_cache'', preload all verified); imports became position-sensitive like other ''use'' statements; rejected the runtime-activation-opcode and persisted-side-table designs (preload argument recorded under Rejected Features).
	+	* 1.1 (2026-07-08): documented the shared-memory invariant inherited from the base RFC and the literal-compaction requirement for the named form's paired literals; implementation verified under ''opcache.protect_memory=1'' and ''opcache.jit=tracing''.
	+	* 1.0 (2026-07-07): initial draft, written alongside the phase-2 prototype.

extension_methods_visibility - Added clarification on autoloading

thecodelorax (thecodelorax@undisclosed.example.com) — 2026-07-11T18:02:21+00:00

2026/07/11 16:25		current
Line 1:		Line 1:
	====== PHP RFC: Extension Method Visibility (use extension) ======		====== PHP RFC: Extension Method Visibility (use extension) ======
-	* Version: 1.3	+	* Version: 1.4
	* Date: 2026-07-11		* Date: 2026-07-11
	* Author: Holly Schilling, holly.a.schilling@outlook.com		* Author: Holly Schilling, holly.a.schilling@outlook.com
Line 55:		Line 55:
	- The declaring position imports itself. A named extension is visible to its own methods and to code below its declaration in the declaring file, without a self-import (matching Kotlin: same-file extensions need no import).		- The declaring position imports itself. A named extension is visible to its own methods and to code below its declaration in the declaring file, without a self-import (matching Kotlin: same-file extensions need no import).
	- Scalar targets gate identically (if the [[rfc:extension_methods_scalars\|Scalar Extension Methods RFC]] is accepted). A named extension on a built-in value type (''extension Str on string'') is gated exactly like a class-targeted one — which is what makes competing userland scalar APIs coexist: each file imports the string vocabulary it wants. The gating test (''scalar_named_gating.phpt'') ships with this RFC's branch.		- Scalar targets gate identically (if the [[rfc:extension_methods_scalars\|Scalar Extension Methods RFC]] is accepted). A named extension on a built-in value type (''extension Str on string'') is gated exactly like a class-targeted one — which is what makes competing userland scalar APIs coexist: each file imports the string vocabulary it wants. The gating test (''scalar_named_gating.phpt'') ships with this RFC's branch.
-	- **Loading is still required. ''use extension'' does not load or autoload anything in this RFC; it only grants visibility. The extension's declaring file must still have executed (''require'', Composer ''files'') before calls resolve — the same load-gating as the base RFC. Autoload triggering is Future Scope, and the named form exists precisely so that a future ''use extension'' can resolve the name through** PSR-4.	+	- **Importing is not loading — the same rule as every other ''use'' statement. A plain ''use A\B;'' does not load class ''B'' either; it only affects name resolution, and the class is loaded later, on first use, by the autoloader. ''use extension'' follows the first half of that model: it only grants visibility, and is inert until the extension's declaring file has executed (''require'', Composer ''files'' — the base RFC's load-gating). What it does //not// yet do is the second half — trigger autoloading on first use: calling a method of an imported-but-never-loaded extension is simply the ordinary "Call to undefined method" error, and no autoloader is consulted. Two consequences worth stating explicitly: importing an extension that never loads is not an error (like an unused ''use'' import), and the relative order of import and load does not matter — resolution works as soon as both have happened. So, to answer the recurring question directly — //"do I need the ''use extension'' statement and a ''require_once''?"// — yes, both must happen, but usually not both by you. Loading is the declaring package's job: in a Composer project it lists its extension files under its ''autoload.files'' directive, which Composer executes once at bootstrap (exactly how function files ship today), so consumer code writes only the ''use extension'' line. A manual ''require_once'' is needed only when no bootstrap loads the declaring file for you — the same situation in which a plain function from that file would also be undefined. And this answer has an expiry date: autoload triggering is Future Scope, and the ecosystem half of it is already staged — [[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]] (draft) teaches Composer's class-map generator to map named extension declarations to their files exactly as it maps classes. Once that PR and the engine-side trigger are merged, no ''require_once'' — and no package-side ''files'' entry — is required at all: the ''use extension'' line alone both grants visibility and, on first use, loads the declaring file, because the named form exists precisely so extension names are PSR-4 addressable**.
	- Precedence is unchanged from the base RFC: real method → ''<nowiki>__call</nowiki>'' → extension lookup. Anonymous (global) and named (imported) extensions live in one registry; within a target, the first registered method still wins (but see Open Issues).		- Precedence is unchanged from the base RFC: real method → ''<nowiki>__call</nowiki>'' → extension lookup. Anonymous (global) and named (imported) extensions live in one registry; within a target, the first registered method still wins (but see Open Issues).

Line 108:		Line 108:
	===== Future Scope =====		===== Future Scope =====

-	* Autoload triggering: resolve an unloaded ''use extension Vendor\Name'' through the class autoloader at first use, making named extensions fully PSR-4 addressable. Requires deciding what artifact the autoloader maps the name to (the synthetic CE registered under its extension name is the leading candidate).	+	* Autoload triggering: resolve an unloaded ''use extension Vendor\Name'' through the class autoloader at first use, making named extensions fully PSR-4 addressable. Requires deciding what artifact the autoloader maps the name to (the synthetic CE registered under its extension name is the leading candidate). The tooling side needs no waiting: PSR-4 itself requires no amendment (its "other similar structures" wording covers extensions, as it did enums), and Composer's class-map generator already has a draft PR — [[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]] — mapping named extension declarations, held as draft only until this RFC family's grammar is final. Only the engine-side trigger remains.
	* Inline-cache and JIT fast path for gated resolution (per-op_array caches, as noted under Performance).		* Inline-cache and JIT fast path for gated resolution (per-op_array caches, as noted under Performance).
	* Diagnostics: a "did you forget ''use extension Vendor\Name''?" hint on the undefined-method error when a loaded-but-unimported extension would have matched.		* Diagnostics: a "did you forget ''use extension Vendor\Name''?" hint on the undefined-method error when a loaded-but-unimported extension would have matched.
Line 131:		Line 131:
	* Kotlin extension imports (per-file visibility precedent): https://kotlinlang.org/docs/extensions.html#scope-of-extensions		* Kotlin extension imports (per-file visibility precedent): https://kotlinlang.org/docs/extensions.html#scope-of-extensions
	* C# extension methods (namespace-scoped alternative): https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods		* C# extension methods (namespace-scoped alternative): https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods
		+	* Composer class-map support for named extensions (draft PR): https://github.com/composer/class-map-generator/pull/43

	===== Rejected Features =====		===== Rejected Features =====
Line 141:		Line 142:
	===== Changelog =====		===== Changelog =====

-	* 1.3 (2026-07-10): named form updated for the base RFC's declared receiver variable (''extension Name on Target $recv'').	+	* 1.4 (2026-07-11): referenced the Composer class-map generator draft PR ([[https://github.com/composer/class-map-generator/pull/43\|composer/class-map-generator#43]]) in the loading discussion, Future Scope, and References; stated the end state of the loading story — once that PR and the engine-side autoload trigger land, ''use extension'' alone suffices and no ''require_once'' or ''autoload.files'' entry is needed.
		+	* 1.3 (2026-07-10): named form updated for the base RFC's declared receiver variable (''extension Name on Target $recv''); clarified that importing is not loading, mirroring the semantics of every other ''use'' statement (reader feedback).

	* 1.2 (2026-07-08): resolved the activation-persistence open issue — import sets are now a compile-time property of the ''zend_op_array'', persisted by opcache (SHM, ''file_cache'', preload all verified); imports became position-sensitive like other ''use'' statements; rejected the runtime-activation-opcode and persisted-side-table designs (preload argument recorded under Rejected Features).		* 1.2 (2026-07-08): resolved the activation-persistence open issue — import sets are now a compile-time property of the ''zend_op_array'', persisted by opcache (SHM, ''file_cache'', preload all verified); imports became position-sensitive like other ''use'' statements; rejected the runtime-activation-opcode and persisted-side-table designs (preload argument recorded under Rejected Features).

extension_methods_scalars - created

thecodelorax (thecodelorax@undisclosed.example.com) — 2026-07-11T14:16:36+00:00

2026/07/15 00:33	current
Line 1:	Line 1:
	+	====== PHP RFC: Scalar Extension Methods ======
	+	* Version: 2.0
	+	* Date: 2026-07-11
	+	* Author: Holly Schilling, holly.a.schilling@outlook.com
	+	* Status: Draft
	+	* Depends on: [[rfc:extension_methods\|PHP RFC: Extension Methods]]
	+	* Implementation: https://github.com/hollyschilling/php-src/tree/extension-methods-scalars
	+	* Discussion thread: tbd
	+	* Voting thread: tbd
	+
	+	===== Introduction =====
	+
	+	The [[rfc:extension_methods\|Extension Methods RFC]] lets code declare additional methods for existing classes and interfaces, resolved only where PHP would otherwise raise an undefined-method error. This RFC extends the same construct to the built-in value types:
	+
	+	<code php>
	+	extension string $s {
	+	public function length(): int { return strlen($s); }
	+	}
	+
	+	var_dump("hello"->length()); // int(5)
	+	</code>
	+
	+	Every previous attempt at "scalar methods" for PHP has foundered on the same rock: designing the API. Which methods does ''string'' get, what are they named, how do the legacy argument orders map — a bikeshed with no exit. This RFC dissolves that problem rather than solving it: PHP ships the mechanism and zero methods. Userland defines, names, versions, and ships the scalar APIs as ordinary Composer packages, and with the [[rfc:extension_method_visibility\|lexical visibility RFC]] competing scalar vocabularies cannot collide — each file imports the string API it wants. The language never has to bless anyone's ''length()''.
	+
	+	Why a separate RFC. The base RFC's implementation is contained to the method-resolution miss path: if it is buggy, only code calling extension methods is affected. Value receivers still touch more of the engine than that — dispatch on the non-object call path and a brief handoff through the call frame — even though the base RFC's declared-receiver model (adopted //because// of this RFC; see the base RFC's Rejected Features) reduced the footprint to a fraction of earlier designs. It is co-proposed and fully implemented, but it deserves to be reviewed and voted on its own merits rather than riding on (or dragging down) the base proposal.
	+
	+	===== Proposal =====
	+
	+	==== Targets ====
	+
	+	The five built-in value types become valid extension targets: ''string'', ''int'', ''float'', ''bool'' (covering ''true'' and ''false'' receivers), and ''array''. Scalar targets are matched on the raw unqualified name, never namespace-prefixed: ''extension string'' inside ''namespace App'' targets the built-in type, not ''App\string''. All other reserved type names (''iterable'', ''mixed'', ''object'', ''null'', ...) remain compile errors, as in the base RFC. ''null'' is deliberately not extendable — calls on ''null'' keep their existing error, and the nullsafe operator's short-circuit is unaffected.
	+
	+	Named extensions and ''use extension'' compose unchanged: ''extension Str on string $s { }'' is lexically gated exactly like a class-targeted named extension — which is precisely what lets competing userland scalar APIs coexist.
	+
	+	==== Semantics ====
	+
	+	- Dispatch. A method call on a scalar is //unconditionally fatal// in PHP today, so this is the base RFC's error-path-only principle in its purest form: resolution sits exactly where "Call to a member function on string" is raised, keyed by the receiver's value type. No successful program changes behavior.
	+	- The declared receiver holds the value. ''extension string $s'' binds each method's receiver into ''$s'' — an ordinary by-value local, exactly like a parameter: mutation is local and does not propagate to the caller, which is PHP's value-type semantics stated in syntax. Chained calls — ''<nowiki>$s->shout()</nowiki>'' inside another string extension method — work naturally, and generators work (the receiver variable is populated before a generator's frame is captured).
	+	- One restriction remains: first-class callables of scalar extension methods throw an ''Error'' for now — a closure cannot yet carry a by-value receiver binding. Object-targeted extension methods support them; extending that to scalars is Future Scope. (''$this'', ''static::'', magic methods, and abstract methods are already rejected family-wide by the base RFC.)
	+	- Direct calls only, by construction. Callable arrays require objects, so ''call_user_func'' and friends can never reach a scalar extension method: the base RFC's open question about indirect invocation does not arise for scalars.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	None. Every call this RFC makes resolvable is a fatal ''Error'' today, and ''extension string { }'' is a compile error under the base RFC.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	Same release as the base Extension Methods RFC.
	+
	+	===== RFC Impact =====
	+
	+	==== To the Ecosystem ====
	+
	+	Tooling that learned the base RFC's blocks needs one addition: the five type names as targets, with methods surfaced in completion on receivers of the matching static type. The same static analysis that resolves extension calls on classes applies; there is no runtime discovery to model.
	+
	+	==== To Existing Extensions ====
	+
	+	The engine surface beyond the base RFC is small and narrow, and this section states it plainly:
	+
	+	* A brief frame handoff. The scalar rides in the call frame's ''This'' slot (call-info bits preserved) only from call initialization until the body's first ''ZEND_RECV_RECEIVER'' instruction, which moves it into the declared variable, nulls the slot, and clears the release flag — the rest of the call is an ordinary scoped frame, and the receiver is freed by ordinary CV cleanup. Teardown paths discriminate for that narrow window by the receiver's type bits (the value types ''IS_FALSE''..''IS_ARRAY'', which no legacy frame stores there) — deliberately //not// by inspecting ''<nowiki>call->func</nowiki>'', which may already be a freed trampoline at teardown time.
	+	* JIT. Scalar-receiver bodies are excluded from JIT compilation (generated code must never observe the non-object handoff), matching the base RFC's existing rule that traces never follow into never-cached callees. Calls from JIT'd code dispatch correctly through the interpreter paths. JIT support for scalar bodies is Future Scope.
	+	* Extensions that inspect in-flight call frames directly and assume ''RELEASE_THIS'' implies an object ''This'' would need the same type-bits discrimination the engine now applies during the handoff window.
	+
	+	==== To SAPIs ====
	+
	+	None beyond the engine changes.
	+
	+	==== To Opcache ====
	+
	+	Nothing new beyond the base RFC: the flag is compile-time state persisted with the op_array; the registry lanes reuse the base registry. Verified under ''opcache.protect_memory=1'', ''file_cache'', and both JIT modes with aggressive hotness settings (the configuration that exposed — and now regression-tests — a JIT'd ''FETCH_THIS'' unsoundness during development).
	+
	+	===== Open Issues =====
	+
	+	- Should ''int'' methods apply to ''float'' receivers (numeric unification), or stay strictly type-keyed as proposed?
	+
	+	===== Unaffected PHP Functionality =====
	+
	+	All existing scalar behavior: casts, operators, string functions, array functions, ''null'' handling, and the nullsafe operator. Objects and the base RFC's semantics are untouched. Programs that never declare a scalar extension cannot observe this RFC.
	+
	+	===== Future Scope =====
	+
	+	* JIT compilation of scalar extension method bodies.
	+	* By-reference receiver variants (''function push($v): void'' mutating the caller's array) — deliberately excluded; value semantics are the safe default.
	+
	+	===== Voting Choices =====
	+
	+	Primary vote requiring a 2/3 majority (per the [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting-phase\|php/policies voting guidelines]]); void if the base Extension Methods RFC is declined:
	+
	+	> Allow extension methods on the built-in value types as outlined in the RFC? Yes / No
	+
	+	===== Patches and Tests =====
	+
	+	Implemented on the [[https://github.com/hollyschilling/php-src/tree/extension-methods-scalars\|extension-methods-scalars]] branch, stacked directly on the base RFC's ''extension-methods-phase1'' branch — [[https://github.com/hollyschilling/php-src/compare/extension-methods-phase1...extension-methods-scalars\|the diff between the two branches]] is exactly this proposal. Tests cover all five targets, literal/temporary/dynamic-name receivers, chained calls, value semantics, generators, namespaced scalar targets, and the first-class-callable restriction; the lexical-gating interaction ships with the visibility RFC's branch. Verified: full Zend suite green plain, under ''opcache.protect_memory=1'', and under tracing and function JIT with ''jit_hot_*=1''.
	+
	+	===== Implementation =====
	+
	+	After acceptance: link to the merged commit(s), PHP version, and documentation.
	+
	+	===== References =====
	+
	+	* Base RFC: [[rfc:extension_methods\|PHP RFC: Extension Methods]]
	+	* Companion: [[rfc:extension_method_visibility\|PHP RFC: Extension Method Visibility]]
	+	* nikic's ''scalar_objects'' extension (proof-of-concept prior art for scalar receivers): https://github.com/nikic/scalar_objects
	+	* Kotlin extension functions on primitives; C# extension methods on value types
	+
	+	===== Rejected Features =====
	+
	+	* Extending ''null'' — a method call on ''null'' is far more often a bug than a dispatch opportunity; nullsafe ''?->'' already expresses the intentional case.
	+	* By-reference receivers — would reintroduce every aliasing question value semantics avoids; see Future Scope.
	+
	+	===== Changelog =====
	+
	+	* 2.0 (2026-07-10): redesigned around the base RFC's declared receiver variable — the by-value-''$this'' binding model is rejected (see the base RFC's Rejected Features for the implementation experience). The engine footprint collapsed to a brief frame handoff: generators now work, ''get_called_class()'' is fully defined, and the ''static::''/generator bans disappeared. First-class callables of scalar methods remain deferred.
	+	* 1.0 (2026-07-09): initial draft, split from the base RFC after implementation showed a distinctly larger engine footprint; fully implemented and verified.

extension_methods - Changed Github link to link to PR and not Branch

thecodelorax (thecodelorax@undisclosed.example.com) — 2026-07-11T14:11:13+00:00

2026/07/11 14:18		current
Line 3:		Line 3:
	* Date: 2026-07-11		* Date: 2026-07-11
	* Author: Holly Schilling, holly.a.schilling@outlook.com		* Author: Holly Schilling, holly.a.schilling@outlook.com
-	* Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")	+	* Status: Draft
	* Implementation: https://github.com/php/php-src/pull/22635		* Implementation: https://github.com/php/php-src/pull/22635
	* Discussion thread: https://news-web.php.net/php.internals/131861		* Discussion thread: https://news-web.php.net/php.internals/131861

textcurve.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-10T14:08:53+00:00

1783692513	current

function-autoloading-five-oh - add strict_namespace and shadow-global prevalence research

pmjones (pmjones@undisclosed.example.com) — 2026-07-07T16:39:05+00:00

2026/07/07 16:39		current
Line 235:		Line 235:
	==== How common is the shadow-global case? ====		==== How common is the shadow-global case? ====

-	Having said all that, the shadow-global case is not common. I researched the top 1000 packages on Packagist (981 with analyzable source, roughly 161,000 files), tracking three things:	+	Having said all that, the shadow-global case is not common. I researched the top 1000 packages on Packagist, tracking three things:

	* unqualified calls to a builtin-named function inside a namespace;		* unqualified calls to a builtin-named function inside a namespace;

2026/07/02 17:14		current
Line 17:		Line 17:
	\| Jul 16 2026 \| Alpha 2 \|		\| Jul 16 2026 \| Alpha 2 \|
	\| Jul 30 2026 \| Alpha 3 \|		\| Jul 30 2026 \| Alpha 3 \|
-	\| Aug 13 2026 \| Feature freeze \|	+	\| Aug 11 2026 \| Soft feature freeze: all RFCs must have their voting concluded, and should have been merged. \|
	\| Aug 13 2026 \| Beta 1 \|		\| Aug 13 2026 \| Beta 1 \|
	\| Aug 27 2026 \| Beta 2 \|		\| Aug 27 2026 \| Beta 2 \|
	\| Sep 10 2026 \| Beta 3 \|		\| Sep 10 2026 \| Beta 3 \|
		+	\| Sep 22 2026 \| Hard feature freeze: features — whether requiring an RFC or not — must be merged only with approval from the RMs. \|
	\| Sep 24 2026 \| RC1 \|		\| Sep 24 2026 \| RC1 \|
	\| Oct 08 2026 \| RC2 \|		\| Oct 08 2026 \| RC2 \|

2026/07/14 14:00		current
Line 23:		Line 23:

	* ''zend_get_property_offset()'' gains a ''write_access'' flag. It is an ''always_inline'' function and every caller passes a constant, so the parameter folds away at compile time. The write, unset, and ''get_property_ptr_ptr'' handlers resolve with write access; read and isset resolve without.		* ''zend_get_property_offset()'' gains a ''write_access'' flag. It is an ''always_inline'' function and every caller passes a constant, so the parameter folds away at compile time. The write, unset, and ''get_property_ptr_ptr'' handlers resolve with write access; read and isset resolve without.
-	* Write-kind resolution performs the asymmetric set-visibility check at cache population. When the running scope lacks set access, the property still resolves exactly as today — the caller's state-dependent slow path keeps deciding between the visibility error and the ''__set'' fallback — but the runtime cache slot is left unpopulated (and its key invalidated).	+	* Write-kind resolution performs the asymmetric set-visibility check at cache population. When the running scope lacks set access, the property still resolves exactly as today — the caller's state-dependent slow path keeps deciding between the visibility error and the ''_''''_set'' fallback — but the runtime cache slot is left unpopulated (and its key invalidated).
	* This establishes the invariant: a populated ''ZEND_ASSIGN_OBJ'' cache slot proves set access. The cached direct-assignment fast path can therefore skip the per-write scope walk (a debug assertion enforces the invariant).		* This establishes the invariant: a populated ''ZEND_ASSIGN_OBJ'' cache slot proves set access. The cached direct-assignment fast path can therefore skip the per-write scope walk (a debug assertion enforces the invariant).
	* Because the optimizer's literal-compaction pass shares runtime cache slots among ''$this'' property opcodes with the same property name, ''ZEND_ASSIGN_OBJ'' receives its own slot-sharing pool: its cache misses populate exclusively through the set-checked write handler, so sharing among assignment oplines preserves the invariant. All other property opcodes keep the shared pool and their existing per-operation checks.		* Because the optimizer's literal-compaction pass shares runtime cache slots among ''$this'' property opcodes with the same property name, ''ZEND_ASSIGN_OBJ'' receives its own slot-sharing pool: its cache misses populate exclusively through the set-checked write handler, so sharing among assignment oplines preserves the invariant. All other property opcodes keep the shared pool and their existing per-operation checks.
Line 30:		Line 30:

	* ''readonly'' keeps its per-write logic. Its check depends on per-object state (initialized or not), which can never amortize into a per-call-site cache. This RFC does not target readonly and does not change its cost.		* ''readonly'' keeps its per-write logic. Its check depends on per-object state (initialized or not), which can never amortize into a per-call-site cache. This RFC does not target readonly and does not change its cost.
-	* ''__set'' fallback semantics are preserved structurally: the cached fast path only runs when the property slot holds a defined value; every unset-state write already takes the slow handler path, where the full state-dependent handling (error vs. magic fallback) is untouched.	+	* ''_''''_set'' fallback semantics are preserved structurally: the cached fast path only runs when the property slot holds a defined value; every unset-state write already takes the slow handler path, where the full state-dependent handling (error vs. magic fallback) is untouched.
-	* Denied writes stay on the slow path permanently (their call sites are never cached). Denied writes end in an exception or a ''__set'' call; their per-execution cost is irrelevant.	+	* Denied writes stay on the slow path permanently (their call sites are never cached). Denied writes end in an exception or a ''_''''_set'' call; their per-execution cost is irrelevant.
	* Reads are untouched. On a cache hit the read path never enters any changed code.		* Reads are untouched. On a cache hit the read path never enters any changed code.
	* Static properties, compound assignment (''+='', ''++''), writes through references, property-hook dispatch, and the JIT's helper paths keep their existing per-operation checks (see Future Scope).		* Static properties, compound assignment (''+='', ''++''), writes through references, property-hook dispatch, and the JIT's helper paths keep their existing per-operation checks (see Future Scope).
Line 65:		Line 65:
	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====

-	None. The change is behavior-neutral by construction and by test: the full test suite — including the asymmetric-visibility, readonly, and property-hooks suites — passes with zero expectation changes in plain, opcache (with ''protect_memory''), and tracing-JIT modes. Error messages, ''__set'' fallback behavior, Reflection results, and readonly semantics are identical.	+	None. The change is behavior-neutral by construction and by test: the full test suite — including the asymmetric-visibility, readonly, and property-hooks suites — passes with zero expectation changes in plain, opcache (with ''protect_memory''), and tracing-JIT modes. Error messages, ''_''''_set'' fallback behavior, Reflection results, and readonly semantics are identical.

-	One denial-of-caching detail is observable only as timing: call sites that are denied set access re-resolve on every execution instead of being cached. Such writes throw or fall back to ''__set'' in all cases, so this affects no successful code path.	+	One denial-of-caching detail is observable only as timing: call sites that are denied set access re-resolve on every execution instead of being cached. Such writes throw or fall back to ''_''''_set'' in all cases, so this affects no successful code path.

	===== RFC Impact =====		===== RFC Impact =====