PHP Wiki

pipe_assignment_operator

cdwhite3 (cdwhite3@undisclosed.example.com) — 2026-07-10T05:16:28+00:00

2026/07/10 05:00		current
Line 9:		Line 9:

	===== Introduction =====		===== Introduction =====
-	PHP 8.4 introduced the pipe operator (''\|>''), enabling functional-style transformation chains. A common pattern is piping a variable through transformations and assigning the result back to the same variable:	+	PHP 8.4 introduced the pipe operator (''\|>''), enabling functional-style transformation chains. A common pattern is piping a variable through transformations and assigning the result back to the same variable.
		+	This RFC proposes ''\|>='', a compound assignment form that eliminates the repetition, consistent with PHP's existing compound assignment operators (''+='' , ''.='', ''??='', etc.):

	<PHP>		<PHP>
-	$this->requestData = $this->requestData	+	// Before
-	\|> array_filter(...);	+	$this->requestData = array_filter($this->requestData);
		+	// or
		+	$this->requestData = $this->requestData \|> array_filter(...);

	$headers = $headers		$headers = $headers
Line 19:		Line 22:
	\|> (fn($h) => array_filter($h, fn($v) => $v !== ''))		\|> (fn($h) => array_filter($h, fn($v) => $v !== ''))
	\|> array_values(...);		\|> array_values(...);
-	</PHP>

-	This RFC proposes ''\|>='', a compound assignment form that eliminates the repetition, consistent with PHP's existing compound assignment operators (''+='' , ''.='', ''??='', etc.):	+	// After
-		+
-	<PHP>	+
	$this->requestData \|>= array_filter(...);		$this->requestData \|>= array_filter(...);

readonly_property_defaults - Improved un-/serialisation

nicksdot (nicksdot@undisclosed.example.com) — 2026-07-09T19:09:41+00:00

2026/07/09 11:57		current
Line 209:		Line 209:
	</PHP>		</PHP>

-	==== Interaction with serialisation ====	+	==== Interaction with serialisation ====

-	Serialisation follows existing readonly property behaviour. A readonly property with a default value is initialised, hence included in the serialisation. Unserialisation without <php>__unserialize()</php> continues to use native object hydration semantics and may restore a serialised value for such a property. If <php>__unserialize()</php> is used, assignments in that method honour readonly initialisation, like <php>ReflectionProperty::setValue()</php>, so the default value	+	A readonly property with a default value is initialised, hence included in serialised data. During unserialisation, the readonly property value may be restored from the serialised data. This applies both to native object hydration and to assignments via <php>__unserialize()</php>. After unserialisation completes the property is readonly again.
-	cannot be overwritten.	+

	<PHP>		<PHP>
Line 221:		Line 220:
	public readonly int $value = 1;		public readonly int $value = 1;
	}		}
		+
		+	var_dump(serialize(new Counter)); // string(34) "O:7:"Counter":1:{s:5:"value";i:1;}"

	var_dump(unserialize('O:7:"Counter":0:{}')->value); // int(1)		var_dump(unserialize('O:7:"Counter":0:{}')->value); // int(1)
	var_dump(unserialize('O:7:"Counter":1:{s:5:"value";i:2;}')->value); // int(2)		var_dump(unserialize('O:7:"Counter":1:{s:5:"value";i:2;}')->value); // int(2)

-	final class CounterWithUnserialize	+	?>
		+	</PHP>
		+
		+	<PHP>
		+	<?php
		+
		+	final class Counter
	{		{
-	public readonly int $value = 1;	+	public readonly int $value = 1;

-	public function __unserialize(array $data): void {	+	public function __unserialize(array $data): void {
-	$this->value = $data['value'];	+	foreach ($data as $key => $value) {
-	}	+	$this->{$key} = $value;
		+	}
		+	}
	}		}

-	unserialize('O:22:"CounterWithUnserialize":1:{s:5:"value";i:2;}');	+	var_dump(serialize(new Counter)); // string(34) "O:7:"Counter":1:{s:5:"value";i:1;}"
-	// Error: Cannot modify readonly property CounterWithUnserialize::$value	+
		+	var_dump(unserialize('O:7:"Counter":0:{}')->value); // int(1)
		+	var_dump(unserialize('O:7:"Counter":1:{s:5:"value";i:2;}')->value); // int(2)

	?>		?>
Line 351:		Line 362:
	* 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

ext-gd-2.4

pajoye (pajoye@undisclosed.example.com) — 2026-07-09T12:59:12+00:00

2026/07/09 11:04		current
Line 3:		Line 3:
	* Date: 2026-07-06		* Date: 2026-07-06
	* Author: pajoye@php.net		* Author: pajoye@php.net
-	* Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")	+	* Status: Draft
-	* Implementation: https://github.com/...	+	* Implementation: to be added once the sync PR is merged
-	* 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)	+	* Discussion thread: tbd
	* Voting thread: tbd		* Voting thread: tbd

deprecations_php_8_6 - Removed deprecation as per ML discussion

edorian (edorian@undisclosed.example.com) — 2026-07-09T11:21:54+00:00

2026/07/09 07:47		current
Line 5:		Line 5:
	* Jordi Kroon <jordikroon@php.net>		* Jordi Kroon <jordikroon@php.net>
	* Weilin Du <weilindu@php.net>		* Weilin Du <weilindu@php.net>
-	* Volker Dusch <edorian@php.net>
	* Tim Düsterhus <timwolla@php.net>		* Tim Düsterhus <timwolla@php.net>
	* Osama Aldemeery <aldemeery@gmail.com>		* Osama Aldemeery <aldemeery@gmail.com>
Line 173:		Line 172:
	</doodle>		</doodle>

-	==== Deprecate changing by-reference return modifier via inheritance ====
-
-	* Author: Volker Dusch <edorian@php.net>
-
-	PHP currently permits a child class to override an inherited method while flipping its return-by-reference modifier, changing a fundamental aspect of the method's calling convention.
-
-	<PHP>
-	class A {
-	public function get() { /* by value */ }
-	}
-	class B extends A {
-	public function &get() { /* by reference */ }
-	}
-	</PHP>
-
-	A caller holding an <php>A</php> cannot tell, without reflection, whether the result of <php>$obj->get()</php> could be reference. Given the issues with by-reference semantics and <php>foreach</php> this is an issue, and a LSP violation.
-
-	This proposal deprecates declaring an overriding method whose return-by-reference modifier differs from the parent's. Interfaces and abstract methods are covered by the same rule.
-
-	If accepted, such a declaration will emit a deprecation notice at the point the child class is declared:
-
-	<blockquote>
-	Deprecated: Declaration of B::&get() should match A::get() (return-by-reference modifier differs)
-	</blockquote>
-
-	<doodle title="Deprecate changing by-reference return modifier via inheritance?" voteType="single" closed="true" closeon="2026-01-01T15:30:00Z">
-	* Yes
-	* No
-	* Abstain
-	</doodle>

	==== Deprecate using certain names as identifiers to reserve them as keywords ====		==== Deprecate using certain names as identifiers to reserve them as keywords ====

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;

third_party_ext_documentation

jordikroon (jordikroon@undisclosed.example.com) — 2026-07-06T07:34:43+00:00

2026/07/04 09:31		current
Line 207:		Line 207:

	Primary Vote requiring a 2/3 majority to accept the RFC:		Primary Vote requiring a 2/3 majority to accept the RFC:
-	<doodle title="Move third-party extension documentation out of the official PHP manual?" voteType="single" closed="false" closeon="2026-07-03T18:00:00Z">	+	<doodle title="Move third-party extension documentation out of the official PHP manual?" voteType="single" closed="true" closeon="2026-07-03T18:00:00Z">
	* Yes		* Yes
	* No		* No
Line 214:		Line 214:

	Secondary Vote (simple majority, only counted if primary passes). If there's a tie, this will default to "contrib.php.net (subdomain)":		Secondary Vote (simple majority, only counted if primary passes). If there's a tie, this will default to "contrib.php.net (subdomain)":
-	<doodle title="Where should third-party documentation be hosted?" voteType="single" closed="false" closeon="2026-07-03T18:00:00Z">	+	<doodle title="Where should third-party documentation be hosted?" voteType="single" closed="true" closeon="2026-07-03T18:00:00Z">
	* contrib.php.net (subdomain)		* contrib.php.net (subdomain)
	* www.php.net/manual/extensions/ (subpath)		* www.php.net/manual/extensions/ (subpath)
Line 221:		Line 221:

	Secondary Vote (simple majority, only counted if primary passes). If there's a tie, this will default to "Remove notes":		Secondary Vote (simple majority, only counted if primary passes). If there's a tie, this will default to "Remove notes":
-	<doodle title="How should existing user notes be handled during migration?" voteType="single" closed="false" closeon="2026-07-03T18:00:00Z">	+	<doodle title="How should existing user notes be handled during migration?" voteType="single" closed="true" closeon="2026-07-03T18:00:00Z">
	* Remove notes		* Remove notes
	* Migrate notes to the new location		* Migrate notes to the new location

gradient_art.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:32:24+00:00

	current

tiger.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:32:03+00:00

	current

gradient_operators.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:31:36+00:00

	current

grapheme_mask - add pr link

sepehrphp (sepehrphp@undisclosed.example.com) — 2026-07-05T13:24:51+00:00

2026/07/01 19:17		current
Line 7:		Line 7:
	* First Published at: http://wiki.php.net/rfc/grapheme_mask		* First Published at: http://wiki.php.net/rfc/grapheme_mask
	* Discussion: https://news-web.php.net/php.internals/130522		* Discussion: https://news-web.php.net/php.internals/130522
		+	* pr link:https://github.com/php/php-src/pull/22605
	===== Introduction =====		===== Introduction =====
	In modern web applications, handling Personally Identifiable Information (PII) securely is a critical requirement. Developers frequently need to obfuscate or mask sensitive data such as phone numbers, email addresses, national IDs, or partial credit card numbers before logging them or displaying them to users (e.g., to comply with privacy regulations).		In modern web applications, handling Personally Identifiable Information (PII) securely is a critical requirement. Developers frequently need to obfuscate or mask sensitive data such as phone numbers, email addresses, national IDs, or partial credit card numbers before logging them or displaying them to users (e.g., to comply with privacy regulations).

rfc - Added "Readonly Property Defaults" to "Under Discussion"

nicksdot (nicksdot@undisclosed.example.com) — 2026-07-05T02:34:32+00:00

2026/07/10 04:00		current
Line 19:		Line 19:
	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:pipe_assignment_operator\|Pipe Assignment Operator]] (created 2026-07-09, Discussion started 2026-07-09)
	* [[rfc:readonly_property_defaults\|Readonly Property Defaults]] (Created 2026-07-04, Discussion started 2026-07-04)		* [[rfc:readonly_property_defaults\|Readonly Property Defaults]] (Created 2026-07-04, Discussion started 2026-07-04)
	* [[rfc:grapheme_mask\|Grapheme Mask]] (Created 2026-06-25)		* [[rfc:grapheme_mask\|Grapheme Mask]] (Created 2026-06-25)
Line 76:		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:pipe_assignment_operator\|Pipe Assignment Operator]] (created 2026-07-09)
	* [[rfc:reflectionattribute-getcurrent\|Add ReflectionAttribute::getCurrent()]] (created 2026-04-19, discussion started 2026-05-04)		* [[rfc:reflectionattribute-getcurrent\|Add ReflectionAttribute::getCurrent()]] (created 2026-04-19, discussion started 2026-05-04)
	* [[rfc:deprecated_interfaces\|#[\Deprecated] for interfaces]] (created 2026-05-10)		* [[rfc:deprecated_interfaces\|#[\Deprecated] for interfaces]] (created 2026-05-10)

working_groups

ramsey (ramsey@undisclosed.example.com) — 2026-07-04T16:39:38+00:00

2026/07/04 16:13		current
Line 10:		Line 10:
	For over 30 years, the PHP Project has thrived through the individual efforts of its contributors, and the RFC process has proven effective for making technical changes to the language. The operational side has not received the same attention: infrastructure management, website maintenance, contributor onboarding, and community outreach, among others. These efforts rely on informal arrangements with no clear ownership, no defined membership, and no standard way for new volunteers to get involved.		For over 30 years, the PHP Project has thrived through the individual efforts of its contributors, and the RFC process has proven effective for making technical changes to the language. The operational side has not received the same attention: infrastructure management, website maintenance, contributor onboarding, and community outreach, among others. These efforts rely on informal arrangements with no clear ownership, no defined membership, and no standard way for new volunteers to get involved.

-	This RFC proposes a Working Groups policy that establishes a framework for creating, operating, and dissolving working groups within the PHP Project. Each working group would be chartered through the PHP RFC process, with a defined purpose, duration, membership process, and communication plan. An approved charter grants the group authority to operate autonomously within its scope, while the RFC process remains required for language and policy changes.	+	This RFC proposes a Working Groups policy that establishes a framework for creating, operating, and dissolving working groups within the PHP Project. Each working group is chartered through the PHP RFC process, with a defined purpose, duration, membership process, and communication plan. An approved charter grants the group authority to operate autonomously within its scope, while the RFC process remains required for language and policy changes.

	===== Working Groups Policy =====		===== Working Groups Policy =====

serializable_closures

nicolasgrekas (nicolasgrekas@undisclosed.example.com) — 2026-07-04T08:42:10+00:00

2026/07/01 08:34		current
Line 1:		Line 1:
	====== PHP RFC: Serializable closures, by reference to the code that declares them ======		====== PHP RFC: Serializable closures, by reference to the code that declares them ======

-	* Version: 0.1	+	* Version: 0.2
	* Date: 2026-06-10		* Date: 2026-06-10
	* Author: Nicolas Grekas <nicolasgrekas@php.net>		* Author: Nicolas Grekas <nicolasgrekas@php.net>
-	* Status: Draft	+	* Status: Under Discussion
	* First Published at: https://wiki.php.net/rfc/serializable_closures		* First Published at: https://wiki.php.net/rfc/serializable_closures
	* Mailing List Thread: https://news-web.php.net/php.internals/131198		* Mailing List Thread: https://news-web.php.net/php.internals/131198
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, a	+	The payload is a reference to the declaration site, made of the declaring class name, an
-	**stable id, and the start line** of the closure (used as a staleness check):	+	**element-scoped id, and the start line** of the closure (used as a staleness check):

	<code php>		<code php>
Line 110:		Line 110:

	$payload = serialize($closure);		$payload = serialize($closure);
-	// O:7:"Closure":3:{s:5:"class";s:5:"Order";s:2:"id";i:0;s:4:"line";i:3;}	+	// O:7:"Closure":3:{s:5:"class";s:5:"Order";s:2:"id";s:17:"$billingAddress@0";s:4:"line";i:3;}

	$again = unserialize($payload);		$again = unserialize($payload);
Line 122:		Line 122:
	<php>ReflectionAttribute::getArguments()</php> return two instances today.		<php>ReflectionAttribute::getArguments()</php> return two instances today.

-	The id is deterministic. It is the closure's rank among all closure-declaring constant	+	The id is element-scoped and deterministic. It is an opaque ''"<site>@<rank>"'' string:
-	expressions of the class (anonymous declarations and first-class callable references alike),	+	''<site>'' names the declaring reflection element (the empty string for the class itself, a
-	counted in a fixed declaration-order traversal of the class (class attributes first, then	+	constant or enum-case name, ''$prop'' for a property, ''$prop::get()'' / ''$prop::set()'' for a
-	constants, properties and hooks, then methods with their parameter lists). It is derived from	+	property hook, ''name()'' for a method, with a method's parameters folded into the method), and
-	the compiled class alone, never from runtime state, evaluation order or caches, which is where	+	''<rank>'' is the closure's position among the closures of //that one element//, counted in a
-	its stability comes from: every process running the same source computes the same rank, with or	+	fixed declaration-order traversal (attributes first, then parameter default values, nesting
-	without opcache. The flip side is that editing the class may renumber the ranks. References are	+	depth-first). It is derived from the compiled class alone, never from runtime state, evaluation
-	therefore validated when they resolve (see below) and must be treated like the cache artifacts	+	order or caches: every process running the same source computes the same id, with or without
-	they are embedded in: valid for the code revision that produced them, and per PHP version.	+	opcache. Because each element is numbered independently, adding, removing or reordering a closure
-	Userland should obtain ids from the engine (see the Reflection API below) rather than compute	+	in one element does not renumber the closures of any other element, and resolution locates the one
-	them.	+	named element instead of scanning the whole class. Editing the //declaring// element can still
		+	shift its ranks; references are therefore validated when they resolve (see below) and must be
		+	treated like the cache artifacts they are embedded in: valid for the code revision that produced
		+	them, and per PHP version. Userland should obtain ids from the engine (see the Reflection API
		+	below) rather than compute them, but the grammar is deliberately reproducible so that userland
		+	polyfills on PHP 8.5 can mint and resolve the same references (see the Rationale).
		+
		+	First-class callable references share the same ''"<site>@<key>"'' grammar with a different key:
		+	the callable's name instead of a rank (next section).

	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 142:		Line 150:
	A first-class callable in a constant expression is a closure declaration site like any other:		A first-class callable in a constant expression is a closure declaration site like any other:
	the class's source declares, at a fixed position, "a closure over this callable". Closures		the class's source declares, at a fixed position, "a closure over this callable". Closures
-	created by evaluating such a reference serialize with the same payload as anonymous	+	created by evaluating such a reference serialize with the same ''{class, id}'' payload shape as
-	declarations: the declaring class, the id, the start line. The engine tracks this provenance	+	anonymous declarations, with one difference: the key after ''@'' is not a rank but the
-	when it evaluates the constant expression; an identical-looking closure created at runtime does	+	name of the referenced callable, in PHP's callable-string syntax, so these references carry
-	not have it and refuses to serialize.	+	no positional component at all. The
		+	class part of the key is the late static binding scope, which is what distinguishes the
		+	''self::'' and ''parent::'' forms. There is no line field either: a name cannot drift silently,
		+	so no tripwire is needed. The engine tracks the provenance when it evaluates the constant
		+	expression; an identical-looking closure created at runtime does not have it and refuses to
		+	serialize.

	<code php>		<code php>
Line 158:		Line 171:
	$closure = /* from ReflectionAttribute::getArguments() */;		$closure = /* from ReflectionAttribute::getArguments() */;
	serialize($closure);		serialize($closure);
-	// O:7:"Closure":3:{s:5:"class";s:5:"Order";s:2:"id";i:0;s:4:"line";i:3;}	+	// O:7:"Closure":2:{s:5:"class";s:5:"Order";s:2:"id";s:31:"$billingAddress@Order::isStrict";}
	</code>		</code>

-	Resolution re-evaluates the declared reference in the scope of the declaring class, exactly like	+	Resolution locates the named element, checks that it declares a first-class callable reference
-	attribute evaluation does. Two important properties follow:	+	matching the key, and evaluates //that declaration// in the scope of the declaring class,
		+	exactly like attribute evaluation does. The name is the address; the declaration is the guard:
		+	''"$billingAddress@system"'' does not resolve, because that property declares no such
		+	reference. Two important properties follow:

	* Any visibility works, because the site's own access rules are simply re-run: a private or protected helper referenced from an attribute of its own class (as above, an idiomatic pattern since validation helpers have no reason to be public) round-trips fine, while a forged payload gains nothing: it can only designate references that the class legitimately declares.		* Any visibility works, because the site's own access rules are simply re-run: a private or protected helper referenced from an attribute of its own class (as above, an idiomatic pattern since validation helpers have no reason to be public) round-trips fine, while a forged payload gains nothing: it can only designate references that the class legitimately declares.
-	* Late static binding is preserved: ''self::'', ''parent::'' and explicit class names resolve exactly as they did when the attribute was evaluated, since it is the same evaluation.	+	* Late static binding is preserved, and the key makes it visible: ''self::isStrict(%%...%%)'' declared by ''Order'' yields ''@Order::isStrict'' while a ''parent::'' reference yields the parent class in the key, and each resolves exactly as the attribute evaluation did.
		+
		+	Because the key is a name, these references are insensitive to every edit except removing the
		+	reference itself, renaming its target, or renaming the declaring element, and each of those
		+	fails loudly, by name. Several references to the same callable are indistinguishable by
		+	construction (the callable string fully determines the closure), so no ordinal is ever needed;
		+	when several elements of a class declare the same callable, equivalent closures re-serialize to
		+	the first declaring element in declaration order, a normalization with no observable effect
		+	since the closures are identical.

-	This works uniformly for functions (''strlen(%%...%%)''), own methods (''self::isStrict(%%...%%)''),	+	This works uniformly for functions (''strlen(%%...%%)'', keyed as ''"$p@strlen"''), own methods
-	and cross-class references (''Validators::check(%%...%%)''), in attribute arguments and parameter	+	(''self::isStrict(%%...%%)''), and cross-class references (''Validators::check(%%...%%)''), in
-	default values alike.	+	attribute arguments and parameter default values alike.

	==== What stays non-serializable ====		==== What stays non-serializable ====
Line 193:		Line 217:
	==== Security model ====		==== Security model ====

-	The payload contains a class name and two integers, never code. Resolution can only ever	+	The payload contains a class name, a site id and, for anonymous closures, a line number:**
-	produce a closure that the named class's own source declares in one of its constant	+	never code**. Resolution can only ever produce a closure that the named class's own source
-	expressions: there is nothing else a payload can express. ''unserialize()'' is not a closure	+	declares in one of its constant expressions: there is nothing else a payload can express.
-	factory over the code base; it is a lookup into the fixed, finite set of closures that classes	+	''unserialize()'' is not a closure factory over the code base; it is a lookup into the fixed,
-	declare about themselves.	+	finite set of closures that classes declare about themselves.

-	A forged payload can therefore at worst point at a //different// declared closure, the same	+	Unserializing a closure is inert: unlike objects, whose deserialization hooks and destructors
-	class of risk as unserializing an enum case name or a class name today, and far less than what	+	run, nothing executes when the closure is created. But inertness is not the property that
-	''unserialize()'' already allows through ''%%__wakeup()%%'' gadgets. Visibility needs no special	+	matters here, because the very purpose of the target use cases is to unserialize a closure and
-	rule: resolving a first-class callable site re-runs the same accessibility checks, in the same	+	then //call// it. Once it is called, everything reduces to which callables a payload can name.
-	scope, that attribute evaluation runs, so a reference resolves for the reader exactly when the	+	Bounded to declared references, a forged payload can at worst swap one closure a class declares
-	declaration is legal for the declarer. And the existing	+	for another, the same class of risk as unserializing an enum case name today, and far less than
		+	what ''unserialize()'' already allows through ''%%__wakeup()%%'' gadgets. Unbounded name-based
		+	resolution would instead make a payload naming ''system'' a universal call gadget shipped in
		+	the engine: no application-specific gadget chain required, effective against any application
		+	that unserializes untrusted data and later invokes the result. Keeping the resolution bounded is
		+	the same defense-in-depth stance that added ''allowed_classes'' even though ''unserialize()''
		+	is documented as unsafe on untrusted input.
		+
		+	Visibility needs no special rule: resolving a first-class callable site re-runs the same
		+	accessibility checks, in the same scope, that attribute evaluation runs, so a reference resolves
		+	for the reader exactly when the declaration is legal for the declarer. And the existing
	''allowed_classes'' hardening applies unchanged: with		''allowed_classes'' hardening applies unchanged: with
	''unserialize($data, ['allowed_classes' => [...]])'' not listing <php>Closure</php>, these		''unserialize($data, ['allowed_classes' => [...]])'' not listing <php>Closure</php>, these
Line 214:		Line 248:

	<code>		<code>
-	Invalid serialization data for Closure object (constant-expression closure 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@Order::isStrict" of class Order not found)
	Invalid serialization data for Closure object (cannot load class "Order")		Invalid serialization data for Closure object (cannot load class "Order")
	</code>		</code>
Line 223:		Line 258:
	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(): ?int</php> returns the declaration-site id 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>"'') 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, int $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. It throws an <php>Error</php> if the class cannot be loaded and a <php>ValueError</php> if the id does not resolve.

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

Line 271:		Line 306:
	dropped for three reasons:		dropped for three reasons:

-	* Needless surface. The motivating problem is cached metadata derived from constant expressions. Making every named closure serializable turns ''unserialize()'' into a closure factory over every function and public static method of the code base, a much larger capability than the problem requires. With declaration-site references only, a payload can designate nothing beyond the finite set of closures that classes declare about themselves.	+	* Needless surface. The motivating problem is cached metadata derived from constant expressions. Making every named closure serializable turns ''unserialize()'' into a closure factory over every function and public static method of the code base, a much larger capability than the problem requires; the security model above details why the bounded set is the property that matters once the closure gets called. With declaration-site references only, a payload can designate nothing beyond the finite set of closures that classes declare about themselves.
	* A visibility dilemma it cannot solve. Name-based payloads cross trust domains, so they must be restricted to what unscoped code could create: public static methods. But attributes legitimately reference //private// helpers of their own class (''#[When(self::isStrict(%%...%%))]'', where there is no reason to make the helper public), and those would have stayed unserializable, re-creating the very cache trap this RFC exists to fix. Site references dissolve the dilemma: resolution re-evaluates the declaration in its own scope, so visibility is enforced by the same rule that allowed the attribute to compile and evaluate in the first place.		* A visibility dilemma it cannot solve. Name-based payloads cross trust domains, so they must be restricted to what unscoped code could create: public static methods. But attributes legitimately reference //private// helpers of their own class (''#[When(self::isStrict(%%...%%))]'', where there is no reason to make the helper public), and those would have stayed unserializable, re-creating the very cache trap this RFC exists to fix. Site references dissolve the dilemma: resolution re-evaluates the declaration in its own scope, so visibility is enforced by the same rule that allowed the attribute to compile and evaluate in the first place.
-	* One principle, one payload. Anonymous declarations and callable references get the same format, the same staleness contract, and the same security analysis, instead of two payload kinds with different rules.	+	* One reference model. Both forms share the ''{class, "<site>@<key>"}'' payload, the element-scoped resolution and the same security analysis. They differ only in the key, which is where each form's best identity lives: the callable's name for first-class callables (so those references carry no ordinal at all), a rank for anonymous closures, which have no name to offer.

	The engine tracks the necessary provenance at no observable cost: closures created while		The engine tracks the necessary provenance at no observable cost: closures created while
Line 303:		Line 338:
	==== Why this id, and not another addressing scheme ====		==== Why this id, and not another addressing scheme ====

-	Two natural alternatives were considered for the id.	+	The id names the declaring element and a key within that element: the closure's rank
		+	for anonymous declarations, the referenced callable's name for first-class callables. Scoping
		+	the key to the element has three properties:

-	**A compiler-assigned index stored in the class. Instead of deriving the rank when a reference**	+	* Resolution is local. Resolution looks up the named element and walks only that element, so it is constant-time in the size of that one element and insensitive to how large the rest of the class is: on a class with sixty closure-declaring methods, resolving the last closure costs the same as resolving the first. Serialization is a non-evaluating traversal of the compiled class.
-	is created or resolved, the compiler would number each constant-expression closure while	+	* Unrelated edits do not renumber it. Because each element is numbered independently, adding, removing or reordering a closure in one element leaves every other element's ranks unchanged; only an edit to the //declaring// element can shift its own ranks, which the staleness tripwire (below) catches. Name-keyed references get the full benefit and keep resolving as long as their element and target survive; rank-keyed references additionally carry the line tripwire, which deliberately fails them closed on layout changes (see below).
-	compiling the class and store the table in the compiled artifact. The observable contract would	+	* One reference model across engine and userland. Frameworks need this feature on PHP 8.5, where there is no engine support and userland reproduces it by reflection. The ''"<site>@<rank>"'' string is self-describing: userland computes it from reflection and resolves it by walking the named element, with no engine call, producing references byte-identical to the engine's, so a value serialized on 8.5 by a polyfill and one serialized on 8.6 by the engine are interchangeable. This was verified across the engine, the ''ext-deepclone'' extension and a pure-PHP polyfill.
-	be identical: a stored index is renumbered by source edits in exactly the same situations as the	+
-	derived rank, so it is neither more nor less stable, and the staleness tripwire is needed either	+
-	way. The difference is economics: a stored table costs memory in every compiled class (including	+
-	in opcache shared memory) and new persistence plumbing, while deriving the rank costs a class	+
-	traversal per closure serialized or resolved, negligible next to unserialization itself. The	+
-	proposal therefore specifies the contract (deterministic per source revision and PHP version) and	+
-	derives the id; switching to a stored index later would be invisible to userland. A stored index	+
-	does have one distinctive power, noted under Future Scope: by keeping the compiled closures of	+
-	class constant values and property defaults reachable after their initializers are evaluated, it	+
-	could lift the in-place-evaluation exclusion without changing how those initializers are	+
-	evaluated.	+

-	The rank among attribute arguments of any type, not only closures. Numbering every argument	+	The site grammar folds a method's parameters into the method (''name()'') rather than addressing
-	slot looks simpler but addresses the wrong unit. One argument may declare several closures (an	+	each parameter, so the engine needs no parameter-index bookkeeping for default values, and the
-	array of callbacks is a single argument), so a within-argument ordinal is still needed; parameter	+	whole reference stays a class name, a short string and, for anonymous closures, a line.
-	default values are not attribute arguments, so a second numbering domain appears; and the id	+
-	becomes //less// stable, since adding or removing any scalar argument before the closure renumbers	+
-	it, while the closure-only rank is invariant to every edit that does not add, remove or reorder	+
-	closures themselves. Counting only closures numbers exactly the things being referenced, with the	+
-	smallest possible sensitivity to unrelated edits.	+

-	A fully symbolic variant ("argument ''callback'' of the second attribute of property ''$x''")	+	Two alternative addressing schemes were considered.
-	reads better in payloads but combines the drawbacks: paths must reach into nested arrays and	+
-	chained closures, attribute and parameter-default sites need different address shapes, an ordinal	+	A flat per-class rank, numbering all of a class's constant-expression closures in one
-	is still required when one argument declares several closures, and the robustness it buys	+	sequence, yields a marginally smaller id (a single integer) but gives up each property above:
-	(references surviving edits to //other// members of the class) is not actually desirable for cache	+	resolution scans the class to the target, an edit anywhere renumbers every closure after it, and
-	artifacts, where failing closed on any change to the file is the expected behavior. The flat	+	userland cannot reconstruct the rank the engine assigns without evaluating every preceding site,
-	closure rank plus the line tripwire provides the same safety with a two-integer payload.	+	nor resolve one at all without the engine. The compactness is not worth those costs for
		+	references whose purpose is to survive in caches and be reproducible off-engine.
		+
		+	A compiler-assigned index stored in the class was also considered. Instead of deriving the id
		+	when a reference is created or resolved, the compiler would number each constant-expression
		+	closure while compiling the class and store the table in the compiled artifact. The observable
		+	contract would be identical, and it is renumbered by source edits in the same situations, so the
		+	staleness tripwire is needed either way. The difference is economics: a stored table costs memory
		+	in every compiled class (including in opcache shared memory) and new persistence plumbing, while
		+	deriving the id costs one element traversal per closure serialized or resolved, negligible next to
		+	unserialization itself. The proposal therefore specifies the contract (deterministic per source
		+	revision and PHP version) and derives the id; switching to a stored index later would be invisible
		+	to userland. A stored index does have one distinctive power, noted under Future Scope: by keeping
		+	the compiled closures of class constant values and property defaults reachable after their
		+	initializers are evaluated, it could lift the in-place-evaluation exclusion without changing how
		+	those initializers are evaluated.

	==== Why the line number, and why not a stronger fingerprint ====		==== Why the line number, and why not a stronger fingerprint ====

-	Because the id is positional, an edit to the class can make a stored id designate a //different	+	This section applies to anonymous closures only: first-class callable references are keyed by
-	declaration site// than the one that was serialized: removing an attribute renumbers every closure	+	name, cannot drift silently, and carry no line field.
-	after it. That is the one failure that must not be silent. Storing the closure's start line makes	+
		+	Because the rank of an anonymous reference is positional within its element, an edit to that
		+	element can make a stored id designate a //different declaration site// than the one that was
		+	serialized: removing an earlier attribute renumbers every closure after it in the same element.
		+	That is the one failure that must not be silent. Storing the closure's start line makes
	essentially every renumbering edit fail loudly: for a stale id to resolve silently, the site		essentially every renumbering edit fail loudly: for a stale id to resolve silently, the site
	that now occupies it would have to sit on the very line recorded in the payload.		that now occupies it would have to sit on the very line recorded in the payload.
Line 348:		Line 388:
	know their start line, and so do the nodes of constant expressions), resolution never touches		know their start line, and so do the nodes of constant expressions), resolution never touches
	the filesystem, and it means the same thing in every PHP build.		the filesystem, and it means the same thing in every PHP build.
		+
		+	The line also over-rejects: an edit that merely shifts lines above the closure invalidates
		+	payloads whose rank would still resolve correctly. For anonymous references this trade is
		+	intentional. They are cache artifacts; a rejection is a self-healing miss; and the
		+	''serialize()''-based metadata caches that motivate this RFC do not track file freshness
		+	themselves (they are keyed by class name and cleared on deploy), so the payload is the only
		+	place a freshness fuse can live. References that need to outlive deploys use the name-keyed
		+	form, which carries no line.

	Stronger checks were considered, and each pins the wrong thing:		Stronger checks were considered, and each pins the wrong thing:
Line 361:		Line 409:
	payloads already require today (a payload is only valid for the code revision that produced it),		payloads already require today (a payload is only valid for the code revision that produced it),
	and frameworks invalidate their metadata caches on file changes anyway.		and frameworks invalidate their metadata caches on file changes anyway.
		+
		+	==== Version migration, and why references are cache artifacts ====
		+
		+	Object serialization normally lets a class own its format and migrate old payloads inside an
		+	unserialization hook, e.g. to keep serialized queue jobs working across deploys. That model
		+	cannot transfer here: <php>Closure</php> is final and engine-owned, so there is no user hook,
		+	and an anonymous closure has no name anyone could stabilize a format around. This proposal
		+	therefore does not present anonymous references as durable tokens: they are **cache
		+	artifacts**, valid for the code revision that produced them, like the serialized metadata they
		+	travel in.
		+
		+	Deploy-durable references require the developer to //name// the closure, and this proposal
		+	already supports the construct for that: a static method, referenced first-class
		+	(''#[When(self::isStrict(%%...%%))]'' instead of an inline body). Such a reference is keyed by
		+	the method's name, is stable under every edit that keeps the declaring element and the named
		+	method in place, and tracks the method's current body by design, which is exactly what a
		+	payload that outlives deploys should do.
		+
		+	==== Why a single RFC ====
		+
		+	The 8.5 work shipped closures and first-class callables in constant expressions as two
		+	separate RFCs. This proposal keeps the two forms together because here they are one feature:
		+	they share the payload shape, the element-scoped resolution, the provenance tracking and the
		+	security analysis, and the callable half alone would not fix the anonymous case that motivates
		+	the RFC. Should a blocking objection specific to one half emerge, carving it out before the
		+	vote remains possible.

	==== Naming ====		==== Naming ====
Line 408:		Line 482:
	* Global constants and free-function attributes: addressable in principle (by constant/function name), but functions and constants are not autoloadable, which weakens the resolution story. Could be added incrementally.		* Global constants and free-function attributes: addressable in principle (by constant/function name), but functions and constants are not autoloadable, which weakens the resolution story. Could be added incrementally.
	* Name-based serialization of runtime-created named closures: making ''serialize(strlen(%%...%%))'' work anywhere by serializing closures over public named callables as their name. This is a pure widening of this proposal, discussed and deliberately left out in the Rationale; the two payload kinds can coexist if a need emerges.		* Name-based serialization of runtime-created named closures: making ''serialize(strlen(%%...%%))'' work anywhere by serializing closures over public named callables as their name. This is a pure widening of this proposal, discussed and deliberately left out in the Rationale; the two payload kinds can coexist if a need emerges.
-	* Native ''var_export()'' support: emitting ''\Closure::fromConstExpr(...)'' / ''\Foo::bar(%%...%%)'' from ''var_export()'' itself, instead of leaving it to userland exporters.	+	* Native ''var_export()'' support: emitting ''\Closure::fromConstExpr(...)'' / ''\Foo::bar(%%...%%)'' from ''var_export()'' itself, instead of leaving it to userland exporters. The first-class callable part of this needs no RFC and can land independently as a regular improvement.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====
Line 427:		Line 501:

	* Round-trips from every attribute target (class, constant, enum case, property, hook, method, parameter), parameter defaults, nested and runtime-nested declarations		* Round-trips from every attribute target (class, constant, enum case, property, hook, method, parameter), parameter defaults, nested and runtime-nested declarations
-	* First-class callable sites: functions (incl. namespaced), own private/protected methods, inherited methods via ''self::'' and ''parent::'' (with their distinct ''static::'' bindings), cross-class references	+	* First-class callable sites, with name-keyed ids: functions (incl. namespaced), own private/protected methods, inherited methods via ''self::'' and ''parent::'' (with their distinct ''static::'' bindings and keys), cross-class references, cross-element normalization of duplicate references
	* Runtime-created named closures keep refusing, even when an identical reference exists in an attribute		* Runtime-created named closures keep refusing, even when an identical reference exists in an attribute
	* Inheritance and traits		* Inheritance and traits
	* Scope restoration: ''self::'', private member access		* Scope restoration: ''self::'', private member access
	* Refusals: every row of the "stays non-serializable" table, with unchanged error message		* Refusals: every row of the "stays non-serializable" table, with unchanged error message
-	* Forged and stale payloads: unknown class/id, line mismatch, type confusion, name-shaped payloads, double initialization	+	* Forged and stale payloads: unknown class/id, line mismatch, type confusion, undeclared callable keys (e.g. ''"$p@system"''), double initialization
	* ''allowed_classes'' gating (''%%__PHP_Incomplete_Class%%'', no resolution)		* ''allowed_classes'' gating (''%%__PHP_Incomplete_Class%%'', no resolution)
	* Object-graph behavior: shared instances, ''%%__wakeup()%%'' ordering		* Object-graph behavior: shared instances, ''%%__wakeup()%%'' ordering
Line 444:		Line 518:
	* [[https://github.com/symfony/symfony/pull/61657\|symfony#61657: VarExporter support for named closures]]		* [[https://github.com/symfony/symfony/pull/61657\|symfony#61657: VarExporter support for named closures]]
	* [[https://github.com/opis/closure\|opis/closure]], [[https://github.com/laravel/serializable-closure\|laravel/serializable-closure]]: userland source-extraction serializers		* [[https://github.com/opis/closure\|opis/closure]], [[https://github.com/laravel/serializable-closure\|laravel/serializable-closure]]: userland source-extraction serializers
		+
		+	===== 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 line field) and normalize to their first declaring element. Expanded the security model (inert creation vs substitution on call); added the "Version migration" and "Why a single RFC" rationale sections.
		+	* 0.1: Initial draft.

override_constants - implementation merged

daniels (daniels@undisclosed.example.com) — 2026-07-03T20:04:18+00:00

2026/05/24 04:47		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: Pending implementation / landing	+	* Status: Implemented (in PHP 8.6)
	* 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

duration_class - Fix mistake proof-of-concept implementation.

timwolla (timwolla@undisclosed.example.com) — 2026-07-03T15:51:54+00:00

2026/07/03 14:54		current
Line 312:		Line 312:
	* @strict-properties		* @strict-properties
	*/		*/
-	final class Duration	+	final readonly class Duration
	{		{
	private function __construct(		private function __construct(
Line 633:		Line 633:
	===== Changelog =====		===== Changelog =====

		+	* 2026-07-03: Fix mistake proof-of-concept implementation.
	* 2026-07-03: Add secondary vote for naming of the mathematical operations.		* 2026-07-03: Add secondary vote for naming of the mathematical operations.
	* 2026-06-23: Clarify that every overflow will throw TimeException.		* 2026-06-23: Clarify that every overflow will throw TimeException.

php86 - Add alpha1

sergey (sergey@undisclosed.example.com) — 2026-07-02T17:14:57+00:00

2026/04/15 18:20		current
Line 14:		Line 14:

	^ Date ^ Release ^		^ Date ^ Release ^
-	\| Jul 02 2026 \| Alpha 1 \|	+	\| Jul 02 2026 \| Alpha 1 [[https://www.php.net/archive/2026.php#2026-07-02-3\|Announce]] [[https://downloads.php.net/~mbeccati/\|Files]] \|
	\| Jul 16 2026 \| Alpha 2 \|		\| Jul 16 2026 \| Alpha 2 \|
	\| Jul 30 2026 \| Alpha 3 \|		\| Jul 30 2026 \| Alpha 3 \|

min_supported_versions_php_8_6 - add Tim as a co-author and clarify impact

enorris (enorris@undisclosed.example.com) — 2026-07-02T15:47:50+00:00

2026/07/02 15:07		current
Line 1:		Line 1:
	====== PHP RFC: Minimum supported versions for PHP 8.6 ======		====== PHP RFC: Minimum supported versions for PHP 8.6 ======
-	* Version: 1.0	+	* Version: 1.1
	* Date: 2026-07-02		* Date: 2026-07-02
-	* Author: Eric Norris, erictnorris@gmail.com	+	* Author: Eric Norris, erictnorris@gmail.com; Tim Düsterhus, timwolla@php.net
	* Status: Under Discussion		* Status: Under Discussion
	* Thread: https://news-web.php.net/php.internals/131707		* Thread: https://news-web.php.net/php.internals/131707
Line 30:		Line 30:
	MariaDB 10.2.4 was released on February 17th, 2017 and reached its end-of-life alongside all 10.2 minor versions on [[https://endoflife.date/mariadb\|May 23rd, 2022]].		MariaDB 10.2.4 was released on February 17th, 2017 and reached its end-of-life alongside all 10.2 minor versions on [[https://endoflife.date/mariadb\|May 23rd, 2022]].

-	This RFC proposes that we use ''COM_RESET_CONNECTION'' in PDO and ''mysqlnd'' when reusing persistent connections. Users that are on MySQL or MariaDB databases from before this feature was implemented //may upgrade to PHP 8.6, but would not be able to use persistent connections//. This means that their software could continue to work, but they might lose a performance optimization.	+	This RFC proposes that we use ''COM_RESET_CONNECTION'' in PDO and ''mysqlnd'' when reusing persistent connections. Users that are on MySQL or MariaDB databases from before this feature was implemented may upgrade to PHP 8.6, //but would not be able to use persistent connections//. This means that their software could continue to work, but they might lose a performance optimization.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
Line 40:		Line 40:
	==== To the Ecosystem ====		==== To the Ecosystem ====

-	None expected.	+	* Users that want to use the newest PHP version will be required to also run newer versions (released in the last 5 years) of other software.
		+	* For COM_RESET_CONNECTION, persistent connections to MySQL databases will now be safe to use as they will be reset to a pristine state. On the other hand, if existing users inadvertently rely on connection state carrying over across requests, they may see a breaking change.

	==== To Existing Extensions ====		==== To Existing Extensions ====
Line 47:		Line 48:

	==== To SAPIs ====		==== To SAPIs ====
		+
		+	None.

	===== Open Issues =====		===== Open Issues =====

		+	None.

	===== Future Scope =====		===== Future Scope =====

		+	None.

	===== Voting Choices =====		===== Voting Choices =====
Line 78:		Line 83:

	===== Implementation =====		===== Implementation =====
		+
		+	N/A

	===== References =====		===== References =====
		+
		+	* Discussion thread https://news-web.php.net/php.internals/131707
		+	* Pre-discussion thread https://news-web.php.net/php.internals/130704

	===== Rejected Features =====		===== Rejected Features =====
		+
		+	None.

	===== Changelog =====		===== Changelog =====
		+
		+	* 2026-07-02: Initial version.
		+	* 2026-07-02: Add Tim as a co-author and clarify impact.

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