PHP Wiki - rfc

2d_matrix_operations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: 2D Matrix Operations ======
	+	* Version: 1
	+	* Date: 2023-01-23
	+	* Author: Thomas Hruska, cubic@php.net
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/2d_matrix_operations
	+
	+	===== Introduction =====
	+	PHP has traditionally been weak in the area of mathematics and math operations beyond what the baseline C library supplies. With the growth of machine learning (ML), PHP is extremely inadequate as a language of choice. [[https://en.wikipedia.org/wiki/Matrix_(mathematics)\|Matrix operations from linear algebra]] are the basis of ML and many other areas of scientific computing. This RFC aims to add mat_add(), mat_sub(), and mat_mult() native functions to PHP for matrix addition, subtraction, and multiplication respectively.
	+
	+	Matrix multiplication, in particular, is a natural O(N^3) algorithm. Implementing even a simple matrix multiplication operation in PHP userland has less than desirable outcomes. The mat_mult() native function is up to 46 times faster than the best PHP userland implementation (See Benchmark).
	+
	+	Further, NumPy is one of the major reasons that people gravitate towards Python in academic settings over PHP. NumPy has been used to make several major scientific discoveries and advancements. Implementation of this RFC will begin to move the needle in the direction of PHP and thus keep PHP a more relevant choice for scientific computing tasks.
	+
	+	===== Proposal =====
	+	A number of new global macros, inline global functions in Zend engine, and three new functions for PHP: mat_add(), mat_sub(), and mat_mult().
	+
	+	Working implementations of the functions being proposed can be found at:
	+
	+	[[https://github.com/cubiclesoft/php-ext-qolfuncs]]
	+
	+	==== Global Macros and Inline Functions ====
	+	Before getting to the three matrix operation functions, we need to first expand upon the existing set of macros available to PHP core and extension devs. PHP does not appear to currently offer a way to iterate over two distinct arrays at the exact same time in a manner similar to ZEND_HASH_FOREACH(). ZEND_HASH_FOREACH(), the most popular, safe, and performant way to access an array, can only iterate over one array at a time.
	+
	+	Side note: PHP 8.2 introduced major changes to the fundamental HashTable structure such that it accepts either packed zvals or Buckets - most likely for performance reasons. This affects the design of the relevant macros and inline functions.
	+
	+	The list of macros and inline functions that need to be added to zend_hash.h or zend_types.h is far too long to put into this RFC, but can be seen here:
	+
	+	[[https://github.com/cubiclesoft/php-ext-qolfuncs/blob/master/qolfuncs.c#L1436]]
	+
	+	The macros normalize access to nNumUsed, Bucket values, and the first, next, previous, last, and end element positions. There are also two inline functions (zend_hash_get_next_zval() and zend_hash_get_prev_zval()) to safely normalize access to the next and previous zval via an opaque iterator.
	+
	+	==== mat_add() ====
	+
	+	%%array mat_add(array $a, array $b)%%
	+
	+	Adds the values of two 2D matrices.
	+
	+	* $a - A 2D array.
	+	* $b - A 2D array.
	+
	+	Returns: A 2D array with the values of each corresponding cell added together.
	+
	+	This function performs a matrix addition operation on two matrices and returns the result. It also exercises a number of new macros designed to iterate over HashTable structures.
	+
	+	Target audience: Users working with matrices.
	+
	+	Why it should be added to PHP: Performant matrix addition from linear algebra.
	+
	+	==== mat_sub() ====
	+
	+	%%array mat_sub(array $a, array $b)%%
	+
	+	Subtracts the values of two 2D matrices.
	+
	+	* $a - A 2D array.
	+	* $b - A 2D array.
	+
	+	Returns: A 2D array with the values of each corresponding cell subtracted together.
	+
	+	This function performs a matrix subtraction operation on two matrices and returns the result. Basically a copy of mat_add() but for subtraction.
	+
	+	Target audience: Users working with matrices.
	+
	+	Why it should be added to PHP: Performant matrix subtraction from linear algebra.
	+
	+	==== mat_mult() ====
	+
	+	%%mat_mult(array $a, array\|float\|int $b, [int $row = null])%%
	+
	+	Multiplies the values of two 2D matrices or the values of a 2D matrix or row of the matrix with a scalar value.
	+
	+	* $a - A 2D array.
	+	* $b - A 2D array or a numeric scalar value.
	+	* $row - An integer specifying the number of the row to multiply the scalar value on (Default is null).
	+
	+	Returns: A 2D array with the resulting values of the multiplication operation.
	+
	+	This function performs a matrix multiplication operation on one or two matrices and returns the result. When using a scalar value, it can affect just one row with the $row parameter.
	+
	+	Matrix multiplication of two matrices from linear algebra is a traditionally O(N^3) algorithm. This function is max_execution_time aware to avoid consuming CPU resources beyond the execution time limit on all supported platforms.
	+
	+	Target audience: Users working with matrices.
	+
	+	Why it should be added to PHP: Performant matrix multiplication operations from linear algebra.
	+
	+	=== mat_mult() Benchmark ===
	+
	+	The best (see Notes below) PHP userland implementation of matrix multiplication is:
	+
	+	<code php>
	+	// Makes a number of assumptions about the inputs for this function.
	+	function mat_mult_matrixonly_userland($a, $b)
	+	{
	+	$c = array();
	+
	+	$arows = count($a);
	+	$acols = count($b);
	+	$bcols = count($b[0]);
	+
	+	for ($i = 0; $i < $arows; $i++)
	+	{
	+	$tmpa = $a[$i][0];
	+	$b2 = &$b[0];
	+
	+	$c[$i] = array();
	+	$c2 = &$c[$i];
	+
	+	for ($j = 0; $j < $bcols; $j++)
	+	{
	+	$c2[$j] = $tmpa * $b2[$j];
	+	}
	+
	+	for ($k = 1; $k < $acols; $k++)
	+	{
	+	$tmpa = $a[$i][$k];
	+	$b2 = &$b[$k];
	+
	+	for ($j = 0; $j < $bcols; $j++)
	+	{
	+	$c2[$j] += $tmpa * $b2[$j];
	+	}
	+	}
	+	}
	+
	+	return $c;
	+	}
	+	</code>
	+
	+	<code>
	+	C:\php-sdk\phpdev\vs16\x64\php-8.2.1
	+	$ x64\Release_TS\php.exe test.php
	+	Creating arrays...
	+	1375x1966 * 1966x1375
	+	mat_mult_matrixonly_userland(): 85.441348075867 sec
	+	mat_mult(): 1.8196060657501 sec
	+	</code>
	+
	+	mat_mult() is up to 46 times faster than the best userland implementation. The execution time appears to be on par with NumPy on similar hardware.
	+
	+	Notes: The userland implementation is one I came up with based on [[https://github.com/cubiclesoft/matrix-multiply\|extensive testing]] and [[https://board.phpbuilder.com/d/10403480-converting-matlab-machine-learning-routines-to-php-need-matrix-operations/50\|observation/estimates from measurements of PHP ML libraries]]. Some PHP ML userland libraries take up to 10 minutes to perform the above matrix multiplication operation making 1.5 minutes seem perfectly reasonable until we realize that it's still exceptionally slow. The above userland implementation utilizes a deep understanding of PHP internals + a deep understanding of the best matrix multiply algorithms. Matrix multiplication is a rabbit hole we probably should not wander down too far. The desire to obsessively optimize O(N^3) is very strong. The native implementation of mat_mult() in PHP should be simple, work, and notably improve performance over userland (above) but not necessarily be the absolutely fastest solution nor require another external library or specialized hardware (e.g. CBLAS, cuBLAS).
	+
	+	===== Backward Incompatible Changes =====
	+	Significant care was taken to not introduce any BC breaks. As such, there shouldn't be any BC breaks as a result of these additions and enhancements.
	+
	+	mat_add(), mat_sub(), and mat_mult() will no longer be available as global function names. May break existing userland software that defines global functions with these names. Searching GitHub for those three function names turns up the following results:
	+
	+	* mat_add() - 7 results. One global function in a repository called "php-noob." No apparent naming conflicts.
	+	* mat_sub() - 14 results. One global function naming conflict in [[https://github.com/arun-thomas-abraham/EvCoord/blob/f860fd5a5ff2f42d9d5cb15d409bcaf652d36bf4/matrix%5B1%5D.php\|this repo]].
	+	* mat_mult() - 1 result. Just the test extension (qolfuncs). No apparent naming conflicts.
	+
	+	===== Proposed PHP Version(s) =====
	+	Next PHP 8.x.
	+
	+	===== RFC Impact =====
	+
	+	* To Zend: New macros and inline functions added to zend_hash.h/zend_types.h.
	+	* To SAPIs: Will be applied to all PHP environments.
	+	* To Existing Extensions: Additions and changes made to ext/standard in the existing .c and .h files.
	+	* To Opcache: None.
	+	* New Constants: No new constants introduced.
	+	* php.ini Defaults: No changes to php.ini introduced.
	+
	+	===== Open Issues =====
	+	Issue 1 - From G. P. B. "We already have a couple of issues supporting them that we probably should address those first, namely that multiplication is assumed to be commutative, something which is not true for matrices (see https://github.com/php/php-src/pull/9218) Hoping I get back to argue about the former, it would make it possible to use objects and the fact extensions can overload operators to make dealing with matrices easier. This is IMHO a better approach than using multidimensional arrays. [redacted comment about 2x2 matrices]" I think this was a drive-by observation based on the test suite, which, at the time, only showed 2x2 matrices. Needs more analysis/clarification before proceeding.
	+
	+	Issue 2 - It's possible that I missed macros/inline functions that already exist in Zend and would work equally well. PHP has a ton of macros and ways of accomplishing something that it is easy to miss already implemented/working solutions. Someone with more knowledge of the existing macros should take a look.
	+
	+	Issue 3 - The names for the macros/inline functions for zend_hash.h/zend_types.h should be evaluated for naming consistency.
	+
	+	Issue 4 - Decide where the new macros/inline functions should live: zend_hash.h, zend_types.h, or split up between both.
	+
	+	Issue 5 - Are there any additional features missing from these three functions that should be added now before they are adopted? I wrote these functions based on Wikipedia articles, what I remember from a linear algebra class, and a very long, meandering forum thread. As a result, they may not line up with how users expect to use the functions.
	+
	+	===== Future Scope =====
	+	Perhaps other performance oriented features from NumPy or ML libraries will be deemed important to include such as Fast Fourier Transforms (FFTs). IMO, everything through mid-level calculus and linear algebra should be accessible in the core of any language, especially if there are major performance benefits for doing so. FFTs would therefore be out of scope and better relegated to a PECL extension.
	+
	+	===== Proposed Voting Choices =====
	+	The vote will require 2/3 majority with a vote on a per-function basis.
	+
	+	Any function passing the vote also includes the prerequisite global macros and inline Zend functions to enable the new functionality.
	+
	+	===== Patches and Tests =====
	+	Working implementations of all the items being proposed can currently be found at:
	+
	+	[[https://github.com/cubiclesoft/php-ext-qolfuncs]]
	+
	+	This section will be updated to point to relevant pull request(s). Most of the development and testing is basically done at this point, so turning the extension into a normal pull request should be reasonably straightforward.
	+
	+	===== Implementation =====
	+	After the project is implemented, this section should contain
	+	- the version(s) it was merged into
	+	- a link to the git commit(s)
	+	- a link to the PHP manual entry for the feature
	+	- a link to the language specification section (if any)
	+
	+	===== References =====
	+
	+	* External forum post(s): [[https://board.phpbuilder.com/d/10403480-converting-matlab-machine-learning-routines-to-php-need-matrix-operations/]]
	+	* Results for 18 different ANSI C/C++ matrix multiply algorithms: [[https://github.com/cubiclesoft/matrix-multiply]]
	+	* Implementation PR: TODO
	+	* Discussions on the php.internals mailing list: https://externals.io/message/119238
	+	* Announcement thread: TODO
	+
	+	===== Rejected Features =====
	+	None at this time.

64bit-integer-type

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/05/06 18:34		current
Line 53:		Line 53:

	The type cast have a "long" name alias too: (integer64)		The type cast have a "long" name alias too: (integer64)
		+
		+	==== Functions ====
		+
		+	New function(s) should be inserted into the core
		+	* is_int64 (Or maybe the is_int function should me modified)

	===== Internals =====		===== Internals =====

abolish-narrow-margins

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/02/08 09:04		current
Line 3:		Line 3:
	* Date: 2016-11-17		* Date: 2016-11-17
	* Author: krakjoe		* Author: krakjoe
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/abolish-narrow-margins		* First Published at: http://wiki.php.net/rfc/abolish-narrow-margins

Line 49:		Line 49:
	A straight yes/no vote, 2/3 super majority required to pass.		A straight yes/no vote, 2/3 super majority required to pass.

-	<doodle title="Adopt the changes in this proposal?" auth="krakjoe" voteType="single" closed="false">	+	<doodle title="Adopt the changes in this proposal?" auth="krakjoe" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

abolish-short-votes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/04/05 19:05		current
Line 3:		Line 3:
	* Date: 2019-03-21		* Date: 2019-03-21
	* Author: krakjoe		* Author: krakjoe
-	* Status: Voting	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/abolish-short-votes		* First Published at: http://wiki.php.net/rfc/abolish-short-votes

Line 38:		Line 38:
	Voting started 5th April 2019, finishes 19th April 2019.		Voting started 5th April 2019, finishes 19th April 2019.

-	<doodle title="Adopt the changes in this (abolish short votes) proposal?" auth="krakjoe" voteType="single" closed="false">	+	<doodle title="Adopt the changes in this (abolish short votes) proposal?" auth="krakjoe" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

abstract_final_class

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/12/23 00:05		current
Line 3:		Line 3:
	* Date: 2014-11-26		* Date: 2014-11-26
	* Author: Guilherme Blanco, guilhermeblanco@php.net		* Author: Guilherme Blanco, guilhermeblanco@php.net
-	* Status: Withdrawn	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/abstract_final_class		* First Published at: http://wiki.php.net/rfc/abstract_final_class

abstract_syntax_tree

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/08/27 18:08		current
Line 95:		Line 95:

	==== Changes to list() ====		==== Changes to list() ====
		+
		+	> Note: The behavior of ''list($a, $b) = $a'' described below no longer applies. After this RFC was accepted ''list()'' assignments that contain the same variable on the left- and right-hand side have been special cased to ensure the right-hand side always evaluates first. This means that ''list($a, $b) = $a'' continues working as expected.

	''list()'' currently assigns variables right-to-left, the AST implementation will assign them left-to-right instead:		''list()'' currently assigns variables right-to-left, the AST implementation will assign them left-to-right instead:
Line 147:		Line 149:

	==== Auto-vivification order for by-reference assignments ====		==== Auto-vivification order for by-reference assignments ====
		+
		+	> Note: The auto-vivification order for reference assignments has been restored to the old behavior in PHP 7.1. The reason for this is that we found hard to avoid memory safety issues with the new order.

	While by-reference assignments are (CVs notwithstanding) evaluated left-to-right, auto-vivification currently occurs right-to-left. In the AST implementation this will happen left-to-right instead:		While by-reference assignments are (CVs notwithstanding) evaluated left-to-right, auto-vivification currently occurs right-to-left. In the AST implementation this will happen left-to-right instead:

abstract_trait_method_validation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/03/23 14:06		current
Line 2:		Line 2:
	* Date: 2020-02-07		* Date: 2020-02-07
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.0		* Target Version: PHP 8.0
	* Implementation: https://github.com/php/php-src/pull/5068		* Implementation: https://github.com/php/php-src/pull/5068

access_scope_from_magic_accessors

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/05/09 16:28		current
Line 3:		Line 3:
	* Date: 2023-01-19		* Date: 2023-01-19
	* Author: Nicolas Grekas <nicolasgrekas@php.net>, Ilija Tovilo <tovilo.ilija@gmail.com>		* Author: Nicolas Grekas <nicolasgrekas@php.net>, Ilija Tovilo <tovilo.ilija@gmail.com>
-	* Status: Draft	+	* Status: Withdrawn
	* First Published at: https://wiki.php.net/rfc/access_scope_from_magic_accessors		* First Published at: https://wiki.php.net/rfc/access_scope_from_magic_accessors
	* Implementation: https://github.com/php/php-src/compare/master...iluuu1994:php-src:magic-method-get-calling-scope		* Implementation: https://github.com/php/php-src/compare/master...iluuu1994:php-src:magic-method-get-calling-scope

add_bcdivmod_to_bcmath

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/08/05 02:15		current
Line 3:		Line 3:
	* Date: 2024-06-30		* Date: 2024-06-30
	* Author: Saki Takamachi (saki@php.net)		* Author: Saki Takamachi (saki@php.net)
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/add_bcdivmod_to_bcmath		* First Published at: https://wiki.php.net/rfc/add_bcdivmod_to_bcmath

add_str_begin_and_end_functions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/07/09 01:19		current
Line 3:		Line 3:
	* Date: 2016-08-01 (use today's date here) Updated: 2019-06-18		* Date: 2016-08-01 (use today's date here) Updated: 2019-06-18
	* Author: Will Hudgins, will@wkhudgins.info		* Author: Will Hudgins, will@wkhudgins.info
-	* Status: Voting	+	* Status: Declined
	* First Published at: https://wiki.php.net/rfc/add_str_begin_and_end_functions		* First Published at: https://wiki.php.net/rfc/add_str_begin_and_end_functions

Line 89:		Line 89:

	<doodle		<doodle
-	title="Do you want str_starts_with, str_starts_with_ci, str_ends_with, and str_ends_with_ci functions in PHP 7.4?" auth="user" voteType="single" closed="no">	+	title="Do you want str_starts_with, str_starts_with_ci, str_ends_with, and str_ends_with_ci functions in PHP 7.4?" auth="user" voteType="single" closed="yes">
	* yes		* yes
	* no		* no
Line 97:		Line 97:

	<doodle		<doodle
-	title="Do you want mb_str_starts_with, mb_str_starts_with_ci, mb_str_ends_with, and mb_str_ends_with_ci functions in PHP 7.4?" auth="user" voteType="single" closed="no">	+	title="Do you want mb_str_starts_with, mb_str_starts_with_ci, mb_str_ends_with, and mb_str_ends_with_ci functions in PHP 7.4?" auth="user" voteType="single" closed="yes">
	* yes		* yes
	* no		* no

add_str_starts_with_and_ends_with_functions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/05 11:47		current
Line 3:		Line 3:
	* Date: 2020-03-25 (Updated: 2020-05-05)		* Date: 2020-03-25 (Updated: 2020-05-05)
	* Author: Will Hudgins, will@wkhudgins.info		* Author: Will Hudgins, will@wkhudgins.info
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions		* First Published at: https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions

add_validate_functions_to_filter

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/08/31 20:28		current
Line 506:		Line 506:

	Please choose targeted version for this RFC		Please choose targeted version for this RFC
-	<doodle title="Target version" auth="yohgaki" voteType="single" closed="false">	+	<doodle title="Target version" auth="yohgaki" voteType="single" closed="true">
	* 7.1.0		* 7.1.0
	* 7.2.0		* 7.2.0

add_values_method_to_backed_enum

Anonymous (anonymous@undisclosed.example.com) — 2026-01-19T04:56:47+00:00

2026/01/18 12:09		current
Line 169:		Line 169:
	This is a Yes/No vote, requiring a 2/3 majority.		This is a Yes/No vote, requiring a 2/3 majority.

-	Voting started on Jan 18, 2026 and ends on Feb 08, 2026	+	Voting will start later
-		+
-	<doodle title="Add BackedEnum::values()?" voteType="single" closed="false" closeon="2026-02-08T00:00:00Z">	+
-	* Yes	+
-	* No	+
-	* Abstain	+
-	</doodle>	+

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

add-cms-support

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/13 19:45		current
Line 3:		Line 3:
	* Date: 2020-05-13		* Date: 2020-05-13
	* Author: Eliot Lear, lear@lear.ch		* Author: Eliot Lear, lear@lear.ch
-	* Status: In Discussion	+	* Status: Implemented (PHP 8.0)
	* First Published at: http://wiki.php.net/rfc/add-cms-support		* First Published at: http://wiki.php.net/rfc/add-cms-support

add-sha256-function

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/09/26 20:48		current
Line 33:		Line 33:
	===== Comparison with other languages =====		===== Comparison with other languages =====

-	* Python's [[https://docs.python.org/3/library/hashlib.html\|hashlib]] module provides named constructors for each supported algorithm; the minimum list is MD5, SHA-1, four variants of SHA-2 (''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()''), four variants of SHA-3, two of SHAKE, and two of BLAKE2. The SHA-3, SHAKE, and BLAKE2 algorithms were added in Python 3.6 (2016).	+	* Python's [[https://docs.python.org/3/library/hashlib.html\|hashlib]] module provides named constructors for each supported algorithm; the minimum list is MD5, SHA-1, four variants of SHA-2 (''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()''), four variants of SHA-3, two of SHAKE, and two of BLAKE2. The SHA-3, SHAKE, and BLAKE2 algorithms were added in Python 3.6 (2016).
-	* C# has [[https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.hashalgorithm?view=net-8.0\|classes derived from ''HashAlgorithm'']] for ''MD5'', ''SHA1'', ''SHA256', ''SHA384'', ''SHA512'', ''SHA3_256'', ''SHA3_384'', and ''SHA3_512''; separate classes (outside of that hierarchy) also exist for ''Shake128'' and ''Shake256''.	+	* C# has [[https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.hashalgorithm?view=net-8.0\|classes derived from ''HashAlgorithm'']] for ''MD5'', ''SHA1'', ''SHA256'', ''SHA384'', ''SHA512'', ''SHA3_256'', ''SHA3_384'', and ''SHA3_512''; separate classes (outside of that hierarchy) also exist for ''Shake128'' and ''Shake256''.
-	* Java provides only a universal constructor [[https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/security/MessageDigest.html\|''MessageDigest.getInstance(String algorithm)'']]. The minimum set of algorithms supported is SHA-1 and SHA-256.	+	* Java provides only a universal constructor [[https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/security/MessageDigest.html\|''MessageDigest.getInstance(String algorithm)'']]. The minimum set of algorithms supported is SHA-1 and SHA-256.
-	* Apple CryptoKit (for Swift applications) has [[https://developer.apple.com/documentation/cryptokit/hashfunction\|classes adopting the ''HashFunction'' protocol]] for ''SHA256'', ''SHA384'', and ''SHA512''.	+	* Apple CryptoKit (for Swift) has [[https://developer.apple.com/documentation/cryptokit/hashfunction\|classes adopting the ''HashFunction'' protocol]] for ''SHA256'', ''SHA384'', and ''SHA512''.
		+	* Ruby's [[https://docs.ruby-lang.org/en/3.3/Digest.html\|Digest module]] provides classes for MD5, RIPEMD-160, SHA1, and SHA2 (both via ''Digest::SHA2.new(bitlen)'' and short-hand ''Digest::SHA256'', ''Digest::SHA384'', and ''Digest::SHA512'').
		+	* Go's [[https://pkg.go.dev/crypto#pkg-functions\|standard-library ''crypto'' package]] includes classes for ''md5'', ''sha1'', ''sha256'' (which also implements SHA-224), and ''sha512'' (which also implements SHA-384, SHA-512/224 and SHA-512/256).
		+	* The Web Crypto API (for JavaScript) [[https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest\|has a single ''digest()'' method]] taking a string algorithm name; the only supported algorithms are 'SHA-1', 'SHA-256', 'SHA-384', and 'SHA-512'.
		+	* As far as I can see, Rust and Perl do not provide any digest functions in their standard libraries.

	Some databases also provide standalone functions for common hashing algorithms:		Some databases also provide standalone functions for common hashing algorithms:

-	* PostgreSQL offers built-in ''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()'' functions [[https://www.postgresql.org/docs/11/release-11.html#id-1.11.6.27.5.7\|since version 11.0]] (released in 2018). Prior versions offered only ''md5()'' outside of an optional extension, as [[https://www.postgresql.org/message-id/flat/7b5fca2d-1c5d-a991-fe5c-3851ad57017d%402ndquadrant.com\|discussed in the patch proposing them]].	+	* MySQL has functions for ''md5()'' and ''sha1()'', plus [[https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_sha2\|a combined ''sha2()'' function]] which takes an argument to select SHA-224, SHA-256, SHA-384, or SHA-512.
-	* MySQL has functions for ''md5()'' and ''sha1()'', plus [[https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_sha2\|a combined ''sha2()'' function]] which takes an argument to select SHA-224, SHA-256, SHA-384, or SHA-512.	+	* PostgreSQL offers built-in ''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()'' functions [[https://www.postgresql.org/docs/11/release-11.html#id-1.11.6.27.5.7\|since version 11.0]] (released in 2018). Prior versions offered only ''md5()'' outside of an optional extension, as [[https://www.postgresql.org/message-id/flat/7b5fca2d-1c5d-a991-fe5c-3851ad57017d%402ndquadrant.com\|discussed in the patch proposing them]].
-	* Presto and Trino (big data query engines used by tools like Amazon Athena) include [[https://trino.io/docs/current/functions/binary.html#hashing-functions\|nine hashing functions]] - like PHP these include ''crc32()'', ''md5()'' and ''sha1''; ''sha256()'' and ''sha512()'' variants of SHA-2, plus two variants of SpookyHashV2, one of xxHash, and one of Murmur3	+	* Microsoft SQL Server has only [[https://learn.microsoft.com/en-us/sql/t-sql/functions/hashbytes-transact-sql?view=sql-server-ver16\|a ''HASHBYTES'' function]], which takes an algorithm as a string, and accepts ''MD2'', ''MD4'', ''MD5'', ''SHA'', ''SHA1'', ''SHA2_256'', and ''SHA2_512'' (the algorithm older than SHA-2 log a deprecation notice)
		+	* Presto and Trino (big data query engines used by tools like Amazon Athena) include [[https://trino.io/docs/current/functions/binary.html#hashing-functions\|nine hashing functions]] - like PHP these include ''crc32()'', ''md5()'' and ''sha1''; ''sha256()'' and ''sha512()'' variants of SHA-2, plus two variants of SpookyHashV2, one of xxHash, and one of Murmur3

adding_bcround_bcfloor_bcceil_to_bcmath

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/11/30 08:21		current
Line 3:		Line 3:
	* Date: 2023-10-01		* Date: 2023-10-01
	* Author: Saki Takamachi, saki@sakiot.com		* Author: Saki Takamachi, saki@sakiot.com
-	* Status: Accepted	+	* Status: Implemented
		+	* Target Version: PHP 8.4
		+	* Implementation: https://github.com/php/php-src/pull/13096
	* First Published at: https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath		* First Published at: https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath

Line 109:		Line 111:

	===== Implementation =====		===== Implementation =====
-	Yet.	+
		+	https://github.com/php/php-src/pull/13096

	===== Rejected Features =====		===== Rejected Features =====

additional_soft_reservations_for_php7

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/07/03 22:08		current
Line 17:		Line 17:
	==== void ====		==== void ====

-	Where: As the last part of a class, interface or trait name.	+	Where: As the last segment of a class, interface or trait name. As such the names ''Void'' and ''Foo\Bar\Void'' are reserved, while ''Foo\Bar\MyVoid'' and ''Void\Foo\Bar'' are okay.

	Why: ''void'' is a likely candidate for the demarcation of void functions (which do not return a value). Alternatively ''null'' can be used for this purpose, which is already reserved. However both possibilities should be kept open until we reach a decision on this question.		Why: ''void'' is a likely candidate for the demarcation of void functions (which do not return a value). Alternatively ''null'' can be used for this purpose, which is already reserved. However both possibilities should be kept open until we reach a decision on this question.
Line 23:		Line 23:
	==== enum ====		==== enum ====

-	Where: In any context which is not protected by the [[https://wiki.php.net/rfc/context_sensitive_lexer\|context sensitivity RFC]]. This includes any part of class, interface, trait and function names.	+	Where: In any context which is not protected by the [[https://wiki.php.net/rfc/context_sensitive_lexer\|context sensitivity RFC]]. This includes any segment of class, interface, trait and function names.

	Why: There already is an [[https://wiki.php.net/rfc/enum\|enum RFC]] which will be proposed for PHP 7.x and requires this reserved keyword.		Why: There already is an [[https://wiki.php.net/rfc/enum\|enum RFC]] which will be proposed for PHP 7.x and requires this reserved keyword.

additional-context-in-pcntl-signal-handler

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/07/15 00:19		current
Line 3:		Line 3:
	* Date: 2016-06-14		* Date: 2016-06-14
	* Authors: David Walker <dave@mudsite.com>, Bishop Bettini <bishop@php.net>		* Authors: David Walker <dave@mudsite.com>, Bishop Bettini <bishop@php.net>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/additional-context-in-pcntl-signal-handler		* First Published at: http://wiki.php.net/rfc/additional-context-in-pcntl-signal-handler

additional-splat-usage

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/09 16:03		current
Line 3:		Line 3:
	* Date: 2014-11-03		* Date: 2014-11-03
	* Author: Chris Wright, daverandom@php.net, Marcelo Camargo, João Lucchetta		* Author: Chris Wright, daverandom@php.net, Marcelo Camargo, João Lucchetta
-	* Status: Inactive	+	* Status: Obsolete
	* First Published at: http://wiki.php.net/rfc/additional-splat-usage		* First Published at: http://wiki.php.net/rfc/additional-splat-usage
		+
		+	> This proposal has been superseded by [[rfc:spread_operator_for_array\|Spread Operator in Array Expression]], which has been implemented in PHP 7.4.

	===== Introduction =====		===== Introduction =====

adopt_pie_deprecate_pecl

Anonymous (anonymous@undisclosed.example.com) — 2025-09-22T06:17:34+00:00

2025/09/07 12:09		current
Line 3:		Line 3:
	* Date: 2025-08-20		* Date: 2025-08-20
	* Author: James Titcumb, asgrim@php.net		* Author: James Titcumb, asgrim@php.net
-	* Status: Voting	+	* Status: Accepted

	===== Introduction =====		===== Introduction =====
Line 32:		Line 32:
	Yes / No vote requiring 2/3 Yes votes to pass. Voting ends 2025-09-20T09:00:00Z.		Yes / No vote requiring 2/3 Yes votes to pass. Voting ends 2025-09-20T09:00:00Z.

-	<doodle title="Deprecate PECL and adopt PIE instead?" voteType="single" closed="false" closeon="2025-09-20T09:00:00Z">	+	<doodle title="Deprecate PECL and adopt PIE instead?" voteType="single" closed="true" closeon="2025-09-20T09:00:00Z">
	* Yes		* Yes
	* No		* No

adopt-code-of-conduct

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/01/20 18:44		current
Line 16:		Line 16:

	* A general "Code of Conduct", which provides a general overview on what constitutes as unacceptable behaviour		* A general "Code of Conduct", which provides a general overview on what constitutes as unacceptable behaviour
-	* A set of guidelines to foster collaboration on proposed language features through RFCs	+	* A set of guidelines to foster collaboration on proposed language features through RFCs [[guidelines]].
	* A set of procedures to follow if individuals wish to make complaints if other project members do not follow either the Code of Conduct or the Constructive Collaboration Guidelines.		* A set of procedures to follow if individuals wish to make complaints if other project members do not follow either the Code of Conduct or the Constructive Collaboration Guidelines.
	* A Contributor Mediation Team to asses and act upon the complaints as received through the above procedures		* A Contributor Mediation Team to asses and act upon the complaints as received through the above procedures

adts

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Algebraic Data Types ======
	+	* Version: 0.9
	+	* Date: 2020-10-04
	+	* Author: Larry Garfield (larry@garfieldtech.com), Ilija Tovilo (tovilo.ilija@gmail.com)
	+	* Status: Meta-RFC
	+	* First Published at: http://wiki.php.net/rfc/adts
	+
	+	===== Introduction =====
	+
	+	This is an over-arching description of a multi-step process to add Algebraic Data Types to PHP. That effort is happening over multiple implementation RFCs in order to keep them individually digestible. Algebraic Data Types are a valuable tool in data modeling, and in "making invalid states unrepresentable," an effective technique for avoiding many classes of bug.
	+
	+	===== Proposal =====
	+
	+	This proposal is implemented in stages. Each stage has its own RFC. Consult the list below for details of each. They are listed in approximately the order in which they can and should be implemented, although in some cases the order may be safely reversed.
	+
	+	* [[rfc:enumerations\|Enumerations]] - The basic unit enumeration type.
	+	* [[rfc:tagged_unions\|Tagged Unions]] - Associating values with enum cases to create tagged unions.
	+	* [[rfc:pattern-matching\|Pattern Matching ''is'' keyword]] - Pattern matching for objects, enumerations, and similar structures. Mainly to condense conditional logic around the structure of enumerations and value objects.
	+	* ''isIdentical()'' method override (future scope)
	+	* Advanced pattern matching (future scope)

aliases_by_reflection

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/12/15 19:30		current
Line 147:		Line 147:


-	<doodle title="Access to aliases definition by reflection" auth="milo" voteType="single" closed="false">	+	<doodle title="Access to aliases definition by reflection" auth="milo" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

allow_casting_closures_into_single-method_interface_implementations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/04/25 19:34		current
Line 168:		Line 168:

	In this example, an ''UriExpanderInterface'' is defined with an <php>expand()</php> method.		In this example, an ''UriExpanderInterface'' is defined with an <php>expand()</php> method.
-
	3 different implementations of the interface are derived using the <php>castTo()</php> method.		3 different implementations of the interface are derived using the <php>castTo()</php> method.
-
	Finally, the <php>getExpandedUrl()</php> function is defined, which accepts an implementation of		Finally, the <php>getExpandedUrl()</php> function is defined, which accepts an implementation of
	<php>UriExpanderInterface</php> and expands a URI template using the provided implementation.		<php>UriExpanderInterface</php> and expands a URI template using the provided implementation.

allow_int_args_to_bcmath_function

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/07/08 01:18		current
Line 35:		Line 35:
	function bcround(int\|string $num, int $precision = 0, int $mode = PHP_ROUND_HALF_UP): string {}		function bcround(int\|string $num, int $precision = 0, int $mode = PHP_ROUND_HALF_UP): string {}
	</PHP>		</PHP>
		+
		+	Note that even if the only numbers passed as arguments are ints, the return value will always be a string.

	I do not change anything for the following three functions. <php>bcscale()</php> is not a calculation function, so exclude it. <php>bcfloor()</php> and <php>bcceil()</php> are excluded because there is no point in allowing int type arguments due to the characteristics of their functions.		I do not change anything for the following three functions. <php>bcscale()</php> is not a calculation function, so exclude it. <php>bcfloor()</php> and <php>bcceil()</php> are excluded because there is no point in allowing int type arguments due to the characteristics of their functions.

allow_multiple_simultaneous_syslog_connections

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/07/05 13:36		current
Line 3:		Line 3:
	* Date: 2011-07-05		* Date: 2011-07-05
	* Author: Jérôme Loyet <fat@php.net>		* Author: Jérôme Loyet <fat@php.net>
-	* Status: Under Discussion	+	* Status: Dead as no one seem to be interested in
	* First Published at: https://wiki.php.net/rfc/syslog_enhancement		* First Published at: https://wiki.php.net/rfc/syslog_enhancement
	* Original discussion: http://marc.info/?l=php-internals&m=129639452805700&w=2		* Original discussion: http://marc.info/?l=php-internals&m=129639452805700&w=2
Line 100:		Line 100:
	* 2011/07/05 Draft		* 2011/07/05 Draft
	* 2011/07/05 first revision		* 2011/07/05 first revision
		+	* 2011/10/08 marked as dead

allow_null

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/02/20 20:19		current
Line 11:		Line 11:
	* GitHub Repo: https://github.com/craigfrancis/php-allow-null-rfc		* GitHub Repo: https://github.com/craigfrancis/php-allow-null-rfc
	* Implementation: ?		* Implementation: ?
		+
		+	----
		+
		+	This RFC has been superseded by [[https://wiki.php.net/rfc/null_coercion_consistency\|NULL Coercion Consistency]]
		+
		+	----

	===== Introduction =====		===== Introduction =====

allow_url_include

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/02/27 10:03		current
Line 15:		Line 15:
	Current allow_url_include behavior is wrong for 3 reasons.		Current allow_url_include behavior is wrong for 3 reasons.

-	- Implicit allowance of URL is problematic. It's "caller" responsibility to set this setting as intended. (Or "callee" must have API for overriding it to do the job)	+	- Implicit allowance of URL formed filename is problematic. It's "caller" responsibility to set this setting as intended. (Or "callee" must have API for overriding it to do the job)
	- It does not make "include/require" behave as INI setting name implies.		- It does not make "include/require" behave as INI setting name implies.
	- Being INI_SYSTEM increases risk of security filter bypass.		- Being INI_SYSTEM increases risk of security filter bypass.

allow-abstract-function-override

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/05/22 13:10		current
Line 4:		Line 4:
	* Date: 2017-03-01		* Date: 2017-03-01
	* Author: @WesNetmo @ Twitter		* Author: @WesNetmo @ Twitter
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* First Published at: https://wiki.php.net/rfc/allow-abstract-function-override		* First Published at: https://wiki.php.net/rfc/allow-abstract-function-override

allow-closures-to-declare-interfaces-they-implement

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/04/25 12:14		current
Line 55:		Line 55:
	</code>		</code>

-	Should be the equivalent to:	+	Should be equivalent to:
	<code php>		<code php>
	$f = new class() extends Closure implements FooInterface {		$f = new class() extends Closure implements FooInterface {

allow-constant-override-consistently

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/04/11 02:38		current
Line 20:		Line 20:
	interface B2 extends A2 { const X = 2; }		interface B2 extends A2 { const X = 2; }

-	// This doesn't work too:	+	// This doesn't work either:
	interface A3 { const X = 1; }		interface A3 { const X = 1; }
	class B3 implements A3 { const X = 2; }		class B3 implements A3 { const X = 2; }
Line 45:		Line 45:

	7.3		7.3
		+
		+	===== Future scope: =====
		+
		+	If desired by the community, the '''final''' keyword could be introduced in order to actually prevent constant override.

	===== Voting =====		===== Voting =====

allow-constant-override

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/03/30 22:29		current
Line 1:		Line 1:
-	====== PHP RFC: Allow abstract function override ======	+	wip
-		+
-	* Version: 0.1	+
-	* Date: 2017-03-01	+
-	* Author: @WesNetmo @ Twitter	+
-	* Status: Voting	+
-	* First Published at: https://wiki.php.net/rfc/allow-abstract-function-override	+
-		+
-	===== Proposal =====	+
-		+
-	PHP 7 introduced type declarations for return and improved ones for parameters. They currently support a very limited kind of variance (only to no-type):	+
-		+
-	<code php>	+
-	<?php	+
-	class A { function bar(stdClass $x){} }	+
-	class B extends A { function bar($x): stdClass{} }	+
-	</code>	+
-		+
-	However, this isn't currently matched by the equivalent abstract declarations:	+
-		+
-	<code php>	+
-	<?php	+
-	abstract class A { abstract function bar(stdClass $x); }	+
-	abstract class B extends A { abstract function bar($x): stdClass; }	+
-	class C extends B { function bar($x): stdClass{} }	+
-	// Fatal error: Can't inherit abstract function A::bar()	+
-	// (previously declared abstract in B)	+
-	</code>	+
-		+
-	This RFC proposes to allow this, even if it has very few uses, and because there is no reason to disallow a compatible redefinition.	+
-		+
-	Additionally, it comes in handy for documentation:	+
-		+
-	<code php>	+
-	interface A{	+
-	function doSomething();	+
-	}	+
-		+
-	interface B extends A{	+
-	function doSomethingElse();	+
-	}	+
-		+
-	abstract class AProxy implements A{	+
-	abstract protected function getOrigin(): A;	+
-	function doSomething(){	+
-	return $this->getOrigin()->doSomething();	+
-	}	+
-	}	+
-		+
-	// This phpdoc syntax has quirks in phpdocumentor	+
-	// apigen and phpstorm, and it's almost unmanageable	+
-	// as phpdoc interpreters have poor multiline support	+
-	// (imagine documenting all the parameters, the return	+
-	// type, all the throws...):	+
-	/ @method B getOrigin() /*	+
-	abstract class BProxy extends AProxy implements B{	+
-	/ @return B / // This is much better!*	+
-	abstract protected function getOrigin(): A;	+
-	function doSomethingElse(){	+
-	return $this->getOrigin()->doSomethingElse();	+
-	}	+
-	}	+
-	</code>	+
-		+
-	And, obviously, it will gain more uses when PHP will support a full-featured type variance.	+
-		+
-	===== Backward Incompatible Changes =====	+
-		+
-	None.	+
-		+
-	===== Proposed PHP Version(s) =====	+
-		+
-	7.2	+
-		+
-	===== Voting =====	+
-		+
-	2/3 majority required.	+
-		+
-	<doodle title="Accept abstract function override?" auth="WesNetmo" voteType="single">	+
-	* Yes	+
-	* No	+
-	</doodle>	+
-		+
-	===== Patches and Tests =====	+
-		+
-	N/A	+
-		+
-	===== References =====	+
-		+
-	[[https://externals.io/thread/735\|Discussion on externals.io]]	+

allow-stringable-string-param-strict-mode

Anonymous (anonymous@undisclosed.example.com) — 2026-01-26T08:27:48+00:00

2026/01/26 08:23		current
Line 51:		Line 51:

	===== Proposal =====		===== Proposal =====
-
-	==== PHP 8.6 ====

	Strict mode will accept <php>Stringable</php> objects for <php>string</php> parameters, converting them via <php>__toString()</php>:		Strict mode will accept <php>Stringable</php> objects for <php>string</php> parameters, converting them via <php>__toString()</php>:
Line 58:		Line 56:
	<PHP>		<PHP>
	<?php		<?php
		+
	declare(strict_types=1);		declare(strict_types=1);

Line 69:		Line 68:
	?>		?>
	</PHP>		</PHP>
-
-	This is a relaxation of strict mode restrictions. No deprecation is needed in PHP 8.6.

	===== Backward Compatibility Impact =====		===== Backward Compatibility Impact =====

allow-void-variance

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/02/04 06:39		current
Line 48:		Line 48:
	The ''method()'' can return anything, or nothing at all, but ''myFooConsumer'' just does not care about it.		The ''method()'' can return anything, or nothing at all, but ''myFooConsumer'' just does not care about it.

-	For this reason adding a type to ''void'' in subclasses is not an invalid operation, and denying it is a pointless restriction. Changing from ''void'' to something else is very probably a bad idea, but PHP should not enforce ''void'' in subclasses just on that basis.	+	For this reason adding a type to ''void'' in subclasses is not an invalid operation, and denying it is a pointless restriction. Changing from ''void'' to something else is probably a bad idea, but PHP should not enforce ''void'' in subclasses just on that basis.

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

alpanumeric_decrement

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/01/21 16:55		current
Line 4:		Line 4:
	* Date: 2013-12-16		* Date: 2013-12-16
	* Author: Andrea Faulds <ajf@ajf.me>		* Author: Andrea Faulds <ajf@ajf.me>
-	* Status: In voting phase	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/alphanumeric_decrement		* First Published at: http://wiki.php.net/rfc/alphanumeric_decrement

Line 92:		Line 92:
	Merge into PHP 5.6? (Will assume this requires 2/3 majority, due to new language feature)		Merge into PHP 5.6? (Will assume this requires 2/3 majority, due to new language feature)

-	<doodle title="Alphanumeric Decrement" auth="ajf" voteType="single" closed="false">	+	Voting started 2014-01-21 and ended 2014-01-28.
		+
		+	<doodle title="Alphanumeric Decrement" auth="ajf" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

alternative_callback_syntax

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2012-09-18		* Date: 2012-09-18
	* Author: Stephen Clay <steve@mrclay.org>		* Author: Stephen Clay <steve@mrclay.org>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: https://wiki.php.net/rfc/alternative_callback_syntax		* First Published at: https://wiki.php.net/rfc/alternative_callback_syntax

alternative-closure-use-syntax

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/06/15 21:57		current
Line 10:		Line 10:

	PHP users often say that they find defining the lexical-scope imports cumbersome, because		PHP users often say that they find defining the lexical-scope imports cumbersome, because
-	they hate writing the variables explicitly.	+	they hate importing the variables explicitly.

-	My (updated) opinion on the matter is that what's actually annoying is not having to write	+	My opinion on the matter is that what's actually annoying is not writing the variable
-	the variable names, but the syntax with which the imports are defined.	+	names, but the syntax with which the imports are defined.

-	In ES we are forced to declare variables and we don't find it annoying; in PHP we don't	+	In ES we are required to declare variables but we don't find it annoying; in PHP we don't
	have to declare variables, but we are required to specify which one we want to import in		have to declare variables, but we are required to specify which one we want to import in
	''Closure''s. It won't be much different if not for the syntax. It is very standard in ES,		''Closure''s. It won't be much different if not for the syntax. It is very standard in ES,

altmbstring

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/02/10 07:04		current
Line 3:		Line 3:
	* Date: 2014-02-05		* Date: 2014-02-05
	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net> Moriyoshi Koizumi <moriyoshi@php.net>		* Author: Yasuo Ohgaki <yohgaki@ohgaki.net> Moriyoshi Koizumi <moriyoshi@php.net>
-	* Status: Vote	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/altmbstring		* First Published at: http://wiki.php.net/rfc/altmbstring

Line 94:		Line 94:
	VOTE: 2014/02/10 - 2014/02/17		VOTE: 2014/02/10 - 2014/02/17

-	<doodle title="Include mbstring-ng for PHP-5.6 as EXPERIMENTAL module" auth="yohgaki" voteType="single" closed="false">	+	<doodle title="Include mbstring-ng for PHP-5.6 as EXPERIMENTAL module" auth="yohgaki" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

always_enable_json

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/27 12:59		current
Line 3:		Line 3:
	* Date: 2020-04-29		* Date: 2020-04-29
	* Author: Tyson Andre <tandre@php.net>		* Author: Tyson Andre <tandre@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target version: PHP 8.0		* Target version: PHP 8.0
	* Implementation: https://github.com/php/php-src/pull/5495		* Implementation: https://github.com/php/php-src/pull/5495

annotations_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/07/22 08:42		current
Line 3:		Line 3:
	* Date: 2019-02-05		* Date: 2019-02-05
	* Author: Michał Brzuchalski <michal.brzuchalski@gmail.com>		* Author: Michał Brzuchalski <michal.brzuchalski@gmail.com>
-	* Status: Withdrawn	+	* Status: Obsolete
	* First Published at: http://wiki.php.net/rfc/annotations_v2		* First Published at: http://wiki.php.net/rfc/annotations_v2

annotations-in-docblock

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/05/12 18:12		current
Line 4:		Line 4:
	* Date: 2011-05-11		* Date: 2011-05-11
	* Author: Guilherme Blanco <guilhermeblanco@hotmail.com>, Pierrick Charron <pierrick@php.net>		* Author: Guilherme Blanco <guilhermeblanco@hotmail.com>, Pierrick Charron <pierrick@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/annotations-in-docblock		* First Published at: http://wiki.php.net/rfc/annotations-in-docblock

annotations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/06/01 00:46		current
Line 18:		Line 18:
	* Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne, @Id, etc.		* Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne, @Id, etc.
	* Zend Framework Server classes Used to automate mappings for XML-RPC, SOAP, etc.		* Zend Framework Server classes Used to automate mappings for XML-RPC, SOAP, etc.
-	* **FLOW3** for dependency injection and validation	+	* **TYPO3** for dependency injection and validation
	* Symfony2 for routing rules		* Symfony2 for routing rules
	* Others One clear thing that comes to my mind is Validation, Functional Behavior injection (which could take advantage of [[rfc:Traits]]), etc. Also, any Framework could take advantage of it somehow.		* Others One clear thing that comes to my mind is Validation, Functional Behavior injection (which could take advantage of [[rfc:Traits]]), etc. Also, any Framework could take advantage of it somehow.

anonymous_catch

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 1:		Line 1:
-
	====== PHP RFC: Support for anonymous catches ======		====== PHP RFC: Support for anonymous catches ======
	* Version: 1.0		* Version: 1.0
	* Date: 2013-06-25		* Date: 2013-06-25
	* Author: Joost Koehoorn, joost.koehoorn@gmail.com		* Author: Joost Koehoorn, joost.koehoorn@gmail.com
-	* Status: Inactive	+	* Status: Obsolete
	* First Published at: http://wiki.php.net/rfc/anonymous_catch		* First Published at: http://wiki.php.net/rfc/anonymous_catch
		+
		+	> This proposal has been superseded by [[rfc:non-capturing_catches\|non-capturing catches]], which has been implemented in PHP 8.0.

	===== Introduction =====		===== Introduction =====

anonymous_classes_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/10/22 14:48		current
Line 8:		Line 8:
	===== Introduction =====		===== Introduction =====
	We have looked at anonymous classes before http://wiki.php.net/rfc/anonymous_classes		We have looked at anonymous classes before http://wiki.php.net/rfc/anonymous_classes
-
-	The patch is only a tiny bit different, moving constructor arguments to the position where most expect them.

	There has been many requests from the community to incorporate this feature, most recently here: http://grokbase.com/t/php/php-internals/146wpa11s5/revisiting-anonymous-classes from Sebastian Bergmann, author of PHPUnit.		There has been many requests from the community to incorporate this feature, most recently here: http://grokbase.com/t/php/php-internals/146wpa11s5/revisiting-anonymous-classes from Sebastian Bergmann, author of PHPUnit.

anonymous_classes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/28 17:10		current
Line 4:		Line 4:
	* Date: 2013-09-22		* Date: 2013-09-22
	* Author: Joe Watkins <krakjoe@php.net>, Phil Sturgeon <philstu@php.net>		* Author: Joe Watkins <krakjoe@php.net>, Phil Sturgeon <philstu@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/anonymous_classes		* First Published at: http://wiki.php.net/rfc/anonymous_classes

any_all_on_iterable_straw_poll_namespace

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/02/03 00:26		current
Line 191:		Line 191:
	===== Vote =====		===== Vote =====

-	Voting started on 2021-01-19 and ended on 2021-02-02	+	Voting started on 2021-01-19 and ended on 2021-02-02. Of the top two options, 12 voters had ranked "PHP\iterable" before the global namespace (including not listing the latter in their vote). 11 voters had ranked the global namespace ahead of "PHP\iterable" (including not listing the latter in the vote). One voter had ranked neither option.

	This vote will influence the name choice for the RFC https://wiki.php.net/rfc/any_all_on_iterable		This vote will influence the name choice for the RFC https://wiki.php.net/rfc/any_all_on_iterable

any_all_on_iterable_straw_poll

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/12/20 15:46		current
Line 3:		Line 3:
	* Date: 2020-12-19		* Date: 2020-12-19
	* Author: Tyson Andre, tandre@php.net		* Author: Tyson Andre, tandre@php.net
-	* Status: Voting	+	* Status: Complete
	* First Published at: http://wiki.php.net/rfc/any_all_on_iterable_straw_poll		* First Published at: http://wiki.php.net/rfc/any_all_on_iterable_straw_poll

Line 50:		Line 50:
	Voting starts on 2020-12-19 and will close on 2020-12-26.		Voting starts on 2020-12-19 and will close on 2020-12-26.

-	<doodle title="Straw poll: Preferred choice of naming pattern" auth="tandre" voteType="multi" closed="false">	+	<doodle title="Straw poll: Preferred choice of naming pattern" auth="tandre" voteType="multi" closed="true">
	* any() and all()		* any() and all()
	* iter_any() and iter_all()		* iter_any() and iter_all()

any_all_on_iterable

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/02/22 15:28		current
Line 325:		Line 325:
	- https://externals.io/message/111756 "[RFC] Global functions any() and all() on iterables"		- https://externals.io/message/111756 "[RFC] Global functions any() and all() on iterables"
	- [[rfc:any_all_on_iterable_straw_poll\|Straw poll: Naming for any() and all() on iterables]]		- [[rfc:any_all_on_iterable_straw_poll\|Straw poll: Naming for any() and all() on iterables]]
-	- [[rfc:any_all_on_iterable_straw_poll_namespace\|Straw poll: Using namespaces for any() and all() on iterables]]	+	- [[rfc:any_all_on_iterable_straw_poll_namespace\|Straw poll: Using namespaces for any() and all() on iterables]] (older poll)
		+	- [[rfc:namespaces_in_bundled_extensions\|RFC: Namespaces in bundled PHP extensions]] (started after voting closed)
		+	- [[rfc:cachediterable_straw_poll\|Straw poll: Namespace to use for CachedIterable and iterable functionality]] (newer poll)
	===== Rejected Features =====		===== Rejected Features =====

any_and_on_iterable

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/08/30 16:11		current
Line 1:		Line 1:
-	====== PHP RFC: any() and and() on iterables ======	+	====== PHP RFC: any() and all() on iterables ======
	* Version: 0.1		* Version: 0.1
	* Date: 2020-08-30		* Date: 2020-08-30

apache_tail_request

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/25 11:23		current
Line 1:		Line 1:
-	====== New apache2handler apache_tail_request() function ======	+	====== New apache_tail_request() function ======
	* Version: 0.9		* Version: 0.9
	* Date: 2015-03-25		* Date: 2015-03-25

apprise_on_invalid_arithmetic_operands

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/04/06 12:07		current
Line 10:		Line 10:

	This is a WIP. Feel free to update this RFC with other cases where you'd like to see ''E_WARNING''s or ''E_NOTICE''s emitted (as well as cases of promoting ''E_NOTICE''s or demoting ''E_WARNING''s).		This is a WIP. Feel free to update this RFC with other cases where you'd like to see ''E_WARNING''s or ''E_NOTICE''s emitted (as well as cases of promoting ''E_NOTICE''s or demoting ''E_WARNING''s).
		+
		+	EDIT related: https://bugs.php.net/bug.php?id=67904

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

apxs-loadmodule

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/02/28 20:07		current
Line 1:		Line 1:
	====== Request for Comments: APXS LoadModule Option in configure ======		====== Request for Comments: APXS LoadModule Option in configure ======
-	* RFC Version: 1.30	+	* RFC Version: 1.40
	* Target PHP Version: 5.4.1		* Target PHP Version: 5.4.1
	* Date: 2012-02-20		* Date: 2012-02-20
	* Author: Kris Craig <kriscraig@php.net>		* Author: Kris Craig <kriscraig@php.net>
-	* Status: Voting Underway	+	* Status: [[rfc/apxs-loadmodule/results\|Accepted]]
	* First Published at: http://wiki.php.net/rfc/apxs-loadmodule		* First Published at: http://wiki.php.net/rfc/apxs-loadmodule

Line 77:		Line 77:
	===== Vote =====		===== Vote =====

-	<doodle	+	[[rfc/apxs-loadmodule/results\|Click here to view the results]].
-	title="Should configure include an option to take advantage of the APXS built-in -a switch as outlined above?" auth="kriscraig" voteType="single">	+
-	* yes	+
-	* no	+
-	</doodle>	+

	===== Changelog =====		===== Changelog =====
		+
		+	Version 1.40 : Status => [[rfc/apxs-loadmodule/results\|Accepted]].

	Version 1.30 : Voting.		Version 1.30 : Voting.

arbitrary_expression_interpolation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/11/27 12:03		current
Line 43:		Line 43:
	* ''{}'' - Poses a potentially large BC break by suddenly giving all curly braces in strings semantic meaning		* ''{}'' - Poses a potentially large BC break by suddenly giving all curly braces in strings semantic meaning
	* ''#{}'' - Poses a low BC break		* ''#{}'' - Poses a low BC break
-	* Sting sigils (such as: ''e"Result: {func()}"'') - Poses no BC break, but is not really applicable to the execution operator, looks ugly for the heredoc syntax, and introduces a "conditionally activated" syntax...	+	* Sting sigils (such as: ''e"Result: {func()}"'') - Poses no BC break, but looks odd to apply to the execution operator (''e`...`''), and looks ugly for the heredoc syntax (''e<''''<''''<END'' or ''e<''''<''''<"END"'')

	Overall, I have chosen the ''#{}'' syntax for its low BC impact, as well as its familiarity (given that the same syntax is used by other languages, including Ruby, Crystal, Elixir, and CoffeeScript).		Overall, I have chosen the ''#{}'' syntax for its low BC impact, as well as its familiarity (given that the same syntax is used by other languages, including Ruby, Crystal, Elixir, and CoffeeScript).
Line 50:		Line 50:
	The new syntax will now cause the character sequence ''#{...}'' to be evaluated within strings.		The new syntax will now cause the character sequence ''#{...}'' to be evaluated within strings.

-	To minimise the BC impact, the ''#'' symbol will not need additional escaping (unlike the ''$'' symbol). This means that regular expressions such as ''#Number \#[1-9][0-9]*#'' can remain unaffected. However, there are still two cases where BC will be broken.	+	To minimise the BC impact, the ''#'' symbol will not need additional escaping (unlike the ''$'' symbol) when used within interpreted (double-quoted/heredoc/execution operator) strings. This means that regular expressions such as ''"#Number \#[1-9][0-9]*#"'' can remain unaffected. However, there are still two cases where BC will be broken.

-	The first is by the consuming of the ''#'' in cases such as ''"#{$n}"'', where the output will now not contain the leading ''#''.	+	The first is by the consuming of the ''#'' in cases where a variable is interpolated with curly braces immediately following it, such as in ''"#{$n}"''. In this case, the output will now not contain the leading ''#'' (it will need to be escaped as ''"\#{$n}"'').

-	The second is that in the event a regular expression specifies a quantity of ''#''s, such as ''"~#{1,2}~"'', then this will now need to be escaped to ''"~\#{1,2}~"''.	+	The second is that in the event a regular expression specifies a quantity of ''#''s, such as ''"~#{1,2}~"'', and this regular expression is encapsulated in evaluated strings, then it will now need to be escaped to ''"~\#{1,2}~"''.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
-	I have tentatively chosen the next major version of PHP (PHP 8, or whatever it will be numbered) for this feature. This is due to the potential BC break with respect to regular expressions.	+	I have tentatively chosen the next major version of PHP (PHP 8, or whatever it will be numbered) for this feature. This is mainly due to the potential BC break with respect to regular expressions.

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

arbitrary_static_variable_initializers

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/04/05 09:59		current
Line 3:		Line 3:
	* Date: 2022-11-06		* Date: 2022-11-06
	* Author: Ilija Tovilo, tovilo.ilija@gmail.com		* Author: Ilija Tovilo, tovilo.ilija@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.3		* Target Version: PHP 8.3
	* Implementation: https://github.com/php/php-src/pull/9301		* Implementation: https://github.com/php/php-src/pull/9301

arbitrary_string_interpolation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/03/27 16:17		current
Line 3:		Line 3:
	* Date: 2022-03-17		* Date: 2022-03-17
	* Author: Ilija Tovilo, tovilo.ilija@gmail.com		* Author: Ilija Tovilo, tovilo.ilija@gmail.com
-	* Status: Under discussion	+	* Status: Withdrawn
	* Target Version: PHP 8.2		* Target Version: PHP 8.2
	* Implementation: https://github.com/php/php-src/pull/8256		* Implementation: https://github.com/php/php-src/pull/8256

argon2_password_hash_enhancements

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/06/23 17:45		current
Line 14:		Line 14:


-	Argon2id is now the recommended Argon2 variant to use in the ITEF draft spec.	+	Argon2id is now the recommended Argon2 variant to use in the IETF draft spec.

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

argon2_password_hash

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-07-10		* Date: 2016-07-10
	* Author: Charles R. Portwood II <charlesportwoodii@erianna.com>		* Author: Charles R. Portwood II <charlesportwoodii@erianna.com>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* First Published at: http://wiki.php.net/rfc/argon2_password_hash		* First Published at: http://wiki.php.net/rfc/argon2_password_hash

argument_unpacking

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/02/26 15:56		current
Line 80:		Line 80:

	<code php>		<code php>
-	var_dump(1, 2, ...null, 3, 4);	+	var_dump(1, 2, ...null, ...[3, 4]);
	// Warning: Only arrays and Traversables can be unpacked		// Warning: Only arrays and Traversables can be unpacked
	// int(1) int(2) int(3) int(4)		// int(1) int(2) int(3) int(4)

arithmetic_operator_type_checks

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/04/30 08:33		current
Line 2:		Line 2:
	* Date: 2020-04-02		* Date: 2020-04-02
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.0		* Target Version: PHP 8.0
	* Implementation: https://github.com/php/php-src/pull/5331		* Implementation: https://github.com/php/php-src/pull/5331

array_change_keys

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-05-29		* Date: 2016-05-29
	* Authors: Colin O'Dell <colinodell@gmail.com>, Jeremy Mikola <jmikola@gmail.com>		* Authors: Colin O'Dell <colinodell@gmail.com>, Jeremy Mikola <jmikola@gmail.com>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/array_change_keys		* First Published at: http://wiki.php.net/rfc/array_change_keys

array_column_results_grouping

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/12/22 09:32		current
Line 3:		Line 3:
	* Date: 2021-11-28		* Date: 2021-11-28
	* Author: Hassan Ahmed, 7snovic@gmail.com		* Author: Hassan Ahmed, 7snovic@gmail.com
-	* Status: Voting	+	* Status: Declined
	* First Published at: https://wiki.php.net/rfc/array_column_results_grouping		* First Published at: https://wiki.php.net/rfc/array_column_results_grouping

Line 134:		Line 134:
	Ends at : 2022-01-04		Ends at : 2022-01-04

-	<doodle title="Add array_group function to PHP" auth="hassan" voteType="single" closed="false">	+	<doodle title="Add array_group function to PHP" auth="hassan" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

array_column

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/03/09 13:09		current
Line 4:		Line 4:
	* Date: 2013-01-11		* Date: 2013-01-11
	* Author: Ben Ramsey <ramsey@php.net>		* Author: Ben Ramsey <ramsey@php.net>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.5
	* First Published at: http://wiki.php.net/rfc/array_column		* First Published at: http://wiki.php.net/rfc/array_column

array_count_handlers

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/07/02 12:02		current
Line 3:		Line 3:
	* Date: 2008-06-25		* Date: 2008-06-25
	* Author: Etienne Kneuss <colder@php.net>		* Author: Etienne Kneuss <colder@php.net>
-	* Status: Draft	+	* Status: Implemented

array_delete

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/06/19 21:41		current
Line 3:		Line 3:
	* Date: 2012-08-21		* Date: 2012-08-21
	* Author: Rasmus Schultz <rasmus@mindplay.dk>, Yasuo Ohgaki <yohgaki@ohgaki.net>/<yohgaki@php.net>		* Author: Rasmus Schultz <rasmus@mindplay.dk>, Yasuo Ohgaki <yohgaki@ohgaki.net>/<yohgaki@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/array_delete		* First Published at: http://wiki.php.net/rfc/array_delete
	===== Introduction =====		===== Introduction =====

array_find

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/05/29 18:13		current
Line 3:		Line 3:
	* Date: 2024-04-07		* Date: 2024-04-07
	* Author: Joshua Rüsweg, josh@php.net		* Author: Joshua Rüsweg, josh@php.net
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/array_find		* First Published at: https://wiki.php.net/rfc/array_find
	* Discussion: https://externals.io/message/123015		* Discussion: https://externals.io/message/123015
		+	* Implementation: https://github.com/php/php-src/pull/14108

	===== Introduction =====		===== Introduction =====

array_first_last

Anonymous (anonymous@undisclosed.example.com) — 2025-10-29T07:34:42+00:00

2025/05/07 17:32		current
Line 113:		Line 113:
	After the project is implemented, this section should contain		After the project is implemented, this section should contain
	- the version(s) it was merged into: 8.5		- the version(s) it was merged into: 8.5
-	- a link to the git commit(s): https://github.com/php/php-src/commit/168343d2e811fe0f2152d39a8f88557cc0b35c86	+	- a link to the git commit(s): https://www.php.net/manual/en/function.array-first.php and https://www.php.net/manual/en/function.array-last.php added in https://github.com/php/php-src/commit/168343d2e811fe0f2152d39a8f88557cc0b35c86
-	- a link to the PHP manual entry for the feature: TBD	+	- a link to the PHP manual entry for the feature: https://github.com/php/doc-en/pull/4925
	- a link to the language specification section (if any): N/A		- a link to the language specification section (if any): N/A

array_get_and_array_has

Anonymous (anonymous@undisclosed.example.com) — 2026-04-18T05:50:39+00:00

2026/04/16 05:42		current
Line 1:		Line 1:
-	====== PHP RFC: array_get and array_has functions ======	+	====== PHP RFC: array_path_get and array_path_exists functions ======
-	* Version: 0.5	+	* Version: 0.6
-	* Date: 2026-04-14	+	* Date: 2026-04-18
	* Author: Carlos Granados, barel.barelon@gmail.com		* Author: Carlos Granados, barel.barelon@gmail.com
	* Status: Under discussion		* Status: Under discussion
Line 43:		Line 43:
	This RFC proposes adding two small, focused array functions to ext/standard for accessing nested arrays using a path in a single step:		This RFC proposes adding two small, focused array functions to ext/standard for accessing nested arrays using a path in a single step:

-	* ''array_get_path()'' retrieves a value from a deeply nested array and returns a default value if the path does not exist.	+	* ''array_path_get()'' retrieves a value from a deeply nested array and returns a default value if the path does not exist.

-	* ''array_has_path()'' checks whether a given nested path exists in an array.	+	* ''array_path_exists()'' checks whether a given nested path exists in an array.

	These operations already appear across PHP codebases and frameworks whenever developers need to traverse structured array data dynamically. Standardizing them in core would make intent explicit, reduce repeated boilerplate, and provide consistent behavior for edge cases.		These operations already appear across PHP codebases and frameworks whenever developers need to traverse structured array data dynamically. Standardizing them in core would make intent explicit, reduce repeated boilerplate, and provide consistent behavior for edge cases.
Line 80:		Line 80:
	$path = getPathFromConfig(); // e.g. ['products', 'desk', 'price']		$path = getPathFromConfig(); // e.g. ['products', 'desk', 'price']

-	$value = array_get_path($array, $path, 'not found');	+	$value = array_path_get($array, $path, 'not found');

	</PHP>		</PHP>
Line 96:		Line 96:
	$path = getPathFromConfig();		$path = getPathFromConfig();

-	if (array_has_path($array, $path)) {	+	if (array_path_exists($array, $path)) {
	// safe to read		// safe to read
	}		}
Line 112:		Line 112:
	$path = explode('.', $dotPath);		$path = explode('.', $dotPath);

-	$value = array_get_path($array, $path);	+	$value = array_path_get($array, $path);
	</PHP>		</PHP>

Line 123:		Line 123:

	<PHP>		<PHP>
-	array_get_path(array $array, array $path, mixed $default = null): mixed	+	array_path_get(array $array, array $path, mixed $default = null): mixed
-	array_has_path(array $array, array $path): bool	+	array_path_exists(array $array, array $path): bool
	</PHP>		</PHP>

Line 131:		Line 131:
	* The array being inspected is the first argument		* The array being inspected is the first argument
	* The path is the second argument		* The path is the second argument
-	* ''array_get_path()'' accepts an optional default value as the third argument	+	* ''array_path_get()'' accepts an optional default value as the third argument

	==== Common behaviour ====		==== Common behaviour ====
Line 152:		Line 152:
	Missing path behaviour: If any path is not found, no errors or warnings will be thrown. Instead:		Missing path behaviour: If any path is not found, no errors or warnings will be thrown. Instead:

-	* ''array_get_path()'' returns ''$default''	+	* ''array_path_get()'' returns ''$default''
-	* ''array_has_path()'' returns ''false''	+	* ''array_path_exists()'' returns ''false''

-	''array_has_path()'' uses existence semantics similar to ''array_key_exists()'':	+	''array_path_exists()'' uses existence semantics similar to ''array_key_exists()'':

-	* If the final key exists and its value is ''null'', ''array_has_path()'' still returns ''true''.	+	* If the final key exists and its value is ''null'', ''array_path_exists()'' still returns ''true''.

	==== Exact semantics (per function) ====		==== Exact semantics (per function) ====

-	* ''array_get_path()''	+	* ''array_path_get()''
	<PHP>		<PHP>
-	function array_get_path(array $array, array $path, mixed $default = null): mixed {	+	function array_path_get(array $array, array $path, mixed $default = null): mixed {
	foreach ($path as $segment) {		foreach ($path as $segment) {
	if (!is_string($segment) && !is_int($segment)) {		if (!is_string($segment) && !is_int($segment)) {
Line 186:		Line 186:
	* If the final key exists return its value.		* If the final key exists return its value.

-	* ''array_has_path()''	+	* ''array_path_exists()''
	<PHP>		<PHP>
-	function array_has_path(array $array, array $path): bool {	+	function array_path_exists(array $array, array $path): bool {
	foreach ($path as $segment) {		foreach ($path as $segment) {
	if (!is_string($segment) && !is_int($segment)) {		if (!is_string($segment) && !is_int($segment)) {
Line 217:		Line 217:
	$array = ['users' => [['name' => 'Alice']]];		$array = ['users' => [['name' => 'Alice']]];

-	array_get_path($array, ['users', 0, 'name']); // 'Alice'	+	array_path_get($array, ['users', 0, 'name']); // 'Alice'
-	array_has_path($array, ['users', 0, 'name']); // true	+	array_path_exists($array, ['users', 0, 'name']); // true
	</PHP>		</PHP>

Line 228:		Line 228:
	$array = ['a' => ['b' => null]];		$array = ['a' => ['b' => null]];

-	array_get_path($array, ['a', 'b']); // null	+	array_path_get($array, ['a', 'b']); // null
-	array_has_path($array, ['a', 'b']); // true	+	array_path_exists($array, ['a', 'b']); // true
	</PHP>		</PHP>

Line 239:		Line 239:
	$array = ['home' => ['sub' => ['third' => 'value']]];		$array = ['home' => ['sub' => ['third' => 'value']]];

-	array_get_path($array, ['home', new stdClass(), 'third'], 'default'); // 'default'	+	array_path_get($array, ['home', new stdClass(), 'third'], 'default'); // 'default'
-	array_has_path($array, ['home', new stdClass(), 'third']); // false	+	array_path_exists($array, ['home', new stdClass(), 'third']); // false
	</PHP>		</PHP>

Line 252:		Line 252:
	$array = ['products' => ['desk' => ['price' => 100]]];		$array = ['products' => ['desk' => ['price' => 100]]];

-	$price = array_get_path($array, ['products', 'desk', 'price']); // 100	+	$price = array_path_get($array, ['products', 'desk', 'price']); // 100
-	$discount = array_get_path($array, ['products', 'desk', 'discount'], 10); // 10	+	$discount = array_path_get($array, ['products', 'desk', 'discount'], 10); // 10
	</PHP>		</PHP>

Line 261:		Line 261:
	$array = ['product' => ['name' => 'Desk', 'price' => 100]];		$array = ['product' => ['name' => 'Desk', 'price' => 100]];

-	array_has_path($array, ['product', 'name']); // true	+	array_path_exists($array, ['product', 'name']); // true
-	array_has_path($array, ['product', 'color']); // false	+	array_path_exists($array, ['product', 'color']); // false
	</PHP>		</PHP>

Line 275:		Line 275:
	];		];

-	array_get_path($array, ['users', 1, 'name']); // 'Bob'	+	array_path_get($array, ['users', 1, 'name']); // 'Bob'
-	array_has_path($array, ['users', 2, 'name']); // false	+	array_path_exists($array, ['users', 2, 'name']); // false
	</PHP>		</PHP>

Line 284:		Line 284:
	$path = getPathFromConfiguration();		$path = getPathFromConfiguration();

-	$value = array_get_path($array, $path, 'not found');	+	$value = array_path_get($array, $path, 'not found');
	</PHP>		</PHP>

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

-	<doodle title="Implement array_get_path and array_has_path functions as outlined in the RFC?" voteType="single" closed="true" closeon="2026-01-01T15:30:00Z">	+	<doodle title="Implement array_path_get and array_path_exists functions as outlined in the RFC?" voteType="single" closed="true" closeon="2026-01-01T15:30:00Z">
	* Yes		* Yes
	* No		* No
Line 353:		Line 353:
	* 2026-04-11: Remove accepting a $key parameter with dot notation and only use a $path parameter with an array path		* 2026-04-11: Remove accepting a $key parameter with dot notation and only use a $path parameter with an array path
	* 2026-04-14: Modify function names to add _path suffix, throw TypeError if segment is not int\|string		* 2026-04-14: Modify function names to add _path suffix, throw TypeError if segment is not int\|string
		+	* 2026-04-18: Modify function names to array_path_get and array_path_exists

array_get_path_and_array_has_path

Anonymous (anonymous@undisclosed.example.com) — 2026-04-14T16:46:23+00:00

2026/04/14 16:45		current
Line 344:		Line 344:

	Discussion: https://news-web.php.net/php.internals/130559		Discussion: https://news-web.php.net/php.internals/130559
		+
		+	Replaces this RFC due to the change in the name of the functions: https://wiki.php.net/rfc/array_get_and_array_has

	===== Changelog =====		===== Changelog =====

array_group

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/06/01 00:07		current
Line 12:		Line 12:
	Almost all mainstream programming languages have a built-in grouping functionality:		Almost all mainstream programming languages have a built-in grouping functionality:

-	* [[https://www.scala-lang.org/api/2.12.4/scala/collection/parallel/ParIterableLike$GroupBy.html\|Scala]]	+	* [[https://learn.microsoft.com/en-us/dotnet/api/system.linq.enumerable.groupby?view=net-7.0\|.NET]]
	* [[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/group\|JavaScript]]		* [[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/group\|JavaScript]]
		+	* [[https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collectors.html#groupingBy-java.util.function.Function-\|Java]]
		+	* [[https://www.scala-lang.org/api/2.12.4/scala/collection/parallel/ParIterableLike$GroupBy.html\|Scala]]
	* [[https://hackage.haskell.org/package/groupBy-0.1.0.0/docs/Data-List-GroupBy.html\|Haskell]]		* [[https://hackage.haskell.org/package/groupBy-0.1.0.0/docs/Data-List-GroupBy.html\|Haskell]]
-	* [[https://learn.microsoft.com/en-us/dotnet/api/system.linq.enumerable.groupby?view=net-7.0\|.NET]]

	The way this has been approached in PHP in the past was to just implement a custom function and use it. This has several drawbacks:		The way this has been approached in PHP in the past was to just implement a custom function and use it. This has several drawbacks:

array_key_first_last_index

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-01-01		* Date: 2016-01-01
	* Author: John Bafford		* Author: John Bafford
-	* Status: Under Discussion	+	* Status: Obsolete
	* First Published at: http://wiki.php.net/rfc/array_key_first_last_index		* First Published at: http://wiki.php.net/rfc/array_key_first_last_index

		+	> This proposal has been superseded by [[rfc:array_key_first_last\|array_key_first(), array_key_last()]], which has been implemented in PHP 7.3.

	===== Introduction =====		===== Introduction =====

array_key_first_last

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/07/16 23:03		current
Line 3:		Line 3:
	* Date: 2018-06-11		* Date: 2018-06-11
	* Author: Enno Woortmann<enno.woortmann@web.de>		* Author: Enno Woortmann<enno.woortmann@web.de>
-	* Status: Accepted partially	+	* Status: Accepted functions array_key_first() and array_key_last() implemented in PHP 7.3
	* First Published at: http://wiki.php.net/rfc/array_key_first_last		* First Published at: http://wiki.php.net/rfc/array_key_first_last

Line 123:		Line 123:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged into	+	The implementation for array_key_first() and array_key_last() was merged for PHP 7.3 with the commit http://git.php.net/?p=php-src.git;a=commit;h=50516a6
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+	The documentation for the added functions is loated at:
-	- a link to the language specification section (if any)	+
		+	* http://php.net/manual/en/function.array-key-first.php
		+	* http://php.net/manual/en/function.array-key-last.php

	===== History =====		===== History =====

array_only_except

Anonymous (anonymous@undisclosed.example.com) — 2026-04-09T01:13:20+00:00

2026/03/12 17:20		current
Line 3:		Line 3:
	* Date: 2026-02-20		* Date: 2026-02-20
	* Author: Muhammed Arshid KV, arshidkv12@gmail.com		* Author: Muhammed Arshid KV, arshidkv12@gmail.com
-	* Status: Voting	+	* Status: Declined
	* Implementation: TBD		* Implementation: TBD

array_part

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/05/28 15:19		current
Line 3:		Line 3:
	* Date: 2012-05-14		* Date: 2012-05-14
	* Author: Gustavo Lopes <cataphract@php.net>		* Author: Gustavo Lopes <cataphract@php.net>
-	* Status: Under Discussion	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/array_part		* First Published at: http://wiki.php.net/rfc/array_part

array_reindex

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/03/07 13:27		current
Line 1:		Line 1:
-	====== PHP RFC: Your Title Here ======	+	====== PHP RFC: array_reindex function ======
	* Version: 0.1		* Version: 0.1
	* Date: 2019-03-07		* Date: 2019-03-07

array_unpacking_string_keys

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/02/08 16:00		current
Line 2:		Line 2:
	* Date: 2021-01-07		* Date: 2021-01-07
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Proposed Version: PHP 8.1		* Proposed Version: PHP 8.1
	* Implementation: https://github.com/php/php-src/pull/6584		* Implementation: https://github.com/php/php-src/pull/6584

array-sort-return-array

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/10/21 13:00		current
Line 4:		Line 4:
	* Date: 2024-10-20		* Date: 2024-10-20
	* Author: Gina Peter Banyard <girgias@php.net>		* Author: Gina Peter Banyard <girgias@php.net>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Target Version: PHP 8.5		* Target Version: PHP 8.5
	* Implementation: TBD		* Implementation: TBD
Line 77:		Line 77:

	===== References =====		===== References =====
		+
		+	Internals discussion thread: https://externals.io/message/125809

array-to-string

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 100:		Line 100:
	Basic Yes/No : Yes to replace E_NOTICE with E_RECOVERABLE_ERROR, No for no change.		Basic Yes/No : Yes to replace E_NOTICE with E_RECOVERABLE_ERROR, No for no change.

-	<doodle title="array-to-string" auth="francois" voteType="single" closed="false">	+	<doodle title="array-to-string" auth="francois" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

arrayiterator-improvements

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/11/24 21:10		current
Line 17:		Line 17:
	The existing method ''ArrayIterator::seek($position)'' searches for the Entry in a linear manner, and this is not ideal for many uses, as what it does is simply iterating over the array (or part of it) to reach the specified position (or key, assuming the array is a list). Instead, the proposed method ''ArrayIterator::seekKey($key)'' would be a ''O(1)'' operation as the cursor can immediately jump to the Entry identified by the given ''$key''.		The existing method ''ArrayIterator::seek($position)'' searches for the Entry in a linear manner, and this is not ideal for many uses, as what it does is simply iterating over the array (or part of it) to reach the specified position (or key, assuming the array is a list). Instead, the proposed method ''ArrayIterator::seekKey($key)'' would be a ''O(1)'' operation as the cursor can immediately jump to the Entry identified by the given ''$key''.

-	Specifically, if the given key is present in the array the method would successfully return ''null''; subsequent calls to ''ArrayIterator::current()'' would get the value associated with the specified ''$key'', ''ArrayIterator::key()'' would get ''$key'' and so on, like it would normally behave when iterating over the Entry. Instead, if the provided key is not present in the array, and exactly like ''ArrayIterator::seek($position)'', the method would throw a ''OutOfBoundsException'' and keep the current ''ArrayIterator'''s cursor state.	+	Specifically, if the given key is present in the array the method would successfully execute such that subsequent calls to ''ArrayIterator::current()'' would get the value associated with the specified ''$key'', ''ArrayIterator::key()'' would get ''$key'' and so on, like it would normally behave when iterating over the Entry. Instead, if the provided key is not present in the array, and exactly like ''ArrayIterator::seek($position)'', the method would throw a ''OutOfBoundsException'' and keep the current ''ArrayIterator'''s cursor state.

	===== ArrayIterator::prev():void =====		===== ArrayIterator::prev():void =====

arrayof

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/06/23 19:33		current
Line 181:		Line 181:
	VOTE: 2014/02/28 - 2014/03/07		VOTE: 2014/02/28 - 2014/03/07

-	<doodle title="Array Of Type Hinting" auth="philstu" voteType="single" closed="false">	+	<doodle title="Array Of Type Hinting" auth="philstu" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

arrow_function_preference

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/07/06 16:45		current
Line 138:		Line 138:


-	<doodle title="Practice vote for Preference of Arrow Function Syntax for PHP 7.2" auth="levim voteType="multi" closed="false">	+	<doodle title="Practice vote for Preference of Arrow Function Syntax for PHP 7.2" auth="levim voteType="multi" closed="TRUE">
	* Prefixed with fn		* Prefixed with fn
	* Enclosed by curly-braces		* Enclosed by curly-braces

arrow_functions_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/04/18 14:54		current
Line 6:		Line 6:
	* Target version: PHP 7.4		* Target version: PHP 7.4
	* Implementation: https://github.com/php/php-src/pull/3941		* Implementation: https://github.com/php/php-src/pull/3941
-	* Status: Accepted	+	* Status: Implemented

	===== Introduction =====		===== Introduction =====

arrow_functions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 4:		Line 4:
	* Author: Levi Morrison <levim@php.net>		* Author: Levi Morrison <levim@php.net>
	* Author: Bob Weinand <bwoebi@php.net>		* Author: Bob Weinand <bwoebi@php.net>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/arrow_functions		* First Published at: http://wiki.php.net/rfc/arrow_functions

assert-string-eval-cleanup

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/07/12 14:14		current
Line 3:		Line 3:
	* Date: 2023-05-31		* Date: 2023-05-31
	* Author: George Peter Banyard, <girgias@php.net>		* Author: George Peter Banyard, <girgias@php.net>
-	* Status: In Voting	+	* Status: Implemented: https://github.com/php/php-src/commit/3d4ff5ae22e73a3f4c41a26c0d2eb11646ecdd88
	* Target Version: PHP 8.3		* Target Version: PHP 8.3
	* First Published at: https://wiki.php.net/rfc/assert-string-eval-cleanup		* First Published at: https://wiki.php.net/rfc/assert-string-eval-cleanup
Line 107:		Line 107:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged into	+	Implemented in PHP 8.3:
-	- a link to the git commit(s)	+
		+	- Commit: https://github.com/php/php-src/commit/3d4ff5ae22e73a3f4c41a26c0d2eb11646ecdd88
	- a link to the PHP manual entry for the feature		- a link to the PHP manual entry for the feature
-	- a link to the language specification section (if any)

assignment-overloading

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/01/04 00:32		current
Line 7:		Line 7:

	===== Introduction =====		===== Introduction =====
-	PHP allows for basic operator overloading for builtin objects. For example, in the following code, gmp_init() produces an object instance of class "GMP", yet the addition operation is not only valid, it produces a valid result (a new object with an updated value).	+	PHP allows for basic operator overloading for builtin objects. For example, in the following code, gmp_init() produces an object instance of class "GMP", yet the addition operation is not only valid, it produces a valid result (a new object with an updated value).

	<?php		<?php
Line 14:		Line 14:
	var_dump($h); // object(GMP)#2 { ["num"]=>125 }		var_dump($h); // object(GMP)#2 { ["num"]=>125 }

-	Specifically, the following basic operators are overloaded: + - * / ** .	+	Specifically, the following basic operators are overloaded: + - * / %%**%% .

-	In addition, the assignment versions of these operators ( += -= = /= *= .= ) are supported by executing a normal operation followed by a store. Thus the following two blocks of code are effectively identical.	+	In addition, the assignment versions of these operators ( += -= = /= %%*%%= .= ) are supported by executing a normal operation followed by a store. Thus the following two blocks of code are effectively identical.

	<?php		<?php

ast_based_parsing_compilation_process

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/08/18 16:45		current
Line 1:		Line 1:
-	====== Request for Comments: Moving to an AST-based parsing/compilation process ======	+	====== Request for Comments: Moving to an AST-based parsing/compilation process (obsolete) ======
	* Date: 2012-09-04		* Date: 2012-09-04
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>

asymmetric-visibility-v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/08/10 13:38		current
Line 3:		Line 3:
	* Date: 2024-05-09		* Date: 2024-05-09
	* Author: Ilija Tovilo (tovilo.ilija@gmail.com), Larry Garfield (larry@garfieldtech.com)		* Author: Ilija Tovilo (tovilo.ilija@gmail.com), Larry Garfield (larry@garfieldtech.com)
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/asymmetric-visibility-v2		* First Published at: http://wiki.php.net/rfc/asymmetric-visibility-v2
	* Implementation: https://github.com/php/php-src/pull/15063		* Implementation: https://github.com/php/php-src/pull/15063

asymmetric-visibility

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/01/09 23:52		current
Line 3:		Line 3:
	* Date: 2022-07-21		* Date: 2022-07-21
	* Author: Ilija Tovilo (tovilo.ilija@gmail.com), Larry Garfield (larry@garfieldtech.com)		* Author: Ilija Tovilo (tovilo.ilija@gmail.com), Larry Garfield (larry@garfieldtech.com)
-	* Status: In voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/asymmetric-visibility		* First Published at: http://wiki.php.net/rfc/asymmetric-visibility
	* Implementation: https://github.com/php/php-src/pull/9257		* Implementation: https://github.com/php/php-src/pull/9257
Line 282:		Line 282:
	This is a simple yes-or-no vote to include this feature. 2/3 majority required to pass.		This is a simple yes-or-no vote to include this feature. 2/3 majority required to pass.

-	<doodle title="Include asymmetric visibility?" auth="crell" voteType="single" closed="false">	+	<doodle title="Include asymmetric visibility?" auth="crell" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 291:		Line 291:
	If you vote no, the authors would appreciate feedback as to why (if you vote Yes, ignore this).		If you vote no, the authors would appreciate feedback as to why (if you vote Yes, ignore this).

-	<doodle title="If voting no, why?" auth="crell" voteType="single" closed="false">	+	<doodle title="If voting no, why?" auth="crell" voteType="single" closed="true">
	* Dislike feature itself		* Dislike feature itself
	* Syntax details		* Syntax details

async_signals

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/07/06 10:15		current
Line 56:		Line 56:
	After the project is implemented, this section should contain		After the project is implemented, this section should contain
	- [[http://git.php.net/?p=php-src.git;a=commitdiff;h=c03ccfe78d6b13cab9546efb616a42a8f3e8a4e0\|c03ccfe78d6b13cab9546efb616a42a8f3e8a4e0]]		- [[http://git.php.net/?p=php-src.git;a=commitdiff;h=c03ccfe78d6b13cab9546efb616a42a8f3e8a4e0\|c03ccfe78d6b13cab9546efb616a42a8f3e8a4e0]]
-	- a link to the PHP manual entry for the feature	+	- Documentation: http://php.net/manual/en/function.pcntl-async-signals.php

attribute_amendments

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/06/29 08:46		current
Line 7:		Line 7:
	* Target: 8.0		* Target: 8.0
	* First Published at: http://wiki.php.net/rfc/attribute_amendments		* First Published at: http://wiki.php.net/rfc/attribute_amendments
-	* Patch: https://github.com/koolkode/php-src/pull/4	+	* Patch: https://github.com/php/php-src/pull/5751

	===== Introduction =====		===== Introduction =====
Line 236:		Line 236:
	===== Patches and Tests =====		===== Patches and Tests =====

-	- https://github.com/koolkode/php-src/pull/4	+	- https://github.com/php/php-src/pull/5751

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

attribute-target-reflector

Anonymous (anonymous@undisclosed.example.com) — 2025-07-07T23:29:48+00:00

2025/07/07 23:29		current
Line 1:		Line 1:
	<!DOCTYPE markdown>		<!DOCTYPE markdown>

-	# PHP RFC: Add ReflectionAttribute->getTargetReflector() ======	+	# PHP RFC: Add ReflectionAttribute->getTargetReflector(
	* Version: 0.9		* Version: 0.9
	* Date: 2025-07-07 (use today's date here)		* Date: 2025-07-07 (use today's date here)

attributes_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/04 12:00		current
Line 4:		Line 4:
	* Date: 2020-03-09		* Date: 2020-03-09
	* Author: Benjamin Eberlei (beberlei@php.net), Martin Schröder		* Author: Benjamin Eberlei (beberlei@php.net), Martin Schröder
-	* Status: Accepted	+	* Status: Implemented
	* Target: 8.0		* Target: 8.0
	* First Published at: http://wiki.php.net/rfc/attributes_v2		* First Published at: http://wiki.php.net/rfc/attributes_v2

attributes-on-constants

Anonymous (anonymous@undisclosed.example.com) — 2025-04-29T19:52:21+00:00

2025/04/03 13:08		current
Line 3:		Line 3:
	* Date: 2024-11-30		* Date: 2024-11-30
	* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com		* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com
-	* Status: Pending Implementation	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/attributes-on-constants		* First Published at: https://wiki.php.net/rfc/attributes-on-constants
	* Implementation: https://github.com/php/php-src/pull/16952		* Implementation: https://github.com/php/php-src/pull/16952

attributes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/05/12 04:51		current
Line 3:		Line 3:
	* Date: 2016-04-21		* Date: 2016-04-21
	* Author: Dmitry Stogov, dmitry@zend.com		* Author: Dmitry Stogov, dmitry@zend.com
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/attributes		* First Published at: http://wiki.php.net/rfc/attributes

Line 463:		Line 463:
	The voting started on May 10th, 2016 and will close on May 24th, 2016.		The voting started on May 10th, 2016 and will close on May 24th, 2016.

-	<doodle title="Accept PHP Attributes? (2/3+1 majority required)" auth="dmitry" voteType="single" closed="false">	+	<doodle title="Accept PHP Attributes? (2/3+1 majority required)" auth="dmitry" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 470:		Line 470:
	----		----

-	<doodle title="What may be used as attribute value? (simple majority wins)" auth="dmitry" voteType="single" closed="false">	+	<doodle title="What may be used as attribute value? (simple majority wins)" auth="dmitry" voteType="single" closed="true">
	* valid PHP expression (internally represented as AST)		* valid PHP expression (internally represented as AST)
	* valid PHP constant (number or string)		* valid PHP constant (number or string)

auto-capture-closure

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/07/02 13:12		current
Line 5:		Line 5:
	* Author: Larry Garfield (larry@garfieldtech.com)		* Author: Larry Garfield (larry@garfieldtech.com)
	* Author: Arnaud Le Blanc (arnaud.lb@gmail.com)		* Author: Arnaud Le Blanc (arnaud.lb@gmail.com)
-	* Status: In Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/auto-capture-closure		* First Published at: http://wiki.php.net/rfc/auto-capture-closure

Line 415:		Line 415:


-	<doodle title="Add Short Closures as described in PHP 8.2?" auth="jrf" voteType="single" closed="false">	+	<doodle title="Add Short Closures as described in PHP 8.2?" auth="jrf" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

auto-capture-lambda

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/03/24 15:54		current
Line 1:		Line 1:
-	====== PHP RFC: Auto-capturing multi-statement closures ======	+	[[rfc:auto-capture-closure\|Moved. See the Auto-capturing multi-statement closures RFC]]
-	* Version: 0.9	+
-	* Date: 2021-03-22	+
-	* Author: Nuno Maduro (enunomaduro@gmail.com), Larry Garfield (larry@garfieldtech.com)	+
-	* Status: Draft	+
-	* First Published at: http://wiki.php.net/rfc/auto-capture-lambda	+
-		+
-	===== Introduction =====	+
-		+
-	Closures (also known as lambdas or anonymous functions), have become increasingly powerful and useful in PHP in recent versions. In their current form they have two versions, long and short. Unfortunately, these two syntaxes have different, mutually-incompatible benefits. This RFC proposes a syntax for closures that combines the benefits of both for those situations where that is warranted.	+
-		+
-	<code php>	+
-	// As of 8.0:	+
-		+
-	$y = 1;	+
-		+
-	$fn1 = fn($x) => $x + $y; // auto-capture + single expression	+
-		+
-	$fn2 = function ($x) use ($y): int { // manual-capture + statement list	+
-	// ...	+
-		+
-	return $x + $y;	+
-	};	+
-	</code>	+
-		+
-	The proposed syntax combines the auto-capture and multi-line capabilities into a single syntax:	+
-		+
-	<code php>	+
-	$fn3 = fn ($x): int { // auto-capture + statement list	+
-	// ...	+
-		+
-	return $x + $y;	+
-	};	+
-	</code>	+
-		+
-	This RFC has also been designed in concert with the [[rfc:short-functions\|Short Functions]] RFC, such that the syntax choices of both RFCs are mutually complementary in a logical, predictable fashion and described below.	+
-		+
-	===== Proposal =====	+
-		+
-	==== Background ====	+
-		+
-	As of PHP 8.0, the following syntax around functions has the following meaning:	+
-		+
-	<code php>	+
-		+
-	// A named, globally available function.	+
-	// No variables are auto-captured from the environment.	+
-	// The body is a statement list, with possibly a return statement.	+
-	function foo($a, $b, $c): int {	+
-	*return $a $b * $c;**	+
-	}	+
-		+
-	// An anonymous, locally available function.	+
-	// Variables are explicitly captured lexically.	+
-	// The body is a statement list, with possibly a return statement.	+
-	$foo = function ($a, $b) use ($c) {	+
-	*return $a $b * $c;**	+
-	};	+
-		+
-	// An anonymous, locally available function.	+
-	// Variables are auto-captured lexically.	+
-	// The body is a single-expression, whose value is returned.	+
-	*$foo = fn($a, $b): int => $a $b * $c;**	+
-	</code>	+
-		+
-	That is, a function may be named or local/anonymous, auto-capture or not, and a statement list or single expression. That means there are 8 possible combinations of properties, of which only three are currently supported.	+
-		+
-	The [[rfc:short-functions\|Short Functions]] RFC seeks to add one additional combination: named, no-capture, single-expression.	+
-		+
-	This RFC seeks to add a different combination: anonymous, auto-capture, statement list.	+
-		+
-	The remaining combinations would be:	+
-		+
-	* named function, auto-capture, statement list - This is of little use in practice as there is nothing to auto-capture, except potentially global variables.	+
-	* named function, auto-capture, expression - Ibid.	+
-	* anonymous function, manual-capture, expression - While this form would be possible to add, its use cases are limited. The existing short-closure syntax is superior in nearly all cases.	+
-		+
-	==== Auto-capture multi-statement closures ====	+
-		+
-	Specifically, this RFC adds the following syntax:	+
-		+
-	<code php>	+
-	// An anonymous, locally available function.	+
-	// Variables are auto-captured lexically.	+
-	// The body is a statement list, with possibly a return statement;	+
-	$c = 1;	+
-	$foo = fn($a, $b):int {	+
-	*$val = $a $b;**	+
-	*return $val $c;**	+
-	};	+
-	</code>	+
-		+
-	The syntax choice here, in combination with the short-functions RFC, leads to the following consistent syntactic meanings:	+
-		+
-	* The ''=>'' sigil always means "evaluates to the expression on the right," in all circumstances. (Named functions, anonymous functions, arrays, and ''match()''.)	+
-	* ''{ ... }'' denotes a statement list, potentially ending in a ''return''.	+
-	* The ''function'' keyword indicates a function that has no auto-capture.	+
-	* The ''fn'' keyword indicates a function that will auto-capture variables, by value.	+
-	* A function with a name is declared globally at compile time. A function without a name is declared locally as a closure at runtime.	+
-		+
-	These rules are easily recognizable and learnable by developers.	+
-		+
-	==== Methods ====	+
-		+
-	As methods cannot be anonymous, there are no impacts on methods from this RFC. The short-functions RFC does address methods, and does so in a way that is completely consistent with the syntactic rules defined above.	+
-		+
-	==== What about long-closures? ====	+
-		+
-	The existing multi-line closure syntax remains valid, and there is no intent to deprecate it. It is likely to become less common in practice, but it still has two use cases where it will be necessary:	+
-		+
-	* When it is desirable to capture variables explicitly, such as to avoid name collision.	+
-	* When it is desirable to capture a variable by reference. Such use case are rare but do exist.	+
-		+
-	<code php>	+
-	// This remains the only way to capture by reference.	+
-	$c = 1;	+
-	$f = function($a, $b) use (&$c) {	+
-	*$c = $a $b;**	+
-	};	+
-	</code>	+
-		+
-	==== Multi-line expressions ====	+
-		+
-	There has been related discussion of multi-line expressions, specifically in the context of ''mach()'' arms. We considered whether multi-line expressions made sense as an alternative approach, but decided against it as that introduces considerably more edge cases both syntactically and in the engine.	+
-		+
-	As a side benefit, the syntax proposed here does offer a somewhat round-about way to have a multi-line ''match()'' arm. This is not a deliberate feature of the RFC, but more of a convenient side-effect.	+
-		+
-	<code php>	+
-	$b = ...;	+
-	$c = ...;	+
-	$ret = match ($a) {	+
-	1, 3, 5 => fn() {	+
-	*$val = $a $b;**	+
-	*return $val $c;**	+
-	}(),	+
-	2, 4, 6 => fn() {	+
-	$val = $a + $b;	+
-	return $val + $c;	+
-	}(),	+
-	};	+
-	</code>	+
-		+
-	While sub-optimal, it may be sufficient for the few times that a multi-statement ''match()'' arm is needed.	+
-		+
-	===== Backward Incompatible Changes =====	+
-		+
-	None.	+
-		+
-	===== Proposed PHP Version(s) =====	+
-		+
-	PHP 8.1.	+
-		+
-	===== Open Issues =====	+
-		+
-	None.	+
-		+
-	===== Unaffected PHP Functionality =====	+
-		+
-	Existing function syntax continues to work precisely as it does now. Only new combinations are possible.	+
-		+
-	===== Future Scope =====	+
-		+
-	The proposal section detailed three additional possible combinations of function functionality that are not included here. While it is not likely that they have much use, the pattern here clearly lays out what they would be were a future RFC to try and implement them.	+
-		+
-	Specifically, they would be:	+
-		+
-	<code php>	+
-	// Global scope	+
-	$c = 1;	+
-		+
-	fn foo($a, $b): int {	+
-	*$val = $a $b;**	+
-	*return $val $c;**	+
-	}	+
-		+
-	*fn foo($a, $b): int => $a $b * $c;**	+
-		+
-	*$foo = fn($a, $b) use ($c): int => $a $b * $c;**	+
-	</code>	+
-		+
-	Those versions are //not// included in this RFC.	+
-		+
-	===== Proposed Voting Choices =====	+
-		+
-	This is a simple Yes/No vote, requiring 2/3 to pass.	+
-		+
-	===== Patches and Tests =====	+
-		+
-	Pull Request: https://github.com/php/php-src/pull/6246	+
-		+
-	===== Implementation =====	+
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged into	+
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+
-	- a link to the language specification section (if any)	+
-		+
-	===== References =====	+
-	[[rfc:short-functions\|PHP RFC: Short Functions]]	+
-		+
-	===== Rejected Features =====	+
-	Keep this updated with features that were discussed on the mail lists.	+

auto-implement_stringable_for_string_backed_enums

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/06/21 22:42		current
Line 3:		Line 3:
	* Date: 2022-06-21		* Date: 2022-06-21
	* Author: Ilija Tovilo <tovilo.ilija@gmail.com>, Nicolas Grekas <nicolasgrekas@php.net>		* Author: Ilija Tovilo <tovilo.ilija@gmail.com>, Nicolas Grekas <nicolasgrekas@php.net>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Implementation: https://github.com/php/php-src/pull/8825		* Implementation: https://github.com/php/php-src/pull/8825
	* First Published at: https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums		* First Published at: https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums

autoboxing

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2010-05-04		* Date: 2010-05-04
	* Author: Moriyoshi Koizumi <moriyoshi@php.net>		* Author: Moriyoshi Koizumi <moriyoshi@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/autoboxing		* First Published at: http://wiki.php.net/rfc/autoboxing
-	* Other formats ..

	===== Introduction =====		===== Introduction =====

autodefine

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2010-12-07		* Date: 2010-12-07
	* Author: Reinier van Loon <reinier.van.loon@gmail.com>		* Author: Reinier van Loon <reinier.van.loon@gmail.com>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/autodefine		* First Published at: http://wiki.php.net/rfc/autodefine

autofunc

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/08/17 20:59		current
Line 3:		Line 3:
	* Date: 2011-08-05		* Date: 2011-08-05
	* Author: Ferenc Kovacs <tyra3l@gmail.com>		* Author: Ferenc Kovacs <tyra3l@gmail.com>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: https://wiki.php.net/rfc/autofunc		* First Published at: https://wiki.php.net/rfc/autofunc

autoload_classmap

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/03/19 18:37		current
Line 31:		Line 31:
	* Always check the classmap first if it is set.		* Always check the classmap first if it is set.
	* (If Found) Trigger a TypeError if the key's associated value is not a string.		* (If Found) Trigger a TypeError if the key's associated value is not a string.
-	* (If Found) Use the REQUIRE_ONCE mechanism.	+	* (If Found) Use the REQUIRE mechanism.
	* (If Found) Trigger an Error if the relevant class is not defined after including the file specified in the classmap.		* (If Found) Trigger an Error if the relevant class is not defined after including the file specified in the classmap.

autoload_include

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/12/23 15:12		current
Line 3:		Line 3:
	* Date: 2009-11-10		* Date: 2009-11-10
	* Author: Lukas Smith <smith@pooteeweet.org>		* Author: Lukas Smith <smith@pooteeweet.org>
-	* Status: [[http://news.php.net/php.internals/46162\|Proposed]]	+	* Status: updated stream_resolve_include_path() was added in PHP 5.3.3
	* First Published at: http://wiki.php.net/rfc/autoload_include		* First Published at: http://wiki.php.net/rfc/autoload_include

Line 66:		Line 66:

	* [[http://valokuva.org/patches/php/new/stream_resolve_include_path.txt}\|patch to add an improved stream_resolve_include_path() to 5.3]]		* [[http://valokuva.org/patches/php/new/stream_resolve_include_path.txt}\|patch to add an improved stream_resolve_include_path() to 5.3]]
-

automatic_csrf_protection

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-05-10		* Date: 2016-05-10
	* Author: Yasuo Ohgaki <yohgaki@php.net>		* Author: Yasuo Ohgaki <yohgaki@php.net>
-	* Status: Draft	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/automatic_csrf_protection		* First Published at: http://wiki.php.net/rfc/automatic_csrf_protection

automatic_get_set_methods

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== Request for Comments: Automatic get/set methods for objects ======
	+	* Version: 1.0
	+	* Date: 2008-12-16
	+	* Author: Michael Kimsal <michael@kimsal.com>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/automatic_get_set_methods
	+
	+
	+	===== Introduction =====
	+
	+	Currently, PHP only allows for defining functionality during access to properties on an object when those properties are not defined in the class. This proposal will outline a suggested change to PHP's behaviour when dealing with object properties which will allow for compact code when necessary, and easy refactoring of code when necessary with a minimum of fuss.
	+
	+	===== Proposal version 1 =====
	+
	+	When a class is initialized at runtime, each property will have a 'get' and a 'set' method created for it which will handle basic 'get/set' functionality. If a get or set method exists for the given property, then the corresponding auto-generated method would not be auto-generated.
	+
	+	===== Proposal version 2 =====
	+
	+	When a property on an object is attempted to be read, the PHP engine will look for a corresponding getXXX() method for the given property. If one exists, that methods will be executed. If not, the property will be returned (subject the public/protected/private visibility). Similarly, when a property on an object is attempted to be set, the PHP engine will look for a corresponding setXXX() method. If one exists, that method will be executed. Otherwise, the property will be set normally (subject to public/protected/private visibility).
	+
	+
	+	===== Benefits =====
	+
	+	This will allow for standard PHP code with property access logic to be written without the need for writing corresponding boilerplate get/set methods up front. Only when non-standard or extra logic needs to be applied to a property during reading or writing would get/set methods for those properties need to be written. This will reduce code size and make it more clear that 'out of the ordinary' logic is happening in the given code.
	+
	+	Also, when dealing with existing classes that are not written with traditional get/set methods for each property, this proposed change would make it easier to add in new functionality without the need for extensive refactoring of code that's using the classes in question. For example, rather than needing to update code such as $calendar->dayOfWeek to be $calendar->getDayOfWeek() in the calling code, the code using the calendar library can remain untouched, and a getDayOfWeek() method can be added to the calendar class, introducing some extra functionality in the calculation of the day of the week (in this example).
	+
	+
	+	===== Changelog =====
	+	Initial draft. Full idea not fleshed out entirely with code examples yet.
	+

automatic_property_initialization

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/02/10 22:01		current
Line 4:		Line 4:
	* Date: 2013-09-27		* Date: 2013-09-27
	* Author: Gordon Oheim, gooh@php.net (patch provided by NikiC, nikic@php.net)		* Author: Gordon Oheim, gooh@php.net (patch provided by NikiC, nikic@php.net)
-	* Status: Under Discussion	+	* Status: Declined
	* First Published at: https://wiki.php.net/rfc/automatic_property_initialization		* First Published at: https://wiki.php.net/rfc/automatic_property_initialization

autovivification_false

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/23 21:11		current
Line 2:		Line 2:
	* Date: 2021-05-25		* Date: 2021-05-25
	* Author: Kamil Tekiela <dharman@php.net>		* Author: Kamil Tekiela <dharman@php.net>
-	* Status: Accepted	+	* Status: Implemented in PHP 8.1
-	* Draft implementation: https://github.com/php/php-src/pull/7131	+	* Implementation: https://github.com/php/php-src/pull/7131
-	* Target Version: PHP 8.1	+

	===== Introduction =====		===== Introduction =====

backslashnamespaces

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/10/25 13:54		current
Line 287:		Line 287:
	* because \ is a single keystroke, it is possible to require \ prefix for all global functions/classes/constants, and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)		* because \ is a single keystroke, it is possible to require \ prefix for all global functions/classes/constants, and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)
	* code review ambiguities disappear permanently		* code review ambiguities disappear permanently
-	* name resolution order problems disappear if we decide that "foo/bar" or "foo::bar" is always prefixed with namespace name, and only short names like "bar()" or "new bar" are checked for both "nsname/bar()" and internal function "bar()" or "class nsname/bar" and internal class "bar". "/foo/bar" is used for global scoping.	+	* name resolution order problems disappear if we decide that "foo\bar" or "foo::bar" is always prefixed with namespace name, and only short names like "bar()" or "new bar" are checked for both "nsname\bar()" and internal function "bar()" or "class nsname\bar" and internal class "bar". "\foo\bar" is used for global scoping.
	* code coverage of namespace-related code is so good, it is possible to be very confident of the correctness of the patch.		* code coverage of namespace-related code is so good, it is possible to be very confident of the correctness of the patch.

backwards_compatibility

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/09/25 01:39		current
Line 49:		Line 49:
	* Class A - At any time.		* Class A - At any time.
	* Class B - Must have have a consensus among developers (normally by RFC/vote).		* Class B - Must have have a consensus among developers (normally by RFC/vote).
-	* Class C - Must pass the some basic tests	+	* Class C - Must pass the some basic tests (voting is essential)
	* Does it affect a number of end users (eyeball / grep various open source projects, PEAR, Syphony, Zend and various CMS / large open source projects)		* Does it affect a number of end users (eyeball / grep various open source projects, PEAR, Syphony, Zend and various CMS / large open source projects)
	* Can a "Forward Compatility workaround" be implemented by end users trivially based on a Depreciation warning.		* Can a "Forward Compatility workaround" be implemented by end users trivially based on a Depreciation warning.

bare_name_array_dereference

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/06/22 00:15		current
Line 3:		Line 3:
	* Date: 2014-06-01		* Date: 2014-06-01
	* Author: Andrea Faulds <ajf@ajf.me>		* Author: Andrea Faulds <ajf@ajf.me>
-	* Status: Under Discussion	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/bare_name_array_dereference		* First Published at: http://wiki.php.net/rfc/bare_name_array_dereference

Line 64:		Line 64:
	===== Vote =====		===== Vote =====

-	A 2/3 majority as it is a language change. Voting began on 2014-06-21 (after a hiccup it was restarted) and ends 2014-06-28.	+	A 2/3 majority as it is a language change. Voting began on 2014-06-21 (after a hiccup it was restarted) and ended 2014-06-28.
-	<doodle title="Merge array dereference into master/PHP 5.7?" auth="user" voteType="single" closed="false">	+	<doodle title="Merge array dereference into master/PHP 5.7?" auth="user" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

bare_name_array_literal

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/06/28 21:25		current
Line 119:		Line 119:

	<code php>		<code php>
-	const('foo', 'bar');	+	const foo = 'bar';
	$arr = [foo: 3];		$arr = [foo: 3];
	// array(1) {		// array(1) {

bare_name_arrays

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/06/01 22:18		current
Line 1:		Line 1:
-	This was a single RFC, but as it contained two proposals, it was split into two RFCs, [[rfc:bare_name_array_literal\|Bare Name Array Literal]] and [[rfc:bare_name_array_literal\|Bare Name Array Dereference]].	+	This was a single RFC, but as it contained two proposals, it was split into two RFCs, [[rfc:bare_name_array_literal\|Bare Name Array Literal]] and [[rfc:bare_name_array_dereference\|Bare Name Array Dereference]].

base_convert_improvements

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/04/12 20:13		current
Line 3:		Line 3:
	* Date: 2019-05-15		* Date: 2019-05-15
	* Author: Scott Dutton,php@exussum.co.uk		* Author: Scott Dutton,php@exussum.co.uk
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.4)
	* First Published at: https://wiki.php.net/rfc/base_convert_improvements		* First Published at: https://wiki.php.net/rfc/base_convert_improvements

base-convert

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/03/12 14:50		current
Line 25:		Line 25:
	* B. Throw a Warning and return FALSE on unexpected characters		* B. Throw a Warning and return FALSE on unexpected characters
	* C. Throw a Warning, stop processing, and return the value up to that point (strtol() behavior)		* C. Throw a Warning, stop processing, and return the value up to that point (strtol() behavior)
		+	* D. Throw an InvalidArgumentException

	===== Targeting Version =====		===== Targeting Version =====

basic_scalar_types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2015-03-11		* Date: 2015-03-11
	* Author: Bob Weinand, bobwei9@hotmail.com		* Author: Bob Weinand, bobwei9@hotmail.com
-	* Status: Inactive (different RFC passed)	+	* Status: Obsolete (different RFC passed)
	* First Published at: http://wiki.php.net/rfc/basic_scalar_types		* First Published at: http://wiki.php.net/rfc/basic_scalar_types
		+
		+	> This proposal has been superseded by [[rfc:scalar_type_hints_v5\|Scalar Type Declarations]], which has been implemented in PHP 7.0.

	===== Introduction =====		===== Introduction =====

batch_use_declarations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/01/29 23:14		current
Line 1:		Line 1:
-	====== PHP RFC: Group Use Declarations ======	+	Moved to https://wiki.php.net/rfc/group_use_declarations
-	* Date: 2015-01-28	+
-	* Author: Márcio Almada, marcio.web2@gmail.com	+
-	* Status: Draft	+
-	* First Published at: http://wiki.php.net/rfc/group_use_declarations	+
-	* Patch: https://github.com/php/php-src/pull/1005	+
-		+
-	===== Introduction =====	+
-	This RFC represents an attempt to improve current PHP namespace implementation by introducing the concept of Group Use Declarations:	+
-		+
-	<code php>	+
-	// Proposed group use syntax:	+
-		+
-	use FooLibrary\Bar\Baz\Biz { ClassA, ClassB, ClassC as Fizbo, ClassD };	+
-		+
-	// Compared to current use syntax:	+
-		+
-	use FooLibrary\Bar\Baz\Biz\ClassA;	+
-	use FooLibrary\Bar\Baz\Biz\ClassB;	+
-	use FooLibrary\Bar\Baz\Biz\ClassC as Fizbo;	+
-	use FooLibrary\Bar\Baz\Biz\ClassD;	+
-	</code>	+
-		+
-	===== Proposal =====	+
-	Group use declarations, also known as grouped imports, are just syntax sugar to cut verbosity when importing multiple entities from a common namespace. Using common PHP library examples, the following use declarations are equivalents:	+
-		+
-	<code php>	+
-	// Current use syntax:	+
-		+
-	use Doctrine\Common\Collections\Expr\Comparison;	+
-	use Doctrine\Common\Collections\Expr\Value;	+
-	use Doctrine\Common\Collections\Expr\CompositeExpression;	+
-		+
-	// Proposed group use syntax:	+
-		+
-	use Doctrine\Common\Collections\Expr { Comparison, Value, CompositeExpression };	+
-	</code>	+
-		+
-	=== Compound Namespaces ===	+
-	Compound namespaces are also allowed. For instance, the following use declarations are equivalents:	+
-		+
-	<code php>	+
-	// Current use syntax:	+
-		+
-	use Symfony\Component\Console\Helper\Table;	+
-	use Symfony\Component\Console\Input\ArrayInput;	+
-	use Symfony\Component\Console\Output\NullOutput;	+
-	use Symfony\Component\Console\Question\Question;	+
-	use Symfony\Component\Console\Input\InputInterface;	+
-	use Symfony\Component\Console\Output\OutputInterface;	+
-	use Symfony\Component\Console\Question\ChoiceQuestion as Choice;	+
-	use Symfony\Component\Console\Question\ConfirmationQuestion;	+
-		+
-	// Proposed group use syntax:	+
-		+
-	use Symfony\Component\Console {	+
-	Helper\Table,	+
-	Input\ArrayInput,	+
-	Input\InputInterface,	+
-	Output\NullOutput,	+
-	Output\OutputInterface,	+
-	Question\Question,	+
-	Question\ChoiceQuestion as Choice,	+
-	Question\ConfirmationQuestion,	+
-	};	+
-	</code>	+
-		+
-	This is also a real use case. Check out the Laravel source code:	+
-		+
-	* [[https://github.com/laravel/framework/blob/5afdac39290bc38d729830190f17581b60b08502/src/Illuminate/Console/Command.php#L3-L10\|https://github.com/laravel/framework/blob/4.2/src/Illuminate/Console/Command.php#L3-L10]]	+
-	* [[https://github.com/laravel/framework/blob/5afdac39290bc38d729830190f17581b60b08502/src/Illuminate/Log/Writer.php#L5-L9\|https://github.com/laravel/framework/blob/4.2/src/Illuminate/Log/Writer.php#L5-L9]]	+
-		+
-	=== Non Mixed Use Declarations ===	+
-	As expected, non mixed group use declarations are supported:	+
-		+
-	<code php>	+
-	// Current use syntax:	+
-		+
-	use function foo\math\sin, foo\math\cos, foo\math\cosh;	+
-	use const foo\math\PI, foo\math\E, foo\math\GAMMA, foo\math\GOLDEN_RATIO;	+
-		+
-	// Proposed non mixed group use syntax:	+
-		+
-	use function foo\math { sin, cos, cosh };	+
-	use const foo\math { PI, E, GAMMA, GOLDEN_RATIO };	+
-	</code>	+
-		+
-	=== Mixed Use Declarations ===	+
-		+
-	The current implementation of namespaces does not allow mixed imports of functions, constants and classes. The proposed implementation would allow mixed imports like this:	+
-		+
-	Current namespace implementation does not allow mixed imports of functions, constants and classes. The proposed implementation would allow mixed imports like this:	+
-		+
-	<code php>	+
-	// Current use syntax:	+
-		+
-	use foo\math\Math;	+
-	use const foo\math\PI;	+
-	use function foo\math\sin, foo\math\cos, foo\math\cosh;	+
-		+
-	// Proposed mixed group use syntax:	+
-		+
-	use foo\math { Math, const PI, function sin, function cos, function cosh };	+
-		+
-	</code>	+
-		+
-	===== Justification =====	+
-		+
-	Group use statements makes it easier to identify that multiple imported entities are from the same module. For the first example in this RFC, instead of having to read 'FooLibrary\Bar\Baz\Biz' four times to see that the namespace is the same for each entry, it is clear by the grouping syntax that the entries all come from the same namespace.	+
-		+
-	Also, group use statements makes it easier to see in patch diffs that a dependency on a new module has been introduced. For instance, a patch that adds a new dependency on "Consolidation" namespace has been introduced:	+
-		+
-	<code>	+
-	use Symfony\Component\Console\Question\ConfirmationQuestion;	+
-	use Symfony\Component\Console\Question\ChoiceQuestion as Choice;	+
-	+use Symfony\Component\Console\Question\OptionQuestion;	+
-	+use Symfony\Component\Consolidation\Question\OptionQuestion;	+
-	use Symfony\Component\Console\Question\Question;	+
-	</code>	+
-		+
-	With the current use syntax it's necessary to read to the 30th character of the 2nd modified line to realise that the patch adds a new dependency. The proposed syntax is much more readable:	+
-		+
-	<code>	+
-	use Symfony\Component\Console\Question {	+
-	ConfirmationQuestion,	+
-	ChoiceQuestion as Choice;	+
-	+ OptionQuestion,	+
-	Question,	+
-	};	+
-	+use Symfony\Component\Consolidation\Question\OptionQuestion;	+
-	</code>	+
-		+
-		+
-	===== About The Syntax Choice =====	+
-	The syntax chosen is inline with the current trait adaptation syntax to make it look and feel similar to existing PHP standards. Such design choice allows the feature to stay familiar and intuitive to most PHP user base.	+
-		+
-	===== Optional: Nested Group Use Declarations =====	+
-	Nesting would allow the following use case:	+
-		+
-	<code php>	+
-	use Symfony\Component\Console {	+
-	Helper\Table,	+
-	Input { ArrayInput, InputInterface }	+
-	Output { NullOutput, OutputInterface },	+
-	Question { Question, ChoiceQuestion, ConfirmationQuestion }	+
-	};	+
-	</code>	+
-		+
-	As the author of this RFC, I consider the nesting option too complex to be introduced. But since many people mentioned this possibility, it will be put into the discussion so the community has a chance to appoint.	+
-		+
-	===== Backward Incompatible Changes =====	+
-	There is no BC breaks with current implementation or feature concepts.	+
-		+
-	===== Proposed PHP Version(s) =====	+
-	This is proposed for the next PHP x, which at the time of this writing would be PHP 7.	+
-		+
-	===== RFC Impact =====	+
-		+
-	=== On Backward Compatibility ===	+
-	This RFC is backwards compatible with previous PHP releases.	+
-		+
-	===== Open Issues =====	+
-	* Should nested group use declarations be allowed?	+
-		+
-	===== Unaffected PHP Functionality =====	+
-	Original namespace implementation is not affected by the addition of group use declarations. Current syntax would still be valid.	+
-		+
-	===== Proposed Voting Choices =====	+
-	As this RFC represents a language change a two third majority is required.	+
-		+
-	===== Patches and Tests =====	+
-	The implementation aims to be minimal and of easy maintenance. I created a PR so that the patch diff can be viewed easily: https://github.com/php/php-src/pull/1005	+
-		+
-	The current initial implementation can be found on my PHP [[https://github.com/marcioAlmada/php-src/tree/group-use\|fork]]. You can also directly contribute to this RFC by sending a pull request to https://github.com/marcioAlmada/RFCs.	+
-		+
-	===== References =====	+
-	There is no found record related to group use declarations on mailing lists.	+
-		+
-	==== Support in other languages ====	+
-	Other languages have similar ways to import multiple entities from a given package or module:	+
-		+
-	* [[http://www.rust-lang.org\|Rust Language]] has a very similar sintax `use a::b::{c,d,e,f};`	+
-	* [[https://www.python.org\|Pyhon]] has a different syntax but with the same objective: `from fibo import fib, fib2, fib3`	+
-		+
-	===== Rejected Features =====	+
-	Awaiting discussion.	+

bcrypt_cost_2023

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/10/05 17:47		current
Line 3:		Line 3:
	* Date: 2023-09-07		* Date: 2023-09-07
	* Author: Tim Düsterhus, timwolla@php.net		* Author: Tim Düsterhus, timwolla@php.net
-	* Status: Accepted	+	* Status: Implemented
		+	* Target Version: PHP 8.4
		+	* Implementation: https://github.com/php/php-src/commit/42a85fc5d95c0c5e867cafcca8ebfca9d90e6c88
	* First Published at: https://wiki.php.net/rfc/bcrypt_cost_2023		* First Published at: https://wiki.php.net/rfc/bcrypt_cost_2023

Line 181:		Line 183:
	===== Patches and Tests =====		===== Patches and Tests =====

-	tbd	+	https://github.com/php/php-src/pull/12367

	===== Implementation =====		===== Implementation =====

-	tbd	+	https://github.com/php/php-src/commit/42a85fc5d95c0c5e867cafcca8ebfca9d90e6c88

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

better_benchmarks

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/07/20 13:09		current
Line 208:		Line 208:
	* crypto-md5 (29.06.2009)		* crypto-md5 (29.06.2009)
	* richards (29.06.2009)		* richards (29.06.2009)
		+	* Crypto-AES

	===== Still unfinished =====		===== Still unfinished =====

better_type_names_for_int64

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/08/22 10:54		current
Line 21:		Line 21:
	* There now exists a ''zend_int_t'' type (which is a 64bit-on-64bit type) and ''zend_int'' (which is a 32bit type). Apart from the ''_t'' suffix the name is the same, but the meaning is totally different.		* There now exists a ''zend_int_t'' type (which is a 64bit-on-64bit type) and ''zend_int'' (which is a 32bit type). Apart from the ''_t'' suffix the name is the same, but the meaning is totally different.
	* PHP and the Zend Engine do not use ''_t'' suffixes for types. This introduces a new type naming convention that is not used anywhere else. (Probably this is done to avoid clashing with the previous point.)		* PHP and the Zend Engine do not use ''_t'' suffixes for types. This introduces a new type naming convention that is not used anywhere else. (Probably this is done to avoid clashing with the previous point.)
-	* Using the term ''int'' for an 64bit type goes against the normal expectations of a C programmer (ILP64 systems are very rare). The meaning of the ''zend_int_t'' type is much closer to the ''long'' type.	+	* Furthermore all types ending in ''_t'' are reserved by the POSIX standard.
		+	* Using the term ''int'' for an 64bit type goes against the normal expectations of a C programmer (ILP64 systems are rare). The meaning of the ''zend_int_t'' type is much closer to the ''long'' type.

	Instead the following alternative naming is proposed:		Instead the following alternative naming is proposed:

bigint

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/02/15 13:58		current
Line 3:		Line 3:
	* Date: 2014-06-20 (Initial Draft; Put Under Discussion 2014-10-10, Last updated 2015-02-15)		* Date: 2014-06-20 (Initial Draft; Put Under Discussion 2014-10-10, Last updated 2015-02-15)
	* Author: Andrea Faulds, ajf@ajf.me		* Author: Andrea Faulds, ajf@ajf.me
-	* Status: Voting	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/bigint		* First Published at: http://wiki.php.net/rfc/bigint

Line 224:		Line 224:
	As this is a language change (it affects the language specification), this requires a 2/3 majority. It is straight Yes/No vote to accepting the RFC.		As this is a language change (it affects the language specification), this requires a 2/3 majority. It is straight Yes/No vote to accepting the RFC.

-	Voting started on 2015-02-15 and ends 10 days later on 2015-02-25.	+	Voting started on 2015-02-15 and was to end 10 days later on 2015-02-25, but voting was cancelled the same day it started.

-	<doodle title="Big Integer Support RFC" auth="ajf" voteType="single" closed="false">	+	<doodle title="Big Integer Support RFC" auth="ajf" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

binary_string_comparison

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/08/17 20:04		current
Line 3:		Line 3:
	* Date: 2014-08-01, internals on 2014-08-17		* Date: 2014-08-01, internals on 2014-08-17
	* Author: Marc Bennewitz, php@mabe.berlin		* Author: Marc Bennewitz, php@mabe.berlin
-	* Status: Draft	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/binary_string_comparison		* First Published at: http://wiki.php.net/rfc/binary_string_comparison

Line 33:		Line 33:

	=== string == string ===		=== string == string ===
-	(http://3v4l.org/4KA8M)	+	(http://3v4l.org/2bIUj)

	<?php		<?php
	echo ('1' == '1' ? 'true' : 'false') . " ('1' == '1')\n";		echo ('1' == '1' ? 'true' : 'false') . " ('1' == '1')\n";
	echo ('2' == '1' ? 'true' : 'false') . " ('2' == '1')\n";		echo ('2' == '1' ? 'true' : 'false') . " ('2' == '1')\n";
		+	echo ('0' == '0x0' ? 'true' : 'false') . " ('0' == '0x0')\n";
		+	echo ('0' == '00' ? 'true' : 'false') . " ('0' == '00')\n";
	echo ('1e1' == '10' ? 'true' : 'false') . " ('1e1' == '10')\n";		echo ('1e1' == '10' ? 'true' : 'false') . " ('1e1' == '10')\n";
	echo ('1E1' == '10' ? 'true' : 'false') . " ('1E1' == '10')\n";		echo ('1E1' == '10' ? 'true' : 'false') . " ('1E1' == '10')\n";
Line 53:		Line 55:
	true ('1' == '1')		true ('1' == '1')
	false ('2' == '1')		false ('2' == '1')
		+	true ('0' == '0x0')
		+	true ('0' == '00')
	true ('1e1' == '10')		true ('1e1' == '10')
	true ('1E1' == '10')		true ('1E1' == '10')
Line 68:		Line 72:
	true ('1' == '1')		true ('1' == '1')
	false ('2' == '1')		false ('2' == '1')
		+	false ('0' == '0x0')
		+	false ('0' == '00')
	false ('1e1' == '10')		false ('1e1' == '10')
	false ('1E1' == '10')		false ('1E1' == '10')

binary_string_deprecation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/02/20 20:02		current
Line 67:		Line 67:
	* Implementation: [[https://github.com/php/php-src/pull/2322]]		* Implementation: [[https://github.com/php/php-src/pull/2322]]
	* Language Specification: [[https://github.com/php/php-langspec/pull/188]]		* Language Specification: [[https://github.com/php/php-langspec/pull/188]]
-	* Documentation: [[https://edit.php.net/?patch=en/language/types/type-juggling.xml&project=PHP]]	+	* Documentation: //Patch was deleted. It removed the mention of the prefix from the type-juggling page.//

	===== References =====		===== References =====
	This deprecation is also proposed in [[rfc:deprecations_php_7_2\|PHP RFC: Deprecations for PHP 7.2]]. The reason for a separate RFC is the impact on the PHAR extension.		This deprecation is also proposed in [[rfc:deprecations_php_7_2\|PHP RFC: Deprecations for PHP 7.2]]. The reason for a separate RFC is the impact on the PHAR extension.

binnotation4ints

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/08/06 11:09		current
Line 3:		Line 3:
	* Date: 2010-11-11		* Date: 2010-11-11
	* Author: Jonah H. Harris <jonah.harris@gmail.com> / <jonah.harris@myyearbook.com>		* Author: Jonah H. Harris <jonah.harris@gmail.com> / <jonah.harris@myyearbook.com>
-	* Status: Implemented	+	* Status: Implemented in 5.4

	===== Introduction =====		===== Introduction =====

blake3_support

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2025/01/24 10:06		current
Line 1:		Line 1:
-	====== PHP RFC: Integrating BLAKE3 into PHP ======	+	sorry wrong url, goto http://wiki.php.net/rfc/blake3
-		+
-	Version: 0.1	+
-		+
-	Date: 2025-01-24	+
-		+
-	Author: Hans Henrik Bergan, hans@loltek.net	+
-		+
-	Status: Draft	+
-		+
-	First Published at: http://wiki.php.net/rfc/blake3	+
-		+
-	===== Introduction =====	+
-		+
-	BLAKE3 is a cryptographic hash function based on the SHA3-finalist BLAKE, offering SHA3-256-like security at much higher speed. Benchmarks from /ext/hash/bench.php highlight BLAKE3's performance: it is over four times faster than SHA3-256 on AMD Ryzen 9 7950x, with BLAKE3 completing bench.php in 0.007752 seconds versus SHA3-256's 0.031518 seconds.	+
-	/ext/hash/bench.php chart on AMD Ryzen 9 7950x, excluding non-cryptographic hashes:	+
-		+
-	{{:rfc:output_5_.png?\|}}	+
-		+
-	And here is a chart from the BLAKE3 developers:	+
-		+
-	{{ :rfc:speed.svg \|}}	+
-		+
-	This RFC proposes adding BLAKE3 support to PHP, offering performance and security assurance to developers requiring hashing functionality.	+
-		+
-	===== Proposal =====	+
-		+
-	The proposal is to integrate BLAKE3 into PHP as a supported algorithm in the ext/hash extension. Developers will be able to use the familiar hash() function and related APIs to compute BLAKE3 hashes.	+
-		+
-	Example usage:	+
-		+
-	<code php>	+
-	<?php	+
-	// Compute a BLAKE3 hash	+
-	$hash = hash('blake3', 'The quick brown fox jumps over the lazy dog');	+
-	echo $hash, PHP_EOL; // 2f1514181aadccd913abd94cfa592701a5686ab23f8df1dff1b74710febc6d4a	+
-		+
-	// Compute a keyed BLAKE3 hash	+
-	$key = 'secret-key';	+
-	$hash_keyed = hash_hmac('blake3', 'The quick brown fox jumps over the lazy dog', $key);	+
-	echo $hash_keyed, PHP_EOL;	+
-	?>	+
-	</code>	+
-	The integration will include:	+
-		+
-	Support for the blake3 algorithm in the hash() function.	+
-		+
-	Support for keyed hashing (HMAC) with hash_hmac().	+
-		+
-	Updated documentation for ext/hash to include examples and usage of BLAKE3.	+
-		+
-	===== Backward Incompatible Changes =====	+
-		+
-	No backward-incompatible changes are introduced by this RFC. The addition of BLAKE3 is purely additive and does not modify existing functionality.	+
-		+
-	===== Proposed PHP Version(s) =====	+
-		+
-	This feature is proposed for inclusion in the next PHP 8.x release.	+
-		+
-	===== RFC Impact =====	+
-		+
-	==== To SAPIs ====	+
-		+
-	No impact is expected on CLI, Development web server, or embedded PHP.	+
-		+
-	==== To Existing Extensions ====	+
-		+
-	The ext/hash extension will be updated to include BLAKE3. This change will not affect other extensions.	+
-		+
-	==== To Opcache ====	+
-		+
-	There is no expected impact on Opcache.	+
-		+
-	==== New Constants ====	+
-		+
-	No new constants are introduced.	+
-		+
-	==== php.ini Defaults ====	+
-		+
-	No new php.ini settings are required for this feature.	+
-		+
-	===== Open Issues =====	+
-		+
-	There are currently no open issues related to this RFC.	+
-		+
-	===== Unaffected PHP Functionality =====	+
-		+
-	This RFC does not impact existing hashing algorithms or functionality in PHP.	+
-		+
-	===== Future Scope =====	+
-		+
-	Future enhancements to BLAKE3 support could include:	+
-		+
-	* Multi-threaded hashing for even greater performance on large inputs. There is no multithreading support in the current ext/hash apis.	+
-	* Support for extended output modes of BLAKE3 (e.g., XOF functionality). There is no XOF support in the current ext/hash apis.	+
-		+
-	===== Proposed Voting Choices =====	+
-		+
-	The voting choices for this RFC are:	+
-		+
-	Accept BLAKE3 support in PHP.	+
-		+
-	Decline BLAKE3 support in PHP.	+
-		+
-	===== Patches and Tests =====	+
-		+
-	The implementation is available as a pull request at https://github.com/php/php-src/pull/13194. Tests have been included as part of the pull request, ensuring the correctness and reliability of the implementation.	+
-		+
-	===== Implementation =====	+
-		+
-	After approval, this section will include:	+
-		+
-	The version(s) the feature was merged into.	+
-		+
-	A link to the git commit(s).	+
-		+
-	A link to the PHP manual entry for the feature.	+
-		+
-	===== References =====	+
-		+
-	BLAKE3 Official Website: [[https://blake3.io/]]	+
-		+
-	BLAKE3 Specification: [[https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf]]	+
-		+
-	PHP Pull Request for BLAKE3 Support: [[https://github.com/php/php-src/pull/13194]]	+
-		+
-	===== Rejected Features =====	+
-		+
-	No features have been rejected during the discussion of this RFC.	+

blake3

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2025/01/24 21:35		current
Line 12:		Line 12:

	===== Introduction =====		===== Introduction =====
		+
		+	TL;DR: Essentially, BLAKE3 provides SHA3-256–level security at considerably higher throughput.

	BLAKE3 is a cryptographic hash function based on the SHA3-finalist BLAKE, offering SHA3-256-like security at much higher speed. Benchmarks from /ext/hash/bench.php highlight BLAKE3's performance: it is over four times faster than SHA3-256 on AMD Ryzen 9 7950x, with BLAKE3 completing bench.php in 0.007752 seconds versus SHA3-256's 0.031518 seconds.		BLAKE3 is a cryptographic hash function based on the SHA3-finalist BLAKE, offering SHA3-256-like security at much higher speed. Benchmarks from /ext/hash/bench.php highlight BLAKE3's performance: it is over four times faster than SHA3-256 on AMD Ryzen 9 7950x, with BLAKE3 completing bench.php in 0.007752 seconds versus SHA3-256's 0.031518 seconds.

boxingandunboxing

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/07/06 16:18		current
Line 17:		Line 17:
	The most obvious use for boxing is function and method type hints. The object type hints could be used to do implicit boxing of variables. Either a new magic method (''<nowiki>__</nowiki>box'' for example) or a new interface (''Boxable'' for example) would need to be added to PHP. The boxing method would accept the scalar value and set its internal representation (similar to ''<nowiki>__</nowiki>wakeup''). The method could either return false (and let PHP handle the failure) or throw an exception (''BoxingException'' for example) when the supplied value is not valid for the boxing operation.		The most obvious use for boxing is function and method type hints. The object type hints could be used to do implicit boxing of variables. Either a new magic method (''<nowiki>__</nowiki>box'' for example) or a new interface (''Boxable'' for example) would need to be added to PHP. The boxing method would accept the scalar value and set its internal representation (similar to ''<nowiki>__</nowiki>wakeup''). The method could either return false (and let PHP handle the failure) or throw an exception (''BoxingException'' for example) when the supplied value is not valid for the boxing operation.

-	It would be best for PHP to include as many object versions of scalar types as possible. The boxing functionality could be added to the SPL Types (([[http://.php.net/manual/en/book.spl-types.php\|SPL Types]])) to provide for standard representations of the scalar types. The power to box variables would also be available in userland classes.	+	It would be best for PHP to include as many object versions of scalar types as possible. The boxing functionality could be added to the SPL Types (([[http://php.net/manual/en/book.spl-types.php\|SPL Types]])) to provide for standard representations of the scalar types. The power to box variables would also be available in userland classes.

	It could also be possible to try to perform implicit conversions from one object type to another, but the overhead of this feature may be too much. Consider it as an option only.		It could also be possible to try to perform implicit conversions from one object type to another, but the overhead of this feature may be too much. Consider it as an option only.

build-openssl-by-default

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/02/03 05:01		current
Line 9:		Line 9:
	===== Introduction =====		===== Introduction =====

-	Security matters almost all applications. PHP needs ability handle cryptography by default.	+	Security matters almost all applications. PHP needs ability to handle cryptography by default.

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

builtincrypt

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/03/24 17:31		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: Prefer PHP's Builtin Crypt over System versions ======
	* Version: 1.0		* Version: 1.0
	* Date: 2010-03-18		* Date: 2010-03-18

builtinwebserver

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/08/06 19:27		current
Line 3:		Line 3:
	* Date: 2011-06-020		* Date: 2011-06-020
	* Author: Moriyoshi Koizumi <moriyoshi.at.php.net>		* Author: Moriyoshi Koizumi <moriyoshi.at.php.net>
-	* Status: Implemented	+	* Status: Implemented in 5.4
	* First Published at: http://wiki.php.net/rfc/builtinwebserver		* First Published at: http://wiki.php.net/rfc/builtinwebserver
	* Other formats ..		* Other formats ..

cachediterable_straw_poll

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/05 18:27		current
Line 3:		Line 3:
	* Date: 2021-06-01		* Date: 2021-06-01
	* Author: Tyson Andre, <tandre@php.net>		* Author: Tyson Andre, <tandre@php.net>
-	* Status: Voting	+	* Status: Closed
	* First Published at: https://wiki.php.net/rfc/cachediterable_straw_poll		* First Published at: https://wiki.php.net/rfc/cachediterable_straw_poll

Line 54:		Line 54:
	(No namespace alternatives were suggested between announcing the straw poll and opening the straw poll in https://externals.io/message/114687#114687)		(No namespace alternatives were suggested between announcing the straw poll and opening the straw poll in https://externals.io/message/114687#114687)

-	<doodle title="Preferred namespacing choice for CachedIterable" auth="tandre" votetype="multi" closed="false">	+	<doodle title="Preferred namespacing choice for CachedIterable" auth="tandre" votetype="multi" closed="true">
	* Iterable\CachedIterable		* Iterable\CachedIterable
	* CachedIterable		* CachedIterable
Line 67:		Line 67:
	Preferred namespacing choice for successors to the [[rfc:any_all_on_iterable\|any() and all() on iterables]] RFC: [[https://github.com/php/php-src/pull/6053\|any()/all()/none()/find()/reduce()]]		Preferred namespacing choice for successors to the [[rfc:any_all_on_iterable\|any() and all() on iterables]] RFC: [[https://github.com/php/php-src/pull/6053\|any()/all()/none()/find()/reduce()]]

-	<doodle title="Preferred namespacing choice for any()/all()/none()/reduce()/find()" auth="tandre" votetype="multi" closed="false">	+	<doodle title="Preferred namespacing choice for any()/all()/none()/reduce()/find()" auth="tandre" votetype="multi" closed="true">
	* Iterable\any()		* Iterable\any()
	* iterable_any()		* iterable_any()
Line 86:		Line 86:
	("Still too small in scope" means you would probably vote against the implementation as-is for that reason)		("Still too small in scope" means you would probably vote against the implementation as-is for that reason)

-	<doodle title="Global functions I would want to add to PHP to act on iterables as described in implementation link" auth="tandre" votetype="multi" closed="false">	+	<doodle title="Global functions I would want to add to PHP to act on iterables as described in implementation link" auth="tandre" votetype="multi" closed="true">
	* any(...)/all(iterable $input, $callback = null): bool		* any(...)/all(iterable $input, $callback = null): bool
	* none(...): bool		* none(...): bool
Line 123:		Line 123:
	(Aside: shorter namespace names such as iter were unpopular in a [[rfc:any_all_on_iterable_straw_poll_namespace\|previous straw poll]], and iter would conflict with https://github.com/nikic/iter)		(Aside: shorter namespace names such as iter were unpopular in a [[rfc:any_all_on_iterable_straw_poll_namespace\|previous straw poll]], and iter would conflict with https://github.com/nikic/iter)

-	<doodle title="Preferred namespacing for iterable\" auth="tandre" votetype="single" closed="false">	+	<doodle title="Preferred namespacing for iterable\" auth="tandre" votetype="single" closed="true">
	* iterable\ (lowercase)		* iterable\ (lowercase)
	* Iterable\ (CamelCase)		* Iterable\ (CamelCase)

cachediterable

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/17 02:37		current
Line 3:		Line 3:
	* Date: 2021-02-06		* Date: 2021-02-06
	* Author: Tyson Andre, tandre@php.net		* Author: Tyson Andre, tandre@php.net
-	* Status: Voting	+	* Status: Declined
	* Implementation: https://github.com/php/php-src/pull/6655		* Implementation: https://github.com/php/php-src/pull/6655
	* First Published at: https://wiki.php.net/rfc/cachediterable		* First Published at: https://wiki.php.net/rfc/cachediterable
Line 349:		Line 349:
	This is a Yes/No vote, requiring a 2/3 majority. Voting started on June 15, 2021 and ends on June 29, 2021.		This is a Yes/No vote, requiring a 2/3 majority. Voting started on June 15, 2021 and ends on June 29, 2021.

-	<doodle title="Add ImmutableIterable to core" auth="tandre" voteType="single" closed="false">	+	<doodle title="Add ImmutableIterable to core" auth="tandre" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 356:		Line 356:
	==== Poll: Reason for voting against this RFC ====		==== Poll: Reason for voting against this RFC ====

-	<doodle title="Reasons for voting against the ImmutableIterable RFC" auth="tandre" voteType="multi" closed="false">	+	<doodle title="Reasons for voting against the ImmutableIterable RFC" auth="tandre" voteType="multi" closed="true">
	* Object to the namespace choice		* Object to the namespace choice
	* Object to the name		* Object to the name

callable-interfaces

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/04/06 12:00		current
Line 4:		Line 4:
	* Author: Ben Scholzen, mail@dasprids.de		* Author: Ben Scholzen, mail@dasprids.de
	* Author: Marco Pivetta, ocramius@gmail.com		* Author: Marco Pivetta, ocramius@gmail.com
-	* Status: Draft	+	* Status: Retired
	* First Published at: http://wiki.php.net/rfc/callable-interfaces		* First Published at: http://wiki.php.net/rfc/callable-interfaces

Line 129:		Line 129:
	var_dump($register instanceof DeleteUserRegistration); // true? false? possibly want to keep current semantics here.		var_dump($register instanceof DeleteUserRegistration); // true? false? possibly want to keep current semantics here.
	</code>		</code>
		+
		+	===== Retired =====
		+
		+	This RFC has been retired. Reason for that is that PHP currently (Version 7.0~7.1) allows applying function semantics to objects via the __invoke magic methods. Allowing the opposite would mix the domain of functions and objects in ways that are very hard to disentangle, and it would needlessly complicate the language semantics.
		+
		+	While it is unfortunate that migration to type-safe callables (https://wiki.php.net/rfc/typesafe-callable) would require some interface rewrites, that is indeed the correct solution, as it keeps the uni-directionality between object and function semantics.

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

callable-types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/06/06 21:22		current
Line 3:		Line 3:
	* Date: 2015-08-27		* Date: 2015-08-27
	* Authors: Nikita Nefedov <inefedor@gmail.com>, Márcio Almada <marcio3w@gmail.com>		* Authors: Nikita Nefedov <inefedor@gmail.com>, Márcio Almada <marcio3w@gmail.com>
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/callable-types		* First Published at: http://wiki.php.net/rfc/callable-types

callable

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/07/27 09:05		current
Line 3:		Line 3:
	* Date: 2011-06-07		* Date: 2011-06-07
	* Author: Hannes Magnusson <bjori@php.net>		* Author: Hannes Magnusson <bjori@php.net>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.4
	* First Published at: http://wiki.php.net/rfc/callable		* First Published at: http://wiki.php.net/rfc/callable

callableconstructors

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/02/25 16:45		current
Line 146:		Line 146:

	class A {		class A {
-	public function %%__%%construct() {	+	public function __construct() {
	return "Why would you even do this.";		return "Why would you even do this.";
	}		}

	public function foo() {		public function foo() {
-	$fn = [self::class, '%%__%%construct'];	+	$fn = [self::class, '__construct'];
	// Calling directly as a callable like:		// Calling directly as a callable like:
	// $result = $fn();		// $result = $fn();
	// Correctly fails with the error message:		// Correctly fails with the error message:
-	// Error: Non-static method A::%%__%%construct() cannot be called statically	+	// Error: Non-static method A::__construct() cannot be called statically

	// However calling with 'call user function', is erroneously allowed.		// However calling with 'call user function', is erroneously allowed.

calls_in_constant_expressions_poll

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/02/19 17:54		current
Line 3:		Line 3:
	* Date: 2020-02-16		* Date: 2020-02-16
	* Author: Tyson Andre, tandre@php.net		* Author: Tyson Andre, tandre@php.net
-	* Status: Voting (ends 2020-03-04)	+	* Status: Closed (ends 2020-03-04)
	* First Published at: https://wiki.php.net/rfc/calls_in_constant_expressions_poll		* First Published at: https://wiki.php.net/rfc/calls_in_constant_expressions_poll

Line 48:		Line 48:
	Voting ends March 4th, 2020.		Voting ends March 4th, 2020.

-	<doodle title="Support calls in class constants" auth="tandre" voteType="single" closed="false">	+	<doodle title="Support calls in class constants" auth="tandre" voteType="single" closed="true">
	* No		* No
	* Whitelist of global functions		* Whitelist of global functions
Line 54:		Line 54:
	</doodle>		</doodle>
	.		.
-	<doodle title="Support calls in global constants" auth="tandre" voteType="single" closed="false">	+	<doodle title="Support calls in global constants" auth="tandre" voteType="single" closed="true">
	* No		* No
	* Whitelist of global functions		* Whitelist of global functions
Line 66:		Line 66:
	* ''function($x) { return $x*$x; }''		* ''function($x) { return $x*$x; }''

-	<doodle title="Support calls in static property declarations" auth="tandre" voteType="single" closed="false">	+	<doodle title="Support calls in static property declarations" auth="tandre" voteType="single" closed="true">
	* No		* No
	* Whitelist of global functions		* Whitelist of global functions
Line 73:		Line 73:
	</doodle>		</doodle>
	.		.
-	<doodle title="Support calls in static variables" auth="tandre" voteType="single" closed="false">	+	<doodle title="Support calls in static variables" auth="tandre" voteType="single" closed="true">
	* No		* No
	* Whitelist of global functions		* Whitelist of global functions
Line 82:		Line 82:
	.		.

-	<doodle title="Support calls in parameter defaults" auth="tandre" voteType="single" closed="false">	+	<doodle title="Support calls in parameter defaults" auth="tandre" voteType="single" closed="true">
	* No		* No
	* Whitelist of global functions		* Whitelist of global functions

calls_in_constant_expressions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/03/04 13:56		current
Line 250:		Line 250:

	Primary vote: Allow calling global functions that are in the described whitelist (Yes/No, Requires 2/3 majority)		Primary vote: Allow calling global functions that are in the described whitelist (Yes/No, Requires 2/3 majority)
		+
		+	Also see [[https://externals.io/message/108630\|Straw poll: Places to allow function calls in constant expressions]]

	===== Patches and Tests =====		===== Patches and Tests =====
Line 259:		Line 261:
	===== References =====		===== References =====
	[[https://externals.io/message/108343\|Planning an RFC to allow calls to global functions in constant expressions]]		[[https://externals.io/message/108343\|Planning an RFC to allow calls to global functions in constant expressions]]
		+
		+	[[https://externals.io/message/108630\|Straw poll: Places to allow function calls in constant expressions]]
		+
	https://wiki.php.net/rfc/calls_in_constant_expressions_poll		https://wiki.php.net/rfc/calls_in_constant_expressions_poll

calltimebyref

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2008-05-21		* Date: 2008-05-21
	* Author: Steph Fox <sfox@php.net>		* Author: Steph Fox <sfox@php.net>
-	* Status: Under Discussion	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/calltimebyref		* First Published at: http://wiki.php.net/rfc/calltimebyref

Line 51:		Line 51:
	- [3] [[http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.676&r2=1.677]]		- [3] [[http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.676&r2=1.677]]

-		+	==== Comments ====
		+	currently allow_call_time_pass_reference is set to Off in both php.ini-production and php.ini-development for 5.3, and Call-time pass-by-reference was removed from 5.4, so this RFC is implemented/obsolete.

case_insensitive_constant_deprecation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/07/16 16:56		current
Line 2:		Line 2:
	* Date: 2018-06-24		* Date: 2018-06-24
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Target PHP version: PHP 7.3
	* Implementation: https://github.com/php/php-src/pull/3321		* Implementation: https://github.com/php/php-src/pull/3321
	* Discussion: https://externals.io/message/102389		* Discussion: https://externals.io/message/102389
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.3)

	===== Introduction =====		===== Introduction =====

case-sensitivity

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2014-12-26		* Date: 2014-12-26
	* Author: François Laupretre, francois@tekwire.net		* Author: François Laupretre, francois@tekwire.net
-	* Status: Draft	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/case-sensitivity		* First Published at: http://wiki.php.net/rfc/case-sensitivity

catchable-call-to-member-of-non-object

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/07/31 15:21		current
Line 6:		Line 6:
	* Status: Accepted		* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/catchable-call-to-member-of-non-object		* First Published at: https://wiki.php.net/rfc/catchable-call-to-member-of-non-object
		+
		+	Note: This RFC has been superseded by the [[https://wiki.php.net/rfc/engine_exceptions_for_php7\|engine exceptions]] proposal.

	===== Introduction =====		===== Introduction =====

chaining_comparison

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 4:		Line 4:
	* Author: David Walker (dave@mudsite.com)		* Author: David Walker (dave@mudsite.com)
	* Author: Richard Fussenegger (php@fleshgrinder.com)		* Author: Richard Fussenegger (php@fleshgrinder.com)
-	* Status: Draft	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/chaining_comparison		* First Published at: http://wiki.php.net/rfc/chaining_comparison

change_required_votes_to_two_thirds

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/11/19 19:29		current
Line 9:		Line 9:
	This RFC proposes that the rule for the required percentage of votes than an RFC needs to pass be simplified to always require 2/3 in favor of the RFC. I request that RFCs which currently can request 1/2 + 1 votes do not enter the voting stage until this is decided, on the grounds that if the requirements for what an RFC needs to pass are under debate then no affected RFCs should proceed to that stage.		This RFC proposes that the rule for the required percentage of votes than an RFC needs to pass be simplified to always require 2/3 in favor of the RFC. I request that RFCs which currently can request 1/2 + 1 votes do not enter the voting stage until this is decided, on the grounds that if the requirements for what an RFC needs to pass are under debate then no affected RFCs should proceed to that stage.

		+	===== Motivation =====
	Motivations for requiring 2/3 of the votes or more for an RFC to pass:		Motivations for requiring 2/3 of the votes or more for an RFC to pass:

change_the_edge_case_of_round

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/11/24 00:29		current
Line 3:		Line 3:
	* Date: 2023-10-23		* Date: 2023-10-23
	* Author: Saki Takamachi, saki@sakiot.com		* Author: Saki Takamachi, saki@sakiot.com
-	* Status: Voting	+	* Status: Declined
	* First Published at: https://wiki.php.net/rfc/change_the_edge_case_of_round		* First Published at: https://wiki.php.net/rfc/change_the_edge_case_of_round

change-terminology-to-allowlist-and-blocklist

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/06/16 12:08		current
Line 3:		Line 3:
	* Date: 2020-06-09		* Date: 2020-06-09
	* Author: Michał Marcin Brzuchalski <brzuchal@php.net>		* Author: Michał Marcin Brzuchalski <brzuchal@php.net>
-	* Status: Under Discussion	+	* Status: Draft
	* Target Version: PHP 8.0		* Target Version: PHP 8.0
-	* First Published at: http://wiki.php.net/rfc/change-terminology-to-allowlist-and-blocklist	+	* First Published at: https://wiki.php.net/rfc/change-terminology-to-excludelist

	Change the use of "blacklist" in Opcache configuration with better self-descriptive terminology.		Change the use of "blacklist" in Opcache configuration with better self-descriptive terminology.

change-terminology-to-excludelist

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Change terminology to ExcludeList ======
	+	* Version: 0.9
	+	* Date: 2020-06-09
	+	* Author: Michał Marcin Brzuchalski <brzuchal@php.net>
	+	* Status: Under Discussion
	+	* Target Version: PHP 8.0
	+	* First Published at: http://wiki.php.net/rfc/change-terminology-to-excludelist
	+
	+	Change the use of "blacklist" in Opcache configuration with better self-descriptive terminology.
	+
	+	===== Introduction =====
	+	The word "blacklist" require additional context to figure out the exact intention of a specific
	+	configuration. This proposal suggest to change this to a name that better reflects what the functionality does.
	+
	+	===== Proposal =====
	+	The proposal is to replace all occurrences of "blacklist" to the alternative "exclude_list".
	+
	+	A list of Open Source projects with similar terminology change is listed in [[https://wiki.php.net/rfc/change-terminology-to-allowlist-and-blocklist#references\|references]] section. There is also a draft [[https://tools.ietf.org/id/draft-knodel-terminology-00.html\|IETF document]].
	+
	+	==== Change INI directive name ====
	+	A new INI directive called ''opcache.exclude_list_filename'' will be introduced and will configure the same internal value as the already existing ''opcache.blacklist_filename''.
	+
	+	The INI directive called ''opcache.blacklist_filename'' will remain as is but with additional soft-deprecation in the docs and
	+	in ''php.ini-development'' and ''php.ini-production''.
	+
	+	==== Change in opcache_get_configuration function ====
	+	The ''opcache_get_configuration()'' function currently returns an associative array with information about Opcache.
	+	A new key named ''exclude_list'' will be added to resulting array with the same value as the original ''blacklist''
	+	key which will remain untouched with additional soft-deprecation in the docs.
	+
	+
	+	===== Backward Incompatible Changes =====
	+	Most of the changes are internal only with two exceptions for which this patch requires RFC:
	+
	+	- The new ''opcache.exclude_list_filename'' INI directive
	+	- An extra ''exclude_list'' key in the returned array value of ''opcache_get_configuration()''
	+
	+	Whether the use of the ''opcache.blacklist_filename'' INI directive triggers a deprecation notice is a subject to a secondary vote.
	+
	+	===== Proposed PHP Version(s) =====
	+	Next PHP version 8.0.
	+
	+	===== RFC Impact =====
	+	==== To SAPIs ====
	+	None.
	+
	+	==== To Existing Extensions ====
	+	Only in Opcache.
	+
	+	==== To Opcache ====
	+	This proposal modifies Opcache structure and function names by replacing "blacklist" with "exclude_list".
	+
	+	==== php.ini Defaults ====
	+
	+	* php.ini-development changed name of ''opcache.blacklist_filename'' into ''opcache.exclude_list_filename''
	+	* php.ini-production changed name of ''opcache.blacklist_filename'' into ''opcache.exclude__filename''
	+
	+	===== Future scope =====
	+	The possibility to remove ''opcache.blacklist_filename'' INI directive and ''opcache_get_configuration()["exclude_list"]'' in the next
	+	minor PHP version: 8.1.
	+
	+	===== Proposed Voting Choices =====
	+	Accept changing terminology in PHP 8.0? Yes/No with 2/3 majority required.
	+	Add deprecation notice when deprecated INI directive used? Yes/No
	+
	+	===== Implementation =====
	+	- [[https://github.com/php/php-src/pull/5685]]
	+
	+	===== References =====
	+	- [[https://github.com/sebastianbergmann/phpunit/blob/master/ChangeLog-9.3.md#930---2020-08-07\|PHPUnit]]
	+	- [[https://github.com/xdebug/xdebug/commit/63b43b51e43b794cf8cd740e54089b2b7320fbe1\|Xdebug]]
	+	- [[https://www.drupal.org/project/drupal/issues/2993575\|Drupal]]
	+	- [[https://gitlab.com/gitlab-org/gitlab/-/issues/7554\|Gitlab]]
	+	- [[https://go-review.googlesource.com/c/go/+/236857/\|GoLang]]
	+	- [[https://github.com/rails/rails/issues/33677\|RoR]]
	+	- [[https://github.com/rubocop-hq/rubocop/pull/7469\|Ruby Static Analyser]]

changes_to_include_and_require

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/03/08 16:01		current
Line 30:		Line 30:

	This provides a powerful layer of flexibility for frameworks. It also allows a tyro to whack their foot off and spaghetti doesn't even begin to describe the situation that will occur if this gets used incorrectly.		This provides a powerful layer of flexibility for frameworks. It also allows a tyro to whack their foot off and spaghetti doesn't even begin to describe the situation that will occur if this gets used incorrectly.
		+
		+	===== Questions =====
		+
		+	1)
		+	Is it not possible that the library being pulled contains references to itself in the original namespace, rather than the new sub-namespace the require/include is forcing upon it?
		+
		+	Or do you anticipate that all such references would be converted?
		+
		+	What if, somehow, the library composes the reference from $data rather than hard-coded? (Which might be kind of crazy, but you know those PHP guys...)
		+
		+	2) Add more questions.

	===== Changelog =====		===== Changelog =====

check_and_set

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/07/06 13:25		current
Line 12:		Line 12:
	`<nowiki>$x += 3</nowiki>`.		`<nowiki>$x += 3</nowiki>`.

-	With PHP being a web focused language, the `?:` operator is often used to check something's existence like `<nowiki>$this->obj = $obj ?: new \stdClass;</nowiki>` However, because	+	With PHP being a web focused language, the `?:` ternary operator is often used to check something's existence like `<nowiki>$this->obj = $obj ?: new \stdClass;</nowiki>` However, because
	variable names are often much longer than `<nowiki>$username</nowiki>`, the use of `<nowiki>?:</nowiki>` for self assignment creates repeated code, like:		variable names are often much longer than `<nowiki>$username</nowiki>`, the use of `<nowiki>?:</nowiki>` for self assignment creates repeated code, like:

Line 19:		Line 19:
	</code>		</code>

-	It is also intuitive to use combined assignment operator null coalesce checking for self assignment.	+	It is also intuitive to use combined assignment operator null ternary checking for self assignment.

	# Proposal		# Proposal

-	Despite `<nowiki>?:</nowiki>` operator being a comparison operator, coalesce equal or `<nowiki>?=</nowiki>` operator is an assignment operator. If the left parameter is null, assigns the value of the right paramater to the left one. If the value is not null, nothing is made.	+	Despite `<nowiki>?:</nowiki>` operator being a comparison operator, ternary equal or `<nowiki>?=</nowiki>` operator is an assignment operator. If the left parameter is null, assigns the value of the right paramater to the left one. If the value is not null, nothing is made.

check-operator

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/12/17 15:26		current
Line 141:		Line 141:
	This has no bearing on the behavior of the ''%%check%%'' operator itself, which only handles ''%%Throwable%%'' values - if the function call with error suppression evaluates to ''null'', that value will pass through as the result of the expression.		This has no bearing on the behavior of the ''%%check%%'' operator itself, which only handles ''%%Throwable%%'' values - if the function call with error suppression evaluates to ''null'', that value will pass through as the result of the expression.

-	==== Impact on error handling ====	+	==== No impact on error handling ====

	The ''%%check%%'' operator is means of generating exceptions, not a means of handling them.		The ''%%check%%'' operator is means of generating exceptions, not a means of handling them.
Line 149:		Line 149:
	Besides potentially generating an implicit ''%%throw%%'', the ''%%check%%'' operator has no influence on the behavior of ''%%try/catch%%'' blocks - exceptions generated by the ''%%check%%'' operator behave exactly like those generated by a ''%%throw%%'' statement.		Besides potentially generating an implicit ''%%throw%%'', the ''%%check%%'' operator has no influence on the behavior of ''%%try/catch%%'' blocks - exceptions generated by the ''%%check%%'' operator behave exactly like those generated by a ''%%throw%%'' statement.

-	Use of the ''%%check%%'' operator also does not interfere with the ''%%set_error_handler%%'' or ''%%set_exception_handler%%''.	+	Use of the ''%%check%%'' operator does not interfere with the ''%%set_error_handler%%'' or ''%%set_exception_handler%%''.
		+
		+	The ''%%check%%'' operator does not interfere with type-hint enforcement - a function that returns something invalid (according to its return type) will trigger an error, as usual.

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

checkdnsrr-default-type

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== Request for Comments: Change checkdnsrr() $type argument behavior ======
	+	* RFC Version: 1.00
	+	* Target PHP Version: 5.7 & 7.0
	+	* Date: 2014-09-19
	+	* Author: Kris Craig <nowiki><</nowiki><kriscraig@php.net><nowiki>></nowiki>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/checkdnsrr-default-type
	+
	+	===== Abstract =====
	+
	+	This RFC proposes that the default behavior of the checkdnsrr() function be changed such that it no longer checks only for MX records by default.
	+
	+	===== Background =====
	+
	+	The checkdnsrr() function is used to check if a given hostname exists. It's essentially PHP's basic DNS lookup function. It returns TRUE if the hostname is found, FALSE otherwise. It accepts 2 arguments, the $host as a string and the record $type as a string. The possible values for $type are: "A", "MX", "NS", "SOA", "PTR", "CNAME", "AAAA", "A6", "SRV", "NAPTR", "TXT", and "ANY". If "ANY", it'll return TRUE regardless of the record type it finds.
	+
	+	===== Current Behavior =====
	+
	+	The $type argument is currently optional and defaults to "MX".
	+
	+	===== The Problem =====
	+
	+	The current behavior is very counter-intuitive because the function is most commonly used for general DNS lookups. In most circumstances, these lookups are not for MX records. As a result, developers who implement this function without noticing the "MX" default in the documentation will have their DNS lookups fail even if the hostname is there. This can lead to a lot of time being wasted triaging what appears to be a DNS issue.
	+
	+	What makes this even more perplexing is the fact that there is already a function dedicated specifically for performing MX record lookups: getmxrr().
	+
	+	There does not appear to be any compelling use case for the default value for PHP's general DNS lookup function being "MX".
	+
	+	===== Solution #1 =====
	+
	+	Change the default value of $type from "MX" to "ANY". This would be implemented in PHP 7.0.
	+
	+	==== Pros ====
	+
	+	This would be the most convenient and intuitive option for developers, as they'd only have to supply the hostname and it would return a general DNS lookup, which is what most people would expect.
	+
	+	==== Cons ====
	+
	+	Though the potential for BC breakage would be the same, this would make it much harder to spot since no error would be generated. Instead, it would just silently fail for anyone expecting the default to be "MX". Concerns have also been raised on Internals that this could be a potential vector for amplification attacks.
	+
	+	===== Solution #2 =====
	+
	+	Make the $type argument required. Starting in PHP 5.7, not including the second argument would cause an E_DEPRECATED to be thrown. Starting in PHP 7.0, it would throw an E_ERROR, causing script execution to abort.
	+
	+	==== Pros ====
	+
	+	For the relatively few instances in which a script is passing only one argument with the expectation that it be checking for "MX", this will make it much easier for devs to spot this BC and adapt their code accordingly. It may also be less susceptible to amplification attacks.
	+
	+	==== Cons ====
	+
	+	The intuitive behavior for virtually any DNS lookup function/utility/etc is for it to accept a hostname and return whether there are any matches. Requiring people to specify a second "ANY" argument would be somewhat cumbersome and may raise complaints from devs who question why the behavior that the overwhelming number of users are looking for is not the default.
	+
	+	===== Final Thoughts =====
	+
	+	This one appears to be pretty much a no-brainer. I believe the much trickier question is whether to change the default or make the argument required. I'm honestly on the fence as far as that goes, so I would encourage everyone with an opinion on this to weigh-in and make their case on Internals.
	+
	+	===== Vote =====
	+
	+	Though this could be reasonably interpreted as language-touching and otherwise, I'll err on the side of caution and require the greater 2/3 majority in order for this RFC to pass. A separate vote will be held simultaneously to determine which solution will be implemented if the RFC passes. Whichever one gets the most votes will win.
	+
	+	===== Changelog =====
	+
	+	Version 1.00 : Initial proposal.

chips

Anonymous (anonymous@undisclosed.example.com) — 2025-08-15T08:51:26+00:00

2025/08/12 20:13		current
Line 3:		Line 3:
	* Date: 2025-07-12		* Date: 2025-07-12
	* Author: Dmitrii Derepko, xepozzd@gmail.com; Niels Dossche, dossche.niels@gmail.com		* Author: Dmitrii Derepko, xepozzd@gmail.com; Niels Dossche, dossche.niels@gmail.com
-	* Status: Accepted	+	* Status: Implemented
-	* Implementation: https://github.com/php/php-src/pull/12652	+	* Implementation: https://github.com/php/php-src/pull/12652 & https://github.com/php/php-src/commit/1bba07ecc065a281ddb3a0ad81c923874882825b

	===== Introduction =====		===== Introduction =====
Line 175:		Line 175:

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

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

clamp_v2

Anonymous (anonymous@undisclosed.example.com) — 2026-03-16T22:54:13+00:00

2026/03/16 22:53		current
Line 3:		Line 3:
	* Date: 2025-08-21		* Date: 2025-08-21
	* Author: kylekatarnls, kylekatarnls@gmail.com		* Author: kylekatarnls, kylekatarnls@gmail.com
-	* Status: Implemented	+	* Status: Implemented in PHP 8.6
	* Implementation: [[https://github.com/php/php-src/pull/19434]]		* Implementation: [[https://github.com/php/php-src/pull/19434]]

clamp

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/07/08 10:49		current
Line 3:		Line 3:
	* Date: 2021-06-23		* Date: 2021-06-23
	* Author: Kim Hallberg, hallbergkim@gmail.com		* Author: Kim Hallberg, hallbergkim@gmail.com
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Proposed Version: PHP 8.2		* Proposed Version: PHP 8.2
	* First Published at: http://wiki.php.net/rfc/clamp		* First Published at: http://wiki.php.net/rfc/clamp

class_and_interface_name_types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/05/05 16:15		current
Line 1:		Line 1:
-	a few a====== PHP RFC: Class name type ======	+	====== PHP RFC: Class name type ======
	* Version: 0.1		* Version: 0.1
	* Date: 2017-04-29		* Date: 2017-04-29

class_casting_to_scalar

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/11/24 12:28		current
Line 39:		Line 39:

	* None yet		* None yet
		+
		+	==== Bugs ====
		+
		+	* When used with math operators, it seems we have to cast to integer if not explictly requested in the code. TODO: find a way to force our way with a float value if needed

	===== Changelog =====		===== Changelog =====

class_const_visibility

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/12/08 16:01		current
Line 3:		Line 3:
	* Date: 2015-09-13		* Date: 2015-09-13
	* Author: Sean DuBois <sean@siobud.com>, Reeze Xia <reeze@php.net>		* Author: Sean DuBois <sean@siobud.com>, Reeze Xia <reeze@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/class_const_visibility		* First Published at: http://wiki.php.net/rfc/class_const_visibility

Line 110:		Line 110:
	* V0.1 Initial version		* V0.1 Initial version
	* V0.2 Adopted by Sean DuBois <sean@siobud.com>		* V0.2 Adopted by Sean DuBois <sean@siobud.com>
		+	* V0.2 Implemented

class_name_literal_on_object

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/02/11 10:20		current
Line 3:		Line 3:
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
	* Target Version: PHP 8.0		* Target Version: PHP 8.0
-	* Status: Accepted	+	* Status: Implemented
	* Implementation: https://github.com/php/php-src/pull/5065		* Implementation: https://github.com/php/php-src/pull/5065

class_name_scalars

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/01/18 18:51		current
Line 3:		Line 3:
	* Date: 2012-04-17		* Date: 2012-04-17
	* Author: Ralph Schindler <ralph.at.ralphschindler.com>		* Author: Ralph Schindler <ralph.at.ralphschindler.com>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.5
	* First Published at: http://wiki.php.net/rfc/class_name_scalars		* First Published at: http://wiki.php.net/rfc/class_name_scalars

class_properties_initialization

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/07/30 10:44		current
Line 27:		Line 27:

	private httpRequest $var3 = NULL;		private httpRequest $var3 = NULL;
		+	}
		+	</code>
		+
		+	instead of:
		+
		+	<code php>
		+	class Foo
		+	{
		+	private $var1;
		+
		+	private $var2;
		+
		+	private $var3 = NULL;
		+
		+	public function __construct ()
		+	{
		+	$this -> var1 = function () { /* some callback ? */ }
		+
		+	$this -> var2 = array ( 'foo' => function () { /* some callback ? */ } );
		+
		+	if ( ( $request = SomeCore :: getRequest () ) instanceof httpRequest )
		+	{
		+	$this -> var3 = $request;
		+	}
		+	}
	}		}
	</code>		</code>
Line 38:		Line 63:
	{		{
	private $var1 = new Bar();		private $var1 = new Bar();
		+
	private $var2 = Bar :: getInstance ();		private $var2 = Bar :: getInstance ();
	}		}

class-like_primitive_types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/12/19 22:21		current
Line 169:		Line 169:
	The extension of these features to the other primitive types opens up a number of future possibilities.		The extension of these features to the other primitive types opens up a number of future possibilities.

-	One of these would be [[http://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html\|introducing new methods on the other primitive types]] (and also properties). This could lend string and array manipulation the convenience of method calls, and would provide an opportunity for a fresh start versus PHP's existing sstring and array functions, which have notoriously inconsistent naming and parameter orders.	+	One of these would be [[http://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html\|introducing new methods on the other primitive types]] (and also properties). This could lend string and array manipulation the convenience of method calls, and would provide an opportunity for a fresh start versus PHP's existing string and array functions, which have notoriously inconsistent naming and parameter orders.

	It also means we can easily introduce new superclasses of our other primitive types. For example, a new <php>\Number</php> type superclassing <php>int</php> and <php>float</php>, or a new <php>\Scalar</php> type superclassing everything except objects and arrays. Such superclasses could potentially be extended also by user-defined classes.		It also means we can easily introduce new superclasses of our other primitive types. For example, a new <php>\Number</php> type superclassing <php>int</php> and <php>float</php>, or a new <php>\Scalar</php> type superclassing everything except objects and arrays. Such superclasses could potentially be extended also by user-defined classes.

class-naming-acronyms

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/05/06 18:16		current
Line 4:		Line 4:
	* Author: Tim Düsterhus, timwolla@php.net		* Author: Tim Düsterhus, timwolla@php.net
	* Status: Accepted		* Status: Accepted
		+	* Implementation: https://github.com/php/php-src/pull/14169, https://github.com/php/policies/pull/7
	* First Published at: http://wiki.php.net/rfc/class-naming-acronyms		* First Published at: http://wiki.php.net/rfc/class-naming-acronyms

Line 209:		Line 210:
	===== Implementation =====		===== Implementation =====

-	n/a	+	* https://github.com/php/php-src/pull/14169
		+	* https://github.com/php/policies/pull/7

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

class-naming

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/07/01 17:44		current
Line 3:		Line 3:
	* Date: 2017-06-03		* Date: 2017-06-03
	* Author: Richard Fussenegger, php@fleshgrinder.com		* Author: Richard Fussenegger, php@fleshgrinder.com
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/class-naming		* First Published at: http://wiki.php.net/rfc/class-naming

Line 100:		Line 100:
	Simple 50%+1 majority vote:		Simple 50%+1 majority vote:

-	<doodle title="Should we update the coding standard?" auth="fleshgrinder" voteType="single" closed="false">	+	<doodle title="Should we update the coding standard?" auth="fleshgrinder" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 107:		Line 107:
	\\		\\

-	<doodle title="What class naming style should we use?" auth="fleshgrinder" voteType="single" closed="false">	+	<doodle title="What class naming style should we use?" auth="fleshgrinder" voteType="single" closed="true">
	* PascalCase except Acronyms		* PascalCase except Acronyms
	* Always PascalCase		* Always PascalCase

clear-process

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/04/25 09:41		current
Line 32:		Line 32:
	Should the focus of an RFC be on removal, and should that RFC be accepted, deprecation shall be carried out as described above.		Should the focus of an RFC be on removal, and should that RFC be accepted, deprecation shall be carried out as described above.

-	===== Voting =====	+	==== Voting ====

	Should this RFC be accepted, a new section in the voting RFC shall be created containing the information agreed upon here.		Should this RFC be accepted, a new section in the voting RFC shall be created containing the information agreed upon here.

-	===== External References =====	+	==== External References ====

	http://externals.io/somewhere		http://externals.io/somewhere

cli_process_title

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/03/08 00:12		current
Line 4:		Line 4:
	* Date: 2013-02-06		* Date: 2013-02-06
	* Author: Keyur Govande <kgovande@gmail.com>		* Author: Keyur Govande <kgovande@gmail.com>
-	* Status: Accepted	+	* Status: Implemented (in PHP 5.5)
	* First Published at: http://wiki.php.net/rfc/cli_process_title		* First Published at: http://wiki.php.net/rfc/cli_process_title

cli_server_http2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/01/18 08:22		current
Line 18:		Line 18:

	- Make it optional, allowing you to build the current HTTP/1.x cli-server and requiring no additional dependency		- Make it optional, allowing you to build the current HTTP/1.x cli-server and requiring no additional dependency
-	- Make it required	+	- Make it required, but this also effectively requires libopenssl

	It should be noted that libnghttp2 is also used by both curl and Apache 2, making it more likely that you already have it		It should be noted that libnghttp2 is also used by both curl and Apache 2, making it more likely that you already have it
Line 26:		Line 26:
	In addition, we should consider adding the HTTP/2 ''SETTINGS'' to ''$_SERVER'' so we can both detect that the request is using HTTP/2 and make intelligent decisions on how the application performs (e.g. server push of multiple CSS files vs minifying/concatenating).		In addition, we should consider adding the HTTP/2 ''SETTINGS'' to ''$_SERVER'' so we can both detect that the request is using HTTP/2 and make intelligent decisions on how the application performs (e.g. server push of multiple CSS files vs minifying/concatenating).

-	We should also support the ability to do server push using HTTP headers (current community thinking is leaning towards ''Link: <resource>; rel=push'' header)	+	We should also support the ability to do server push using HTTP headers (current community thinking is leaning towards ''Link: <resource>; rel=preload'' header)

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

cli-strict

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/07/05 16:41		current
Line 3:		Line 3:
	* Date: 2011-07-06		* Date: 2011-07-06
	* Author: Adam Harvey <aharvey@php.net>		* Author: Adam Harvey <aharvey@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/cli-strict		* First Published at: http://wiki.php.net/rfc/cli-strict

clone_with_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-07-17T19:15:42+00:00

2025/06/30 10:34		current
Line 3:		Line 3:
	* Date: 2025-03-30		* Date: 2025-03-30
	* Author: Volker Dusch (volker@tideways-gmbh.com), Tim Düsterhus (tim@tideways-gmbh.com)		* Author: Volker Dusch (volker@tideways-gmbh.com), Tim Düsterhus (tim@tideways-gmbh.com)
-	* Status: Accepted	+	* Status: Implemented
		+	* Target Version: PHP 8.5
		+	* Implementation: https://github.com/php/php-src/commit/ca49a7bec2a0a8d77bfa4b6d375ca0ffa4edc5ee, https://github.com/php/php-src/commit/c9249e2d3aa401bda5d9a3071e86e0594807ed00, https://github.com/php/php-src/commit/7f4076bae0cf91c5a24f4f908525e739e6bca8fb
	* First Published at: https://wiki.php.net/rfc/clone_with_v2		* First Published at: https://wiki.php.net/rfc/clone_with_v2

Line 477:		Line 479:
	* https://github.com/php/php-src/commit/ca49a7bec2a0a8d77bfa4b6d375ca0ffa4edc5ee		* https://github.com/php/php-src/commit/ca49a7bec2a0a8d77bfa4b6d375ca0ffa4edc5ee
	* https://github.com/php/php-src/commit/c9249e2d3aa401bda5d9a3071e86e0594807ed00		* https://github.com/php/php-src/commit/c9249e2d3aa401bda5d9a3071e86e0594807ed00
		+	* https://github.com/php/php-src/commit/7f4076bae0cf91c5a24f4f908525e739e6bca8fb

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

clone_with

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/06/13 20:21		current
Line 169:		Line 169:
	* ''Foo::$bar'' is assigned to 1		* ''Foo::$bar'' is assigned to 1
	* Clone with assignment #2 opcode		* Clone with assignment #2 opcode
-	* ''$this->bar'' is not a string expression which throws a ''TypeError''	+	* ''$this->bar'' is not a string expression: a ''TypeError'' is thrown
	* the right-hand side is not evaluated: ''Exception'' is not thrown		* the right-hand side is not evaluated: ''Exception'' is not thrown

closure_apply

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/08/20 14:14		current
Line 3:		Line 3:
	* Date: 2014-07-29, put to internals 2014-08-03, latest 2014-08-19		* Date: 2014-07-29, put to internals 2014-08-03, latest 2014-08-19
	* Author: Andrea Faulds, ajf@ajf.me		* Author: Andrea Faulds, ajf@ajf.me
-	* Status: In Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/closure_apply		* First Published at: http://wiki.php.net/rfc/closure_apply

Line 107:		Line 107:
	Voting started 2014-08-17 but was cancelled the same day due to the removal of unbound scoped closures.		Voting started 2014-08-17 but was cancelled the same day due to the removal of unbound scoped closures.

-	Voting started again on 2014-08-20 and ends 2014-08-27.	+	Voting started again on 2014-08-20 and ended 2014-08-27.

-	<doodle title="Closure::apply() (Approve RFC and merge into master?)" auth="ajf" voteType="single" closed="false">	+	<doodle title="Closure::apply() (Approve RFC and merge into master?)" auth="ajf" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

closure_self_reference

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/06/03 21:00		current
Line 111:		Line 111:
	};		};

-	$factorial = fn $fn(int $num) as $fn : int => $num > 1 ? $num * $fn($num - 1) : $num;	+	$factorial = fn $fn(int $num): int => $num > 1 ? $num * $fn($num - 1) : $num;
	</code>		</code>

Line 128:		Line 128:

	<code php>		<code php>
-	$factorial = fn(int $num) as $fn: int => $num > 1 ? $num * $fn($num - 1) : $num;	+	$factorial = fn(int $num): int => $num > 1 ? $num * $fn($num - 1) : $num;
	</code>		</code>

closure-optimizations

Anonymous (anonymous@undisclosed.example.com) — 2026-03-13T14:51:51+00:00

2026/02/27 14:40		current
Line 2:		Line 2:
	* Date: 2026-01-30		* Date: 2026-01-30
	* Author: Ilija Tovilo <ilutov@php.net>		* Author: Ilija Tovilo <ilutov@php.net>
-	* Status: Voting	+	* Status: Accepted / Landing
	* Proposed Version: PHP 8.6		* Proposed Version: PHP 8.6
	* Implementation: https://github.com/php/php-src/pull/19941		* Implementation: https://github.com/php/php-src/pull/19941
Line 88:		Line 88:
	Voting opened on 2026-02-27 and closes on 2026-03-13.		Voting opened on 2026-02-27 and closes on 2026-03-13.

-	<doodle title="Add closure optimizations to PHP 8.6?" auth="ilutov" voteType="single" closed="false" closeon="2026-03-13T14:00:00Z">	+	<doodle title="Add closure optimizations to PHP 8.6?" auth="ilutov" voteType="single" closed="true" closeon="2026-03-13T14:00:00Z">
	* Yes		* Yes
	* No		* No

closurefromcallable

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/07/05 06:54		current
Line 3:		Line 3:
	* Date: 2016-04-23		* Date: 2016-04-23
	* Author: Dan Ackroyd, Danack@php.net		* Author: Dan Ackroyd, Danack@php.net
-	* Status: Accepted	+	* Status: Implemented (PHP 7.1)
	* First Published at: https://wiki.php.net/rfc/closurefromcallable		* First Published at: https://wiki.php.net/rfc/closurefromcallable

Line 191:		Line 191:
	However this RFC takes the position that it is inappropriate to have a separate function per type. Instead having a single function that takes any callable parameter is more powerful, and easier for users to use.		However this RFC takes the position that it is inappropriate to have a separate function per type. Instead having a single function that takes any callable parameter is more powerful, and easier for users to use.

		+	===== Implementation =====
		+
		+	Merged into php-src for PHP 7.1: https://github.com/php/php-src/commit/63ca65d
		+
		+	After the project is implemented, this section should contain
		+	- a link to the PHP manual entry for the feature
		+
	===== Appendix =====		===== Appendix =====

closures_in_const_expr

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/11/29 09:44		current
Line 3:		Line 3:
	* Date: 2024-10-24		* Date: 2024-10-24
	* Author: Tim Düsterhus (tim@tideways-gmbh.com), Volker Dusch (volker@tideways-gmbh.com)		* Author: Tim Düsterhus (tim@tideways-gmbh.com), Volker Dusch (volker@tideways-gmbh.com)
-	* Status: Accepted	+	* Status: Implemented
		+	* Target Version: PHP 8.5
		+	* Implementation: https://github.com/php/php-src/commit/f6a0bb4d0442d2780c61d32d01c117024eccab57
	* First Published at: https://wiki.php.net/rfc/closures_in_const_expr		* First Published at: https://wiki.php.net/rfc/closures_in_const_expr

Line 213:		Line 215:
	===== Implementation =====		===== Implementation =====

-	n/a	+	https://github.com/php/php-src/commit/f6a0bb4d0442d2780c61d32d01c117024eccab57

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

closures

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/12/15 22:40		current
Line 40:		Line 40:

	Note: str_replace also accepts arrays as a third parameter so this example may be a bit useless. But imagine you want to do a more complex operation than simple search and replace.		Note: str_replace also accepts arrays as a third parameter so this example may be a bit useless. But imagine you want to do a more complex operation than simple search and replace.
-
	===== Common misconceptions =====		===== Common misconceptions =====

	- Lambda functions / closures are not a way of dynamically extending classes by additional methods at runtime. There are several other possibilities to do this, including the already present _ _call semantic.		- Lambda functions / closures are not a way of dynamically extending classes by additional methods at runtime. There are several other possibilities to do this, including the already present _ _call semantic.
-
	- PHP's notion of scope is quite different than the notion of scope other languages define. Combine this with variable variables ($$var) and it becomes clear that automatically detecting which variables from the outer scope are referenced inside are closure is impossible. Also, since for example global variables are not visible inside functions either by default, automatically making the parent scope available would break with the current language concept PHP follows.		- PHP's notion of scope is quite different than the notion of scope other languages define. Combine this with variable variables ($$var) and it becomes clear that automatically detecting which variables from the outer scope are referenced inside are closure is impossible. Also, since for example global variables are not visible inside functions either by default, automatically making the parent scope available would break with the current language concept PHP follows.

code_free_constructor

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/01/29 12:13		current
Line 129:		Line 129:

	I think that if we want to add some kind of sugar of this type, then I'd strongly prefer the syntax used by Hack than the one proposed here. It makes a lot more sense to me intuitively, probably because the property declarations still looks like normal property declarations, they just occur in-line in the ctor.</blockquote>		I think that if we want to add some kind of sugar of this type, then I'd strongly prefer the syntax used by Hack than the one proposed here. It makes a lot more sense to me intuitively, probably because the property declarations still looks like normal property declarations, they just occur in-line in the ctor.</blockquote>
-	A matter of habit and documentation. There is a lot of really strange and magical behavior in the language. It seems to me that the proposed concept is quite simple and transparent for understanding.	+	A matter of habit and documentation. There is a lot of really strange and magical behavior in the language. It seems to me that the proposed concept is quite simple and transparent for understanding. IMHO this syntax make behavior more strict. No need to
		+	read constructor's body, because you know exactly what's going on.
	===== References =====		===== References =====

code_optimizations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/03/01 16:15		current
Line 3:		Line 3:
	* Date: 2023-03-01		* Date: 2023-03-01
	* Author: Max Kellermann, max.kellermann@ionos.com		* Author: Max Kellermann, max.kellermann@ionos.com
-	* Status: Draft	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/code_optimizations		* First Published at: http://wiki.php.net/rfc/code_optimizations

coercive_sth

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2015-02-27		* Date: 2015-02-27
	* Authors: Zeev Suraski <zeev@php.net>, Francois Laupretre <francois@php.net>, Dmitry Stogov <dmitry@php.net>		* Authors: Zeev Suraski <zeev@php.net>, Francois Laupretre <francois@php.net>, Dmitry Stogov <dmitry@php.net>
-	* Status: Rejected	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/coercive_sth		* First Published at: http://wiki.php.net/rfc/coercive_sth

collections

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/05/02 15:40		current
Line 3:		Line 3:
	* Date: 2023-04-24		* Date: 2023-04-24
	* Author: Derick Rethans <derick@php.net>		* Author: Derick Rethans <derick@php.net>
-	* Status: Draft	+	* Status: Very Early Draft
	* First Published at: http://wiki.php.net/rfc/collections		* First Published at: http://wiki.php.net/rfc/collections

Line 25:		Line 25:
	Design Goals:		Design Goals:

-	* keep it simple	+	*
-	* default behaviour should be the most expected	+
-	* prefer a method per function, instead of allowing the behaviour of a method to be changed through (optional) arguments.	+
-	* operations are on graphemes****	+
-	* no redundant methods that can be constructed from other methods, unless they already exist in PHP, or are frequently used	+
-	* more as we discuss this...	+

	Non Design Goals:		Non Design Goals:

-	* introduce every feature of the intl extension	+	*

	==== Syntax ====		==== Syntax ====

		+	<code>
	collection Articles(int => Article)		collection Articles(int => Article)
	{		{
	}		}
		+	</code>

	Is short hand for, but acts like ArrayAccess too:		Is short hand for, but acts like ArrayAccess too:

		+	<code>
	class Articles		class Articles
	{		{
Line 73:		Line 71:
	}		}
	}		}
		+	</code>

combined-comparison-operator

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/02/17 14:47		current
Line 70:		Line 70:
	echo $a <=> $b; // 1		echo $a <=> $b; // 1

-	// only values are compared
	$a = (object) ["a" => "b"];		$a = (object) ["a" => "b"];
	$b = (object) ["b" => "b"];		$b = (object) ["b" => "b"];

compact-object-property-assignment

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/04/02 01:56		current
Line 6:		Line 6:
	* Date: 2020-03-17		* Date: 2020-03-17
	* Author: Jakob Givoni <jakob@givoni.dk>		* Author: Jakob Givoni <jakob@givoni.dk>
-	* Status: Voting -[[https://externals.io/message/109055\|externals discussion link]]	+	* Status: Declined
		+	* Discussion: [[https://externals.io/message/109055]]

	===== Introduction =====		===== Introduction =====
Line 470:		Line 471:
	The primary vote of whether or not to accept this RFC requires a 2/3 majority.		The primary vote of whether or not to accept this RFC requires a 2/3 majority.

-	<doodle title="Would you like to add support for COPA?" auth="jgivoni" voteType="single" closed="false">	+	<doodle title="Would you like to add support for COPA?" auth="jgivoni" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 477:		Line 478:
	\\		\\

-	<doodle title="If you voted no, what was the main reason?" auth="jgivoni" voteType="single" closed="false">	+	<doodle title="If you voted no, what was the main reason?" auth="jgivoni" voteType="single" closed="true">
	* I voted yes!		* I voted yes!
	* I don’t find the feature useful		* I don’t find the feature useful
Line 491:		Line 492:
	\\		\\

-	<doodle title="If you did not like the proposed syntax, which alternative would you prefer?" auth="jgivoni" voteType="single" closed="false">	+	<doodle title="If you did not like the proposed syntax, which alternative would you prefer?" auth="jgivoni" voteType="single" closed="true">
	* A (the proposed one)		* A (the proposed one)
	* B		* B

compact

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/06/18 23:22		current
Line 3:		Line 3:
	* Date: 2018-05-24		* Date: 2018-05-24
	* Author: Gabriel Caruso (<carusogabriel34@gmail.com>)		* Author: Gabriel Caruso (<carusogabriel34@gmail.com>)
-	* Status: Accepted	+	* Status: Implemented (PHP 7.3)
	* First Published at: https://wiki.php.net/rfc/compact		* First Published at: https://wiki.php.net/rfc/compact

comparable

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/02/19 22:25		current
Line 118:		Line 118:
	* Comparison of objects with non-objects may become confusing, particularly if scalar casting is added to the mix.		* Comparison of objects with non-objects may become confusing, particularly if scalar casting is added to the mix.
	* Comparison of objects with objects of a different class may be confusing or ill-defined.		* Comparison of objects with objects of a different class may be confusing or ill-defined.
		+	* Why we use interface instead of magic method. Comparable is not reserved currently, but methods started with __ are always reserved.

	===== Alternative Approaches =====		===== Alternative Approaches =====

comparator_interface

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-09-26		* Date: 2016-09-26
	* Author: Ben Scholzen, mail@dasprids.de		* Author: Ben Scholzen, mail@dasprids.de
-	* Status: Draft	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/comparator_interface		* First Published at: http://wiki.php.net/rfc/comparator_interface

complete_callstatc_magic

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/03/29 02:23		current
Line 145:		Line 145:

	Aside from the fact that the method is not static, this code is very clear too.		Aside from the fact that the method is not static, this code is very clear too.
		+
		+
		+
		+	==== Case 3 ====
		+
		+	Let's make a custom facade in Laravel.
		+
		+	<code php>
		+	<?php
		+	// 1. app/Services/CustomService.php
		+	namespace App\Services;
		+
		+	class CustomService
		+	{
		+	public function someMethod() {}
		+	}
		+	</code>
		+
		+	<code php>
		+	<?php
		+	// 2. app/Facades/CustomFacade.php
		+	namespace App\Facades;
		+
		+	use Illuminate\Support\Facades\Facade;
		+
		+	class CustomFacade extends Facade
		+	{
		+	protected static function getFacadeAccessor()
		+	{
		+	return 'custom';
		+	}
		+	}
		+	</code>
		+
		+	<code php>
		+	<?php
		+	// 3. app/Providers/AppServiceProvider.php
		+	namespace App\Providers;
		+
		+	use Illuminate\Support\ServiceProvider;
		+	use App\Services\CustomService;
		+
		+	class AppServiceProvider extends ServiceProvider
		+	{
		+	public function register()
		+	{
		+	$this->app->bind('custom', function () {
		+	return new CustomService();
		+	});
		+	}
		+	}
		+	</code>
		+
		+	<code php>
		+	<?php
		+	use App\Facades\CustomFacade;
		+
		+	CustomFacade::someMethod();
		+	</code>
		+
		+
		+	Now what if this RFC is accepted?
		+
		+
		+	<code php>
		+	<?php
		+	// 1. app/Services/CustomService.php
		+	namespace App\Services;
		+
		+	class CustomService
		+	{
		+	public static __callStatic($method, $args)
		+	{
		+	return (new static())->$method(...$args);
		+	}
		+
		+	public function someMethod() {}
		+	}
		+	</code>
		+
		+	<code php>
		+	<?php
		+	use App\Services\CustomService;
		+
		+	CustomService::someMethod();
		+	</code>
		+
		+	That's it.
		+
		+	----------------------

comprehensions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/03/11 11:53		current
Line 171:		Line 171:
	- In most cases it doesn't matter either way. The result will be put into a foreach() loop and that will be the end of it.		- In most cases it doesn't matter either way. The result will be put into a foreach() loop and that will be the end of it.
	- Cases where it does matter are where the list is especially large, or especially expensive to generate and only selected values will be used. In those cases a generator is superior as it minimizes the memory and CPU usage (respectively) needed to represent values.		- Cases where it does matter are where the list is especially large, or especially expensive to generate and only selected values will be used. In those cases a generator is superior as it minimizes the memory and CPU usage (respectively) needed to represent values.
-	- If an actual array is desired, converting a generator to an array is a trivial call to ''%%iterator_to_array()%%''. Converting an array to an iterator, while technically easy, has no benefit aside from compatibility with other iterators. Returning a generator, therefore, offers the most benefit with the fewest limitations.	+	- If an actual array is desired, converting a generator to an array is a trivial call to ''%%iterator_to_array()%%''. Converting an array to an iterator, while technically easy, has no benefit aside from compatibility with other iterators.
		+	- That is, a greedy-list value can be composed out of a lazy-list value and a expansion operation. However, a lazy-list value cannot be composed from a greedy-list. That means since both are valuable, the one that provides both via syntactic composition is the superior approach.
	- A compact syntax to produce a generator allows for some nifty functional programming techniques that until now have been verbose to implement for non-array iterators.		- A compact syntax to produce a generator allows for some nifty functional programming techniques that until now have been verbose to implement for non-array iterators.

concatenation_precedence

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/05/16 16:05		current
Line 3:		Line 3:
	* Date: 2019-03-28		* Date: 2019-03-28
	* Author: Bob Weinand, bobwei9@hotmail.com		* Author: Bob Weinand, bobwei9@hotmail.com
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/concatenation_precedence		* First Published at: http://wiki.php.net/rfc/concatenation_precedence

conditional_break_continue_return

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/16 20:22		current
Line 3:		Line 3:
	* Date: 2020-05-16		* Date: 2020-05-16
	* Author: Ralph Schindler, ralphschindler@php.net		* Author: Ralph Schindler, ralphschindler@php.net
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/conditional_break_continue_return		* First Published at: http://wiki.php.net/rfc/conditional_break_continue_return
	===== Introduction =====		===== Introduction =====

consistent_callables

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/04/28 03:08		current
Line 3:		Line 3:
	* Date: 2019-04-28		* Date: 2019-04-28
	* Author: Dan Ackroyd		* Author: Dan Ackroyd
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: https://wiki.php.net/rfc/consistent_callables		* First Published at: https://wiki.php.net/rfc/consistent_callables

consistent_function_names

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/07 00:40		current
Line 649:		Line 649:
	* file_stat <- stat (IEEE)		* file_stat <- stat (IEEE)
	* file_stat_clear_cache <- clearstatcache		* file_stat_clear_cache <- clearstatcache
		+
		+	* file_move_uploaded <- move_upload_file

	* file_delete <- unlink (There is dummy "delete()" function entry for unlink(). Unlink is a directory operation in fact, but made it as file_delete(). There will be dir_delete())		* file_delete <- unlink (There is dummy "delete()" function entry for unlink(). Unlink is a directory operation in fact, but made it as file_delete(). There will be dir_delete())
Line 803:		Line 805:

	* Use of namespace to clean up global namespace at all.		* Use of namespace to clean up global namespace at all.
-	* New APIs that replace old APIs.
-	* Parameter order inconsistency.
	* Return type inconsistency.		* Return type inconsistency.
	* Constant name inconsistency.		* Constant name inconsistency.
Line 852:		Line 852:
	* http://php.net/manual/en/ref.classobj.php		* http://php.net/manual/en/ref.classobj.php
	* __autoload — Attempt to load undefined class		* __autoload — Attempt to load undefined class
-	* call_user_method_array — Call a user method given with an array of parameters [deprecated]	+	* class_alias — Creates an alias for a class
-	* call_user_method — Call a user method on an specific object [deprecated]	+
-	* class_alias — Creates an alias for a class (Aliases should not be listed, but they should be searchable)	+
	* class_called — the "Late Static Binding" class name		* class_called — the "Late Static Binding" class name
	* class_declared — Returns an array with the name of the defined classes		* class_declared — Returns an array with the name of the defined classes
Line 871:		Line 869:
	* trait_declared — Returns an array of all declared traits		* trait_declared — Returns an array of all declared traits
	* trait_exists — Checks if the trait exists		* trait_exists — Checks if the trait exists
		+
		+	* call_user_method_array — Call a user method given with an array of parameters [deprecated]
		+	* call_user_method — Call a user method on an specific object [deprecated]


Line 883:		Line 884:
	* gc_enable — Activates the circular reference collector		* gc_enable — Activates the circular reference collector
	* gc_enabled — Returns status of the circular reference collector		* gc_enabled — Returns status of the circular reference collector
-	* get_magic_quotes_gpc — Gets the current configuration setting of magic_quotes_gpc [Deprecated]
-	* get_magic_quotes_runtime — Gets the current active configuration setting of magic_quotes_runtime [Deprecated]
	* get_env — Gets the value of an environment variable		* get_env — Gets the value of an environment variable
	* get_last_mod — Gets time of last page modification		* get_last_mod — Gets time of last page modification
Line 893:		Line 892:
	* get_opt — Gets options from the command line argument list		* get_opt — Gets options from the command line argument list
	* get_rusage — Gets the current resource usages		* get_rusage — Gets the current resource usages
-	* ini_alter — Alias of ini_set (Aliases should not be listed, but they should be searchable)
	* ini_get_all — Gets all configuration options		* ini_get_all — Gets all configuration options
	* ini_get — Gets the value of a configuration option		* ini_get — Gets the value of a configuration option
	* ini_restore — Restores the value of a configuration option		* ini_restore — Restores the value of a configuration option
	* ini_set — Sets the value of a configuration option		* ini_set — Sets the value of a configuration option
-	* magic_quotes_runtime — Alias of set_magic_quotes_runtime [Deprecated] (Aliases should not be listed, but they should be searchable)
	* main — Dummy for main		* main — Dummy for main
	* memory_get_peak_usage — Returns the peak of memory allocated by PHP		* memory_get_peak_usage — Returns the peak of memory allocated by PHP
Line 918:		Line 915:
	* php_ini_scanned_files — Return a list of .ini files parsed from the additional ini dir		* php_ini_scanned_files — Return a list of .ini files parsed from the additional ini dir
	* php_logo_guid — Gets the logo guid		* php_logo_guid — Gets the logo guid
-	* php_required_files — Alias of get_included_files (Aliases should not be listed, but they should be searchable)
	* php_sapi_name — Returns the type of interface between web server and PHP		* php_sapi_name — Returns the type of interface between web server and PHP
	* php_time_limit — Limits the maximum execution time		* php_time_limit — Limits the maximum execution time
Line 924:		Line 920:
	* php_version — Gets the current PHP version		* php_version — Gets the current PHP version
	* put_env — Sets the value of an environment variable		* put_env — Sets the value of an environment variable
-	* set_magic_quotes_runtime — Sets the current active configuration setting of magic_quotes_runtime [Deprecated]
	* sys_get_temp_dir — Returns directory path used for temporary files		* sys_get_temp_dir — Returns directory path used for temporary files
	* version_compare — Compares two "PHP-standardized" version number strings		* version_compare — Compares two "PHP-standardized" version number strings
Line 930:		Line 925:
	* zend_thread_id — Returns a unique identifier for the current thread		* zend_thread_id — Returns a unique identifier for the current thread
	* zend_version — Gets the version of the current Zend engine		* zend_version — Gets the version of the current Zend engine
		+
		+	* get_magic_quotes_gpc — Gets the current configuration setting of magic_quotes_gpc [Deprecated]
		+	* get_magic_quotes_runtime — Gets the current active configuration setting of magic_quotes_runtime [Deprecated]
		+	* magic_quotes_runtime — Alias of set_magic_quotes_runtime [Deprecated] (Aliases should not be listed, but they should be searchable)
		+	* set_magic_quotes_runtime — Sets the current active configuration setting of magic_quotes_runtime [Deprecated]
		+
		+	* ini_alter — Alias of ini_set (Aliases should not be listed, but they should be searchable)
		+	* php_required_files — Alias of get_included_files (Aliases should not be listed, but they should be searchable)
		+

	====Arrays====		====Arrays====
Line 1006:		Line 1010:
	* list — Assign variables as if they were an array		* list — Assign variables as if they were an array
	* next — Advance the internal array pointer of an array		* next — Advance the internal array pointer of an array
-	* pos — Alias of current (Aliases will not be listed)
	* prev — Rewind the internal array pointer		* prev — Rewind the internal array pointer
	* reset — Set the internal pointer of an array to its first element		* reset — Set the internal pointer of an array to its first element
		+
		+	* pos — Alias of current (Aliases will not be listed)
	* sizeof — Alias of count (Aliases will not be listed)		* sizeof — Alias of count (Aliases will not be listed)

Line 1015:		Line 1020:
	* bool_val — Get the boolean value of a variable		* bool_val — Get the boolean value of a variable
	* debug_zval_dump — Dumps a string representation of an internal zend value to output		* debug_zval_dump — Dumps a string representation of an internal zend value to output
-	* double_val — Alias of floatval (Aliases should not be listed, but they should be searchable)
	* empty — Determine whether a variable is empty		* empty — Determine whether a variable is empty
	* float_val — Get float value of a variable		* float_val — Get float value of a variable
Line 1026:		Line 1030:
	* is_float — Finds whether the type of a variable is float		* is_float — Finds whether the type of a variable is float
	* is_int — Find whether the type of a variable is integer		* is_int — Find whether the type of a variable is integer
-	* is_integer — Alias of is_int (Aliases should not be listed, but they should be searchable)
-	* is_long — Alias of is_int (Aliases should not be listed, but they should be searchable)
	* is_null — Finds whether a variable is NULL		* is_null — Finds whether a variable is NULL
	* is_numeric — Finds whether a variable is a number or a numeric string		* is_numeric — Finds whether a variable is a number or a numeric string
	* is_object — Finds whether a variable is an object		* is_object — Finds whether a variable is an object
-	* is_real — Alias of is_float (Aliases should not be listed, but they should be searchable)
	* is_resource — Finds whether a variable is a resource		* is_resource — Finds whether a variable is a resource
	* is_scalar — Finds whether a variable is a scalar		* is_scalar — Finds whether a variable is a scalar
Line 1047:		Line 1048:
	* var_dump — Dumps information about a variable		* var_dump — Dumps information about a variable
	* var_export — Outputs or returns a parsable string representation of a variable		* var_export — Outputs or returns a parsable string representation of a variable
		+
		+	* double_val — Alias of floatval (Aliases should not be listed, but they should be searchable)
		+	* is_integer — Alias of is_int (Aliases should not be listed, but they should be searchable)
		+	* is_long — Alias of is_int (Aliases should not be listed, but they should be searchable)
		+	* is_real — Alias of is_float (Aliases should not be listed, but they should be searchable)

	====Program execution Functions====		====Program execution Functions====
Line 1097:		Line 1103:
	* sprintf — Return a formatted string		* sprintf — Return a formatted string
	* str_case_cmp — Binary safe case-insensitive string comparison		* str_case_cmp — Binary safe case-insensitive string comparison
-	* str_chr — Alias of strstr (Aliases should not be listed, but they should be searchable)
-	* str_chop — Alias of str_rtrim (Aliases should not be listed, but they should be searchable)
	* str_chunk_split — Split a string into smaller chunks		* str_chunk_split — Split a string into smaller chunks
	* str_cmp — Binary safe string comparison		* str_cmp — Binary safe string comparison
Line 1112:		Line 1116:
	* str_ireplace — Case-insensitive version of str_replace.		* str_ireplace — Case-insensitive version of str_replace.
	* str_istr — Case-insensitive strstr		* str_istr — Case-insensitive strstr
-	* str_join — Alias of implode (Aliases should not be listed, but they should be searchable)
	* str_lc_first — Make a string's first character lowercase		* str_lc_first — Make a string's first character lowercase
	* str_len — Get string length		* str_len — Get string length
Line 1163:		Line 1166:
	* vprintf — Output a formatted string		* vprintf — Output a formatted string
	* vsprintf — Return a formatted string		* vsprintf — Return a formatted string
		+
		+	* str_chr — Alias of strstr (Aliases should not be listed, but they should be searchable)
		+	* str_chop — Alias of str_rtrim (Aliases should not be listed, but they should be searchable)
		+	* str_join — Alias of implode (Aliases should not be listed, but they should be searchable)
		+

	====Filesystem Functions====		====Filesystem Functions====
Line 1174:		Line 1182:
	* disk_free_space — Returns available space on filesystem or disk partition		* disk_free_space — Returns available space on filesystem or disk partition
	* disk_total_space — Returns the total size of a filesystem or disk partition		* disk_total_space — Returns the total size of a filesystem or disk partition
-	* diskfreespace — Alias of disk_free_space (Aliases should not be listed, but they should be searchable)
	* fclose — Closes an open file pointer		* fclose — Closes an open file pointer
	* feof — Tests for end-of-file on a file pointer		* feof — Tests for end-of-file on a file pointer
Line 1194:		Line 1201:
	* file_inode — Gets file inode		* file_inode — Gets file inode
	* file_mtime — Gets file modification time		* file_mtime — Gets file modification time
		+	* file_move_uploaded — Moves an uploaded file to a new location
	* file_owner — Gets file owner		* file_owner — Gets file owner
	* file_perms — Gets file permissions		* file_perms — Gets file permissions
Line 1200:		Line 1208:
	* file_passthru — Output all remaining data on a file pointer		* file_passthru — Output all remaining data on a file pointer
	* file_put_csv — Format line as CSV and write to file pointer		* file_put_csv — Format line as CSV and write to file pointer
-	* file_puts — Alias of fwrite (Aliases should not be listed, but they should be searchable)
	* file_size — Gets file size		* file_size — Gets file size
	* file_temp_name — Create file with unique file name		* file_temp_name — Create file with unique file name
Line 1225:		Line 1232:
	* is_uploaded_file — Tells whether the file was uploaded via HTTP POST		* is_uploaded_file — Tells whether the file was uploaded via HTTP POST
	* is_writable — Tells whether the filename is writable		* is_writable — Tells whether the filename is writable
-	* is_writeable — Alias of is_writable (Aliases should not be listed, but they should be searchable)
	* link_chgrp — Changes group ownership of symlink		* link_chgrp — Changes group ownership of symlink
	* link_chown — Changes user ownership of symlink		* link_chown — Changes user ownership of symlink
Line 1233:		Line 1239:
	* link_symbolic — Creates a symbolic link		* link_symbolic — Creates a symbolic link
	* link — Create a hard link		* link — Create a hard link
-	* move_uploaded_file — Moves an uploaded file to a new location
	* parse_ini_file — Parse a configuration file		* parse_ini_file — Parse a configuration file
	* parse_ini_string — Parse a configuration string (This is string function. Or make them ini function? ini_string()/ini_file() )		* parse_ini_string — Parse a configuration string (This is string function. Or make them ini function? ini_string()/ini_file() )
Line 1244:		Line 1249:
	* realpath_cache_size — Get realpath cache size		* realpath_cache_size — Get realpath cache size
	* realpath — Returns canonicalized absolute pathname		* realpath — Returns canonicalized absolute pathname
-	* set_file_buffer — Alias of stream_set_write_buffer (This is kind of deprecated function. User should use stream function)
	* stat_clear_cache — Clears file status cache		* stat_clear_cache — Clears file status cache
	* stat — Gives information about a file		* stat — Gives information about a file

		+	* set_file_buffer — Alias of stream_set_write_buffer (This is kind of deprecated function. User should use stream function)
		+	* diskfreespace — Alias of disk_free_space (Aliases should not be listed, but they should be searchable)
		+	* is_writeable — Alias of is_writable (Aliases should not be listed, but they should be searchable)
		+	* fputs — Alias of fwrite (Aliases should not be listed, but they should be searchable)

consistent_type_errors

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/03/05 10:19		current
Line 2:		Line 2:
	* Date: 2019-02-05		* Date: 2019-02-05
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 8.0)
-	* Target Version: PHP 8.0	+
	* Implementation: https://github.com/php/php-src/pull/3794		* Implementation: https://github.com/php/php-src/pull/3794

consistent-names

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2014-01-23		* Date: 2014-01-23
	* Author: Yasuo Ohgaki, yohgaki@ohgaki.net		* Author: Yasuo Ohgaki, yohgaki@ohgaki.net
-	* Status: Draft	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/consistent-names		* First Published at: http://wiki.php.net/rfc/consistent-names

consolidate-coding-standard-policy-document

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2025/01/14 15:26		current
Line 24:		Line 24:
	2/3rds majority required. The vote runs until January 28th, 16:00 UTC.		2/3rds majority required. The vote runs until January 28th, 16:00 UTC.

-	<doodle title="Rewrite Coding Standards and Naming Document with Suggested Patch?" auth="derick" voteType="single" closed="false">	+	<doodle title="Rewrite Coding Standards and Naming Document with Suggested Patch?" auth="derick" voteType="single" closed="true">
	* yes		* yes
	* no		* no

const_object_property_write

Anonymous (anonymous@undisclosed.example.com) — 2026-04-11T08:07:49+00:00

2026/04/09 08:34		current
Line 7:		Line 7:

	===== Introduction =====		===== Introduction =====
-	This RFC allows writing to object properties (and `isset()` / `unset()` on properties) when the object instance is referenced by a constant.	+	This RFC allows writing to object properties (and <php>isset()</php> / <php>unset()</php> on properties) when the object instance is referenced by a constant.

	PHP constants are immutable in the sense that the constant binding cannot be changed. However, objects in PHP are mutable by design: mutating an object property does not rebind the constant, it only updates the state of the referenced object.		PHP constants are immutable in the sense that the constant binding cannot be changed. However, objects in PHP are mutable by design: mutating an object property does not rebind the constant, it only updates the state of the referenced object.

-	Today, PHP rejects `CONST_OBJ->prop = ...` with a fatal error ("Cannot use temporary expression in write context").	+	Today, PHP rejects <php>CONST_OBJ->prop = ...</php> with a fatal error ("Cannot use temporary expression in write context").
	This RFC proposes permitting property write operations in this specific scenario, aligning behavior with user expectations while keeping the constant binding immutable.		This RFC proposes permitting property write operations in this specific scenario, aligning behavior with user expectations while keeping the constant binding immutable.

	<PHP>		<PHP>
	<?php		<?php
-
	const OBJ = new stdClass();		const OBJ = new stdClass();

Line 24:		Line 23:
	unset(OBJ->value);		unset(OBJ->value);
	var_dump(isset(OBJ->value)); // bool(false)		var_dump(isset(OBJ->value)); // bool(false)
-
	?>		?>
	</PHP>		</PHP>
Line 32:		Line 30:

	The change is intentionally narrow:		The change is intentionally narrow:
-	* It permits object property writes (`->`) and related operations (`isset`, `unset`, compound assignment,	+	* It permits object property writes (<php>-></php>) and related operations (<php>isset</php>, <php>unset</php>, compound assignment, increment/decrement, string concatenation) on objects referenced by constants.
-	increment/decrement, string concatenation) on objects referenced by constants.	+	* It permits passing constant object properties by reference to functions (including the "BP_VAR_FUNC_ARG" path when the function is declared after the call site).
-	* It permits passing constant object properties by reference to functions (including the `BP_VAR_FUNC_ARG`	+
-	path when the function is declared after the call site).	+
	* It does not make constants mutable (rebinding remains illegal).		* It does not make constants mutable (rebinding remains illegal).
-	* It does not change array/dimension write semantics (`[]`), nor does it change "write-to-temporary" behavior for dims.	+	* It does not change array/dimension write semantics (<php>[]</php>), nor does it change "write-to-temporary" behavior for dims.

	Specifically, the following operations become valid:		Specifically, the following operations become valid:

-	* Assignment to a property:	+	* Assignment to a property:<PHP>
-	<PHP>	+
	<?php		<?php
	const OBJ = new stdClass();		const OBJ = new stdClass();
Line 49:		Line 44:
	</PHP>		</PHP>

-	* Compound operations on a property:	+	* Compound operations on a property:<PHP>
-	<PHP>	+
	<?php		<?php
	const OBJ = new stdClass();		const OBJ = new stdClass();
Line 62:		Line 56:
	</PHP>		</PHP>

-	* `isset()` / `unset()` on a property:	+	* <php>isset()</php> / <php>unset()</php> on a property:<PHP>
-	<PHP>	+
	<?php		<?php
	const OBJ = new stdClass();		const OBJ = new stdClass();
Line 73:		Line 66:
	</PHP>		</PHP>

-	* Nested property operations:	+	* Nested property operations:<PHP>
-	<PHP>	+
	<?php		<?php
	const OBJ = new stdClass();		const OBJ = new stdClass();
Line 83:		Line 75:
	</PHP>		</PHP>

-	* Passing properties by reference:	+	* Passing properties by reference:<PHP>
-	<PHP>	+
	<?php		<?php
	const OBJ = new stdClass();		const OBJ = new stdClass();
Line 123:		Line 114:
	</PHP>		</PHP>

-	These dim-write cases involve assignment to temporaries that silently have no effect. Whether such no-effect writes should produce a warning or error is a valid concern but is out of scope for this RFC and may be addressed separately (e.g. warning/throwing on `ASSIGN_DIM` when OP1 is not a pointer — i.e. not an indirect, reference, or object — as the operation can never have an effect). See the Future Scope section.	+	These dim-write cases involve assignment to temporaries that silently have no effect. Whether such no-effect writes should produce a warning or error is a valid concern but is out of scope for this RFC and may be addressed separately (e.g. warning/throwing on "ASSIGN_DIM" when OP1 is not a pointer — i.e. not an indirect, reference, or object — as the operation can never have an effect). See the Future Scope section.

	==== Non-goals / Explicitly Unchanged ====		==== Non-goals / Explicitly Unchanged ====
	This RFC does NOT change:		This RFC does NOT change:
-	* Rebinding constants:	+	* Rebinding constants:<PHP>
-	<PHP>	+
	<?php		<?php
	const OBJ = new stdClass();		const OBJ = new stdClass();
Line 135:		Line 125:
	</PHP>		</PHP>

-	* Dimension/array writes or other write-to-temporary semantics:	+	* Dimension/array writes or other write-to-temporary semantics:<PHP>
-	<PHP>	+
	<?php		<?php
	const ARR = [1,2,3];		const ARR = [1,2,3];
Line 147:		Line 136:

	==== Implementation Details ====		==== Implementation Details ====
-	The compiler change is in `zend_delayed_compile_prop()` in `Zend/zend_compile.c`. When the object AST node is a	+	The compiler change is in "zend_delayed_compile_prop()" in "Zend/zend_compile.c". When the object AST node is a "ZEND_AST_CONST" and the access type is "BP_VAR_W", "BP_VAR_RW", "BP_VAR_UNSET", or "BP_VAR_FUNC_ARG", the compiler now emits a "ZEND_FETCH_CONSTANT" opcode that produces a "VAR" result (via "zend_emit_op") instead of a "TMP" result (via "zend_emit_op_tmp"). This allows the subsequent property write opcodes to operate on the fetched object.
-	`ZEND_AST_CONST` and the access type is `BP_VAR_W`, `BP_VAR_RW`, `BP_VAR_UNSET`, or `BP_VAR_FUNC_ARG`, the compiler now emits a `ZEND_FETCH_CONSTANT` opcode that produces a `VAR` result (via `zend_emit_op`) instead of a `TMP` result (via `zend_emit_op_tmp`). This allows the subsequent property write opcodes to operate on the fetched object.	+

-	The `zend_compile_const()` function remains unchanged — constants used in read contexts (`BP_VAR_R`, `BP_VAR_IS`) still produce `TMP` results as before.	+	The <php>zend_compile_const()</php> function remains unchanged — constants used in read contexts ("BP_VAR_R", "BP_VAR_IS") still produce "TMP" results as before.

	==== Why This Brings Value ====		==== Why This Brings Value ====
Line 158:		Line 146:
	None.		None.

-	Code that previously terminated with a fatal error for `CONST_OBJ->prop = ...` will now execute successfully. This is a compatibility improvement — no previously-working code changes behavior.	+	Code that previously terminated with a fatal error for <php>CONST_OBJ->prop = ...</php> will now execute successfully. This is a compatibility improvement — no previously-working code changes behavior.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
Line 179:		Line 167:

	===== Future Scope =====		===== Future Scope =====
-	* No-effect dim writes: A future RFC could explore whether certain no-effect write cases should produce a warning or error. For example, `ASSIGN_DIM` when OP1 is not a "pointer" (indirect, reference, or object) can never have an effect, since the write is to a temporary that is immediately discarded. This is a distinct concern from the property-write issue addressed here.	+	* No-effect dim writes: A future RFC could explore whether certain no-effect write cases should produce a warning or error. For example, "ASSIGN_DIM" when OP1 is not a "pointer" (indirect, reference, or object) can never have an effect, since the write is to a temporary that is immediately discarded. This is a distinct concern from the property-write issue addressed here.
-	* Other write-to-temporary semantics**: Cases like `foo()[0] = 1` where the return value is a temporary are similarly out of scope but could be revisited.	+	* Other write-to-temporary semantics: Cases like <php>foo()[0] = 1</php> where the return value is a temporary are similarly out of scope but could be revisited.

	===== Voting Choices =====		===== Voting Choices =====
Line 194:		Line 182:
	Proof of concept implementation:		Proof of concept implementation:
	* https://github.com/php/php-src/pull/20903		* https://github.com/php/php-src/pull/20903
-
-	Tests included in the PR:
-	* `Zend/tests/gh10497.phpt` — property assignment, compound updates, isset/unset, nested writes, by-ref passing
-	* `Zend/tests/gh10497_func_arg.phpt` — BP_VAR_FUNC_ARG path (forward-declared function with by-ref parameter)
-	* `Zend/tests/gh10497_guardrails.phpt` — array dim write on constant still rejected
-	* `Zend/tests/gh10497_guardrails_dim_obj.phpt` — dim write on constant object still rejected
-	* `Zend/tests/gh10497_guardrails_rebind.phpt` — constant rebinding still a parse error
-	* `Zend/tests/gh12102_3.phpt` — updated to reflect correct behavior for array constant by-ref passing

	===== Implementation =====		===== Implementation =====

const_scalar_expressions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/08/14 01:46		current
Line 3:		Line 3:
	* Date: 2013-08-13		* Date: 2013-08-13
	* Author: Anthony Ferrara <ircmaxell@php.net>		* Author: Anthony Ferrara <ircmaxell@php.net>
-	* Status: Draft	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/const_scalar_expressions		* First Published at: http://wiki.php.net/rfc/const_scalar_expressions

const_scalar_expressions2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/11/01 19:17		current
Line 3:		Line 3:
	* Date: 2013-10-18 (original's date was 2013-08-13)		* Date: 2013-10-18 (original's date was 2013-08-13)
	* Author: Andrea Faulds <ajf@ajf.me> (copied from the withdrawn RFC by Anthony Ferrara <ircmaxell@php.net>)		* Author: Andrea Faulds <ajf@ajf.me> (copied from the withdrawn RFC by Anthony Ferrara <ircmaxell@php.net>)
-	* Status: Under Discussion	+	* Status: Withdrawn due to improved proposal by bwoebi: [[rfc:const_scalar_exprs\|PHP RFC: Constant Scalar Expressions]]
	* First Published at: http://wiki.php.net/rfc/const_scalar_expressions2 (copied from the RFC at https://wiki.php.net/rfc/const_scalar_expressions)		* First Published at: http://wiki.php.net/rfc/const_scalar_expressions2 (copied from the RFC at https://wiki.php.net/rfc/const_scalar_expressions)

const_scalar_exprs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/11/28 13:01		current
Line 2:		Line 2:
	* Date: 2013-11-03		* Date: 2013-11-03
	* Author: Bob Weinand <bwoebi@php.net>		* Author: Bob Weinand <bwoebi@php.net>
-	* Status: Merged into PHP 5.6	+	* Status: Implemented in PHP 5.6
	* First Published at: https://wiki.php.net/rfc/const_scalar_exprs		* First Published at: https://wiki.php.net/rfc/const_scalar_exprs
	* This is a follow-up to https://wiki.php.net/rfc/const_scalar_expressions from Anthony Ferrara <ircmaxell@php.net> (which was without constant support)		* This is a follow-up to https://wiki.php.net/rfc/const_scalar_expressions from Anthony Ferrara <ircmaxell@php.net> (which was without constant support)

constant_redefinition

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/06/16 08:41		current
Line 48:		Line 48:

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
-	PHP 7.1.	+	PHP 8.0

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====
-	The vote is a straight Yes/No vote, that requires a 2/3 majority. The voting began on Jun 24 and will close on July 1.	+	The vote is a straight Yes/No vote, that requires a 2/3 majority.

	===== Patches and Tests =====		===== Patches and Tests =====

constants_in_traits

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/07/19 22:00		current
Line 3:		Line 3:
	* Date: 2022-06-21		* Date: 2022-06-21
	* Author: Shinji Igarashi<sji@sj-i.dev>, Stephen Reay<stephen@koalephant.com>		* Author: Shinji Igarashi<sji@sj-i.dev>, Stephen Reay<stephen@koalephant.com>
-	* Status: Accepted	+	* Status: Implemented
	* Implementation: https://github.com/php/php-src/pull/8888		* Implementation: https://github.com/php/php-src/pull/8888
	* First Published at: http://wiki.php.net/rfc/constants_in_traits		* First Published at: http://wiki.php.net/rfc/constants_in_traits

constdereference

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/10/29 17:22		current
Line 37:		Line 37:
	===== Vote =====		===== Vote =====
	<doodle		<doodle
-	title="do you think it is okey to apply this to TRUNK(not 5.4)?" auth="laruence" voteType="single" closed="yes">	+	title="do you think it is okey to apply this to TRUNK(not 5.4)?" auth="laruence" voteType="single" closed="true">
	* yes		* yes
	* no		* no

constructor_promotion

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/29 10:59		current
Line 2:		Line 2:
	* Date: 2020-03-26		* Date: 2020-03-26
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.0		* Target Version: PHP 8.0
	* Implementation: https://github.com/php/php-src/pull/5291		* Implementation: https://github.com/php/php-src/pull/5291

constructor_return_type

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/06/17 10:04		current
Line 1:		Line 1:
	====== PHP RFC: Allow void return type on constructors/destructors ======		====== PHP RFC: Allow void return type on constructors/destructors ======
	* Date: 2020-06-16		* Date: 2020-06-16
-	* Author: Benas Seliuginas, <benas.molis.iml@gmail.com>	+	* Author: Benas Seliuginas, <benas.molis@gmail.com>
	* Target version: PHP 8.0		* Target version: PHP 8.0
	* Status: Superseded by [[rfc:make_ctor_ret_void]]		* Status: Superseded by [[rfc:make_ctor_ret_void]]

constructor-promotion

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== Constructor Argument Promotion ======
	+
	+	* Version: 0.1
	+	* Date: 2013-08-07
	+	* Author: Sean Cannella, seanc@fb.com
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/constructor-promotion
	+
	+	===== Introduction =====
	+
	+	Shorthand syntax for declaring and assigning constructor arguments as properties in the function signature. A similar feature can be found in other programming languages such as Scala and TypeScript.
	+
	+	===== Proposal =====
	+
	+	A common pattern used in classes with constructors is to declare class properties, accept some (or all) of those properties as arguments to a constructor, and assign them within the body of the constructor as so:
	+
	+	<?php
	+	class MyClass {
	+	/**
	+	* foo is used for blah
	+	*/
	+	public $foo;
	+
	+	/**
	+	* bar is used for blah
	+	*/
	+	protected $bar;
	+
	+	/**
	+	* baz is used for blah
	+	*/
	+	private $baz;
	+
	+	/**
	+	* Make a new MyClass
	+	* @param string $foo - Something
	+	* @param int $bar - Something else
	+	* @param string $baz - Other things (optional)
	+	*/
	+	public function __construct($foo, $bar, $baz = 'some default') {
	+	$this->foo = $foo;
	+	$this->bar = $bar;
	+	$this->baz = $baz;
	+	}
	+	}
	+
	+	This is verbose boilerplate and can lead to coderot between the constructor's explanation of the parameters and the property declaration's doc comments. This proposal seeks to simplify writing of such classes through implicit constructor argument promotion. The above class could be rewritten as:
	+
	+
	+	<?php
	+	class Car {
	+	/**
	+	* Make a new Car
	+	* @prop string $make - Make of the car
	+	* @prop int $doors - Number of doors the car has
	+	* @prop string $model - Model of the car (optional)
	+	*/
	+	public function __construct(public $make,
	+	protected $doors,
	+	private $model = 'unknown') {
	+	}
	+	}
	+
	+	Where the repurposing of the visibility keywords tells the compiler to create properties on the class and assign them values from the arguments to the constructor. This would be implemented entirely in the parser to produce equivalent zend_class_entry/zend_property_info structures and assignment bytecodes at the start of the constructor.
	+
	+	===== Considerations/Notes =====
	+
	+	1) No class level analysis when promoting arguments. Specifically, if a field with the name of one of the "to be promoted" parameters is present we would give the expected "Cannot redeclare ..." error. So the following code would lead to an error:
	+
	+	<?php
	+	class A {
	+	private $f;
	+
	+	function __construct(private $f) {}
	+	}
	+
	+	2) Don't perform analysis over class hierarchies. So the following code would lead to two fields being declared, one in class A and one in class B:
	+
	+	<?php
	+	class A {
	+	function __construct(private $f) {}
	+	}
	+
	+	class B extends A {
	+	function __construct(private $f) { parent::__construct($f); }
	+	}
	+
	+	3) Parameter promotion over an abstract constructor or in an interface is not allowed. The following code would result in an error:
	+
	+	<?php
	+	class A {
	+	abstract function __construct(private $f);
	+	}
	+
	+	The reason is that promoted parameters need to add statements to the body of the constructor, which for an abstract method or interface is not present.
	+
	+	4) Unclear whether or not to allow var as a promotion attribute (PHP4 syntax). For now, visibility attributes (public, private, protected) must be explicit.
	+
	+	5) The field assignments will be pushed at the beginning of the method body. In that respect, if the field is later assigned in the constructor the subsequent assignment wins. So
	+
	+	<?php
	+	function __construct(private $f) {
	+	$this->f = clone $f;
	+	}
	+
	+	becomes
	+
	+	function __construct(private $f) {
	+	$this->f = $f;
	+	$this->f = clone $f;
	+	}
	+
	+	The rationale here is that user visible code wins over generated argument promotion code.
	+
	+	6) There should be no issue in pushing the assignment statements at the beginning of the constructor body. PHP does not enforce order of calls to the parent constructor so even if code is generated that precedes a call to parent or, say, assertions there should be no unexpected side effects.
	+
	+	The one contrived case where one could run into problems is something like this because $f will be assigned before the if block:
	+
	+	public __construct(private $f) {
	+	if ($f->isGoodForMe()) {
	+	$this->f = $f;
	+	} // $f is null otherwise
	+	}
	+
	+	This feature should not be used when these semantics are required.
	+
	+	7) One future extension to consider is automatically generating getters (and maybe setters) for the promoted parameters.
	+
	+	8) We will not allow this feature inside traits since __construct may already be present in the using class and this will result in the trait __construct simply being dropped which is likely to lead to more confusion than it is worth.
	+
	+	9) Properties promoted in this fashion would not have their own DocBlock which would be noticeable when reflecting over a class but this is the same as undeclared properties today.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	None.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	HEAD / 5.6+
	+
	+	===== Implementation =====
	+
	+	https://github.com/sgolemon/php-src/commit/56010a74279435223b3ad391d9ee5a8020415192
	+
	+	===== External Impact =====
	+
	+	IDEs would need to update their parsing rules to auto-discover promoted properties.
	+

container-offset-behaviour

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/07/16 02:26		current
Line 5:		Line 5:
	* Author: Gina Peter Banyard <girgias@php.net>		* Author: Gina Peter Banyard <girgias@php.net>
	* Status: Under Discussion		* Status: Under Discussion
-	* Target Version: PHP 8.4	+	* Target Version: PHP 8.5
	* Implementations:		* Implementations:
	* New handler API: <https://github.com/Girgias/php-src/pull/19>		* New handler API: <https://github.com/Girgias/php-src/pull/19>

context_sensitive_lexer

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/05/26 04:09		current
Line 31:		Line 31:

	This RFC revisits the topic of [[https://wiki.php.net/rfc/keywords_as_identifiers\|Keywords as Identifiers]] RFC. But this time		This RFC revisits the topic of [[https://wiki.php.net/rfc/keywords_as_identifiers\|Keywords as Identifiers]] RFC. But this time
-	presenting a minimal and maintainable [[https://github.com/marcioAlmada/php-src/commit/d9d6f0c7e325dcd0d0ff3c3f2dc73c2364c3ad5f\|patch]],	+	presenting a minimal and maintainable [[https://github.com/php/php-src/pull/1221\|patch]], restricted to OO scope only, consistently comprehending:
-	restricted to OO scope only, consistently comprehending:	+

	* Properties, constants and methods defined on classes, interfaces and traits		* Properties, constants and methods defined on classes, interfaces and traits

context-managers

Anonymous (anonymous@undisclosed.example.com) — 2026-04-15T15:03:26+00:00

2026/04/10 22:15		current
Line 90:		Line 90:
	All exceptions or errors will be caught by the context manager. If ''exitContext()'' returns a throwable, it will be rethrown to any outer ''catch'' statements (or context manager blocks). If it returns null, then nothing is rethrown and execution will continue after the context block. Because in a success case the method is passed ''null'', that means always calling ''return $exception'' will result in the desired-in-most-cases behavior (that is, rethrowing an exception if there was one, or just continuing if not). Be aware that it should do so only after any appropriate local cleanup is done, such as closing files or IO connections.		All exceptions or errors will be caught by the context manager. If ''exitContext()'' returns a throwable, it will be rethrown to any outer ''catch'' statements (or context manager blocks). If it returns null, then nothing is rethrown and execution will continue after the context block. Because in a success case the method is passed ''null'', that means always calling ''return $exception'' will result in the desired-in-most-cases behavior (that is, rethrowing an exception if there was one, or just continuing if not). Be aware that it should do so only after any appropriate local cleanup is done, such as closing files or IO connections.

-	There are two existing keywords that have special meaning within a ''using'' block (but not in functions called from the block).	+	There are three existing keywords that have special meaning within a ''using'' block (but not in functions called from the block).

	<php>break</php> will jump to the end of the ''using'' block. This will be considered a success case as described above. If the ''break'' is within another control block, it will hit that first; use ''break 2'' or similar, as in other cases of nested control structures. This behavior is consistent with ''switch'' statements.		<php>break</php> will jump to the end of the ''using'' block. This will be considered a success case as described above. If the ''break'' is within another control block, it will hit that first; use ''break 2'' or similar, as in other cases of nested control structures. This behavior is consistent with ''switch'' statements.
		+
		+	<php>continue</php> will have identical behavior to ''break'', but will also trigger a Warning if the continue target would be the ''using'' block. This is consistent with how those keywords behave in ''switch'' statements. The intent is to ensure both keywords have the same "levels" when doing a multi-level ''break 2'' or ''continue 2'' or similar, while still discouraging the use of ''continue'' in cases where it is not appropriate.

	<php>return</php> will return from the function in which the ''using'' block resides, bypassing the remaining statements. This will trigger a success case as defined above, which will happen before the function returns.		<php>return</php> will return from the function in which the ''using'' block resides, bypassing the remaining statements. This will trigger a success case as defined above, which will happen before the function returns.
Line 356:		Line 358:

	Strictly speaking, named labels and ''goto'' would also accomplish the goal. However, ''goto'' is generally discouraged, as it is less structured than ''break'' or ''continue''. Moreover, most other [[https://www.php.net/manual/en/control-structures.break.php\|control structures respect ''break'']]. Making ''using'' the odd one out would serve no purpose but confusion.		Strictly speaking, named labels and ''goto'' would also accomplish the goal. However, ''goto'' is generally discouraged, as it is less structured than ''break'' or ''continue''. Moreover, most other [[https://www.php.net/manual/en/control-structures.break.php\|control structures respect ''break'']]. Making ''using'' the odd one out would serve no purpose but confusion.
-
-	==== continue behavior ====
-
-	The ''continue'' keyword is typically relevant only to looping constructs, which ''using'' is not. The exception is for ''switch'' statements. In ''switch'', a ''continue'' statement will trigger a warning similar to //A "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"// if, and only if, the ''continue X'' statement would land on the switch, and not on a wrapping ''foreach'' or similar. However, the ''switch'' will still be counted for the number of "layers" to be skipped.
-
-	This behavior is due to a quirk of PHP's design, where ''switch'' is treated as a looping structure, which most languages do not. Therefore, ''continue'' is aliased to ''break'', as a warning to users from other languages that it may not do what they're used to it doing. See [[https://externals.io/message/102393#102461\|this message from Nikita]].
-
-	Making ''using'' do the same would be consistent, but would mean adding a feature with a Warning from the get-go.
-
-	Alternatively, we can just have ''continue'' ignore ''using'' blocks entirely, just like it does for ''try'', ''if'', etc. ''using'', is not a looping structure in any sense, logically or in implementation. The downside here is that ''continue N'' and ''break N'' may refer to different parent block levels if one of them is a ''using'', which could be confusing.
-
-	As neither approach is obviously better and both have downsides, we have left this question to a secondary vote. (See below.)

	==== Design notes ====		==== Design notes ====
Line 663:		Line 653:
	==== Generator decorator managers ====		==== Generator decorator managers ====

-	In Python, context managers are implemented under the hood using generators. That allows using stand-alone functions and an annotation to write new context managers, rather than using an object.	+	In Python, context managers may be implemented using generators. That allows using stand-alone functions and an annotation to write new context managers, rather than using an object.

	We have verified that it is possible to write a generator-based wrapper context manager, which would then use a callable that contains its own try-catch blocks. That is, the following would be possible in user-space:		We have verified that it is possible to write a generator-based wrapper context manager, which would then use a callable that contains its own try-catch blocks. That is, the following would be possible in user-space:
Line 715:		Line 705:
	* Abstain		* Abstain
	</doodle>		</doodle>
-
-	Secondary vote. 50% to decide.
-
-	<doodle title="How should continue behave?" voteType="single" closed="true" closeon="2025-01-01T15:30:00Z">
-	* Exactly like in switch
-	* Ignore using blocks entirely, like try
-	* Abstain
-	</doodle>
-

	===== Implementation =====		===== Implementation =====
Line 768:		Line 749:
	* 2026-04-06 - Expand explanation of exitContext return.		* 2026-04-06 - Expand explanation of exitContext return.
	* 2026-04-07 - Move ''continue'' question to a secondary vote.		* 2026-04-07 - Move ''continue'' question to a secondary vote.
		+	* 2026-04-15 - Go back to the original continue implementation, mirroring break.

continue_ob

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/15 07:37		current
Line 4:		Line 4:
	* Last-Modfied: 2015-02-20		* Last-Modfied: 2015-02-20
	* Author: Michael Wallner <mike@php.net>		* Author: Michael Wallner <mike@php.net>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/continue_ob		* First Published at: http://wiki.php.net/rfc/continue_ob

Line 61:		Line 61:

	===== Vote =====		===== Vote =====
-	<doodle title="Continue output buffering on aborted connection?" auth="mike" voteType="single" closed="false">	+	<doodle title="Continue output buffering on aborted connection?" auth="mike" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

continue_on_switch_deprecation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/06/27 16:04		current
Line 3:		Line 3:
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
	* Implementation: https://github.com/php/php-src/pull/3323		* Implementation: https://github.com/php/php-src/pull/3323
-	* Status: Under Discussion	+	* Status: Withdrawn
		+
		+	Based on the RFC discussion, we decided to instead implement this as a simple warning, which has happened in https://github.com/php/php-src/pull/3364.

	===== Introduction =====		===== Introduction =====

convert_numeric_keys_in_object_array_casts

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/11/30 14:49		current
Line 30:		Line 30:
	==== High-level ====		==== High-level ====

-	This RFC proposes to fix this issue for object-to-array casts and array-to-object casts, both for the casting operators and for <php>settype()</php>, and also fix the same issue in <php>get_object_vars()</php>. This would be done by converting the keys of array or object HashTables as appropriate, so numeric string property names in objects would be converted to integer array keys, and vice-versa. Therefore, there would be no inaccessible properties. For example, <php>$arr = [0 => 1, 1 => 2, 2 => 3]; $obj = (object)$arr;</php> would now produce an object with accessible properties named <php>"0"</php>, <php>"1"</php> and <php>"2"</php>, and <php>$obj = new stdClass; $obj->{'0'} = 1; $obj->{'1'} = 2; $obj->{'2'} = 3; $arr = (array)$obj;</php> would now produce an array with the accessible keys <php>0</php>, <php>1</php> and <php>2</php>.	+	This RFC proposes to fix this issue for object-to-array casts and array-to-object casts, both for the casting operators and for <php>settype()</php>, and also fix the same issue in <php>get_object_vars()</php>. This would be done by converting the keys of array or object HashTables as appropriate, so numeric string property names in objects would be converted to integer array keys, and vice-versa. Therefore, there would be no inaccessible properties. For example, <php>$arr = [0 => 1, 1 => 2, 2 => 3]; $obj = (object)$arr;</php> would now produce an object with accessible properties named <php>"0"</php>, <php>"1"</php> and <php>"2"</php>, and <php>$obj = new stdClass; $obj->{'0'} = 1; $obj->{'1'} = 2; $obj->{'2'} = 3; $arr = (array)$obj;</php> would now produce an array with the accessible keys <php> 0</php>, <php>1</php> and <php>2</php>.

	==== Internals ====		==== Internals ====

cookie_max-age

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/01/10 11:34		current
Line 2:		Line 2:
	* Version: 1.1		* Version: 1.1
	* Date: 2012-12-28		* Date: 2012-12-28
-	* Author: Andrey Andreev <narf@bofh.bg>	+	* Author: Andrey Andreev <narf@devilix.net>
	* Status: Implemented		* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/cookie_max-age		* First Published at: http://wiki.php.net/rfc/cookie_max-age

core-autoloading

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/04/23 14:24		current
Line 3:		Line 3:
	* Version: 0.1		* Version: 0.1
	* Date: 2023-04-03		* Date: 2023-04-03
-	* Author: George Peter Banyard, <girgias@php.net>, Dan Ackroyd, <danack@basereality.com>	+	* Author: Gina P Banyard, <girgias@php.net>, Dan Ackroyd, <danack@basereality.com>
	* Status: Under Discussion		* Status: Under Discussion
	* Target Version: PHP 8.3		* Target Version: PHP 8.3

core-function-exceptions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Core Functions Throwing Exceptions in PHP 7 ======
	+	* Version: 0.1
	+	* Date: 2015-08-21
	+	* Author: Aaron Piotrowski, aaron@icicle.io
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/core-function-exceptions
	+
	+	===== Introduction =====
	+	Concern has been raised over the way failure is indicated by several functions in the core that are often used for security purposes. These functions may fail open, allowing execution to continue, potentially compromising the security of an application. Failure of these functions is only indicating failure through a return value that may be inappropriate cast and used or requiring further function calls to check for failure. It is far to easy for an uninformed programmer to be unaware of the potential for failure and the consequences of neglecting to check for failure, so it is imperative that these functions fail closed, so execution cannot continue if the error is ignored.
	+
	+	The following functions are addressed by this RFC:
	+
	+	* ''random_int()''
	+	* ''random_bytes()''
	+	* ''preg_match()''
	+	* ''preg_match_all()''
	+	* ''preg_replace()''
	+	* ''preg_filter()''
	+	* ''preg_split()''
	+	* ''preg_replace_callback()''
	+	* ''preg_replace_callback_array()''
	+
	+	===== Proposal =====
	+	To fail closed while allowing the error to be handled, it is this RFCs proposal that the functions above throw exceptions upon failure. The specific types of exceptions and conditions from which they are thrown are outlined below.
	+
	+	=== random_int() ===
	+	* Throws ''Exception'' if generating sufficiently random data fails.
	+	* Throws ''Error'' if ''$min > $max''.
	+
	+	=== random_bytes() ===
	+	* Throws ''Exception'' if generating sufficiently random data fails.
	+	* Throws ''Error'' if ''$length <= 0''.
	+
	+	=== preg_*() ===
	+	* All functions throw ''Exception'' if the PCRE engine fails.
	+
	+	===== Backward Incompatible Changes =====
	+	''random_int()'' and ''random_bytes()'' are new functions to PHP 7, so changes to these functions do not have any backwards compatibility issues.
	+
	+	Failure of the PCRE engine is uncommon and only occurs when ''prce.jit'' is enabled with certain input strings and patterns. Support for PRCE's JIT compilation was not added until PHP 7.
	+
	+	===== Proposed PHP Version =====
	+	PHP 7.0
	+
	+	===== Future Scope =====
	+	This RFC does not address how exceptions should be thrown from other core functions. This question will be addressed in a separate RFC. Focus was given to the particular functions in this RFC due to their importance to security applications.
	+
	+	===== Proposed Voting Choices =====
	+	* Throw exceptions
	+	* Keep current behavior
	+
	+	===== Patches and Tests =====
	+	Below are implementations of ''random_int()'' and ''random_bytes()'' which throw exceptions, though not exactly what is outlined above. The pulls will be updated to throw the exceptions described above before merging.
	+	* https://github.com/php/php-src/pull/1397
	+	* https://github.com/php/php-src/pull/1398
	+
	+	===== References =====
	+	* [[http://news.php.net/php.internals/87172\|Core functions throwing exceptions in PHP7]]
	+	* [[http://news.php.net/php.internals/87657\|Recap - Core functions throwing exceptions in PHP7]]
	+	* [[http://news.php.net/php.internals/87245\|PCRE JIT stack size limit]]
	+	* [[http://news.php.net/php.internals/87743\|PCRE jit security hole WAS PCRE JIT stack size limit]]

correctly_name_the_rounding_mode_and_make_it_an_enum

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/07/18 06:40		current
Line 3:		Line 3:
	* Date: 2024-04-21		* Date: 2024-04-21
	* Author: Saki Takamachi (saki@php.net), Tim Düsterhus (timwolla@php.net)		* Author: Saki Takamachi (saki@php.net), Tim Düsterhus (timwolla@php.net)
-	* Status: Accepted	+	* Status: Implemented
		+	* Target Version: PHP 8.4
		+	* Implementation: https://github.com/php/php-src/commit/5905857fd2652585989ed03e5a5b0beea89ab18e
	* First Published at: https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_Enum		* First Published at: https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_Enum

Line 264:		Line 266:

	===== Implementation =====		===== Implementation =====
-	Yet.	+
		+	* https://github.com/php/php-src/commit/5905857fd2652585989ed03e5a5b0beea89ab18e

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

counting_non_countables

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 4:		Line 4:
	* Author: Craig Duncan <php@duncanc.co.uk>		* Author: Craig Duncan <php@duncanc.co.uk>
	* Proposed version: PHP 7.2		* Proposed version: PHP 7.2
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* ML thread: http://externals.io/thread/350		* ML thread: http://externals.io/thread/350

covariant-returns-and-contravariant-parameters

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/01/16 18:18		current
Line 3:		Line 3:
	* Date: 2018-09-20		* Date: 2018-09-20
	* Author: Levi Morrison <levim@php.net>		* Author: Levi Morrison <levim@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.4)
	* First Published at: http://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters		* First Published at: http://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters

crc-fast

Anonymous (anonymous@undisclosed.example.com) — 2026-02-23T21:42:08+00:00

2026/02/17 11:27		current
Line 1:		Line 1:
	====== PHP RFC: SIMD-Accelerated CRC via crc-fast for ext/hash ======		====== PHP RFC: SIMD-Accelerated CRC via crc-fast for ext/hash ======

-	* Version: 1	+	* Version: 1.1
-	* Date: 2026-02-17	+	* Date: 2026-02-23
	* Author: Michael Wallner <mike@php.net>, Don MacAskill <don@smugmug.com>		* Author: Michael Wallner <mike@php.net>, Don MacAskill <don@smugmug.com>
	* Status: Under Discussion		* Status: Under Discussion
Line 71:		Line 71:
	\| ''crc64ms'' \| CRC-64/MS \|		\| ''crc64ms'' \| CRC-64/MS \|

-	==== No change when disabled ====	+	==== When disabled ====

-	When ''%%--with-crc-fast%%'' is not specified or ''libcrc_fast'' is not installed, PHP builds and behaves exactly as it does today. The new CRC-64 algorithms are not available, and CRC-32 uses the existing implementations.	+	When ''%%--with-crc-fast%%'' is not specified or ''libcrc_fast'' is not installed, PHP builds and behaves exactly as it does today with the addition of the new CRC-64 algorithms implemented without hardware acceleration.

	===== Technical Details =====		===== Technical Details =====
Line 139:		Line 139:
	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====

-	None. The feature is entirely opt-in via ''%%--with-crc-fast%%''. When disabled, PHP is unchanged. When enabled, existing CRC-32 algorithms produce identical output at higher throughput, and new CRC-64 algorithm names are additive.	+	None. The feature is entirely opt-in via ''%%--with-crc-fast%%''.
		+	When enabled, existing CRC-32 as well as new CRC-64 algorithms produce output at higher throughput.

	===== Proposed PHP Version =====		===== Proposed PHP Version =====
Line 199:		Line 200:
	===== Changelog =====		===== Changelog =====
	If there are major changes to the initial proposal, please include a short summary with a date or a link to the mailing list announcement here, as not everyone has access to the wikis' version history.		If there are major changes to the initial proposal, please include a short summary with a date or a link to the mailing list announcement here, as not everyone has access to the wikis' version history.
		+
		+	* 1.1: Clarified inclusion of CRC-64 implementations when the crc-fast library was not enabled/available.

create-split-alias-to-explode

Anonymous (anonymous@undisclosed.example.com) — 2025-09-22T15:44:26+00:00

2025/09/04 13:54		current
Line 3:		Line 3:
	* Date: 2025-08-17		* Date: 2025-08-17
	* Author: Vinicius Dias, carlosv775@gmail.com		* Author: Vinicius Dias, carlosv775@gmail.com
-	* Status: Voting	+	* Status: Declined
	* Implementation: https://github.com/php/php-src/pull/19490		* Implementation: https://github.com/php/php-src/pull/19490

Line 160:		Line 160:
	===== Voting Choices =====		===== Voting Choices =====

-	<doodle title="Create a new split alias for the explode function?" voteType="single" closed="false" closeon="2025-09-19T00:00:00Z">	+	<doodle title="Create a new split alias for the explode function?" voteType="single" closed="true" closeon="2025-09-19T00:00:00Z">
	* Yes		* Yes
	* No		* No

crypt_function_salt

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 93:		Line 93:
	The vote started on 24.09.2013 and ended on 01.10.2013.		The vote started on 24.09.2013 and ended on 01.10.2013.

-	<doodle title="Change crypt behavior when salt parameter is omitted." auth="yohgaki" voteType="single" closed="false">	+	<doodle title="Change crypt behavior when salt parameter is omitted." auth="yohgaki" voteType="single" closed="true">
	* Generate strong salt by default		* Generate strong salt by default
	* Generate E_NOTICE error		* Generate E_NOTICE error

csprng_exceptions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/08/10 14:35		current
Line 1:		Line 1:
	I have no idea how to embed a poll here.		I have no idea how to embed a poll here.
		+
		+	See [[https://www.dokuwiki.org/plugin:doodle2#syntax_and_usage]] and have a look at how it's done for other RFCs. :)

csrandombytes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2012 Jan 8		* Date: 2012 Jan 8
	* Author: Tom Worster <fsb@thefsb.org>		* Author: Tom Worster <fsb@thefsb.org>
-	* Status: Draft	+	* Status: Inactive
	* Sandbox: https://github.com/tom--/php-cs_random_bytes		* Sandbox: https://github.com/tom--/php-cs_random_bytes

curl_http2_push

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/01/12 17:35		current
Line 141:		Line 141:
	===== Implementation =====		===== Implementation =====

-	Server push support has been implementation in PHP 7.1 with [[http://git.php.net/?p=php-src.git;a=commit;h=ad15e1ccdabc678103e356535919e829ba9a0281\|commit ad15e1cc]], and is documented in the [[http://php.net/manual/function.curl-multi-setopt.php\|curl_multi_setopt man page]].	+	Server push support has been implemented in PHP 7.1 with [[http://git.php.net/?p=php-src.git;a=commit;h=ad15e1ccdabc678103e356535919e829ba9a0281\|commit ad15e1cc]], and is documented in the [[http://php.net/manual/function.curl-multi-setopt.php\|curl_multi_setopt man page]].

	The language specification is not affected by this RFC.		The language specification is not affected by this RFC.

curl_oop_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-08-31T15:23:18+00:00

2025/07/21 15:43		current
Line 375:		Line 375:
	* Yes		* Yes
	* No		* No
		+	* Abstain
	</doodle>		</doodle>

curl_setopt_strict_types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/04/22 11:43		current
Line 76:		Line 76:

	===== References =====		===== References =====
-	Mailing list discussion: TODO	+	Mailing list discussion: [[http://marc.info/?l=php-internals&m=149286128912117&w=2]]

curl_share_persistence_improvement

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2025/01/02 14:59		current
Line 3:		Line 3:
	* Date: 2024-11-27		* Date: 2024-11-27
	* Author: Eric Norris, erictnorris@gmail.com		* Author: Eric Norris, erictnorris@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/curl_share_persistence		* First Published at: https://wiki.php.net/rfc/curl_share_persistence
		+	* Implementation: https://github.com/php/php-src/commit/d20880ce3b14e2be02961e0ea63efc514987eca4

	===== Introduction =====		===== Introduction =====
Line 127:		Line 128:

	===== Implementation =====		===== Implementation =====
		+
		+	* https://github.com/php/php-src/commit/d20880ce3b14e2be02961e0ea63efc514987eca4

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

curl_share_persistence

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/11/08 00:02		current
Line 1:		Line 1:
	====== PHP RFC: Add persistent curl share handles ======		====== PHP RFC: Add persistent curl share handles ======
-	* Version: 1.2	+	* Version: 1.3
	* Date: 2024-10-09		* Date: 2024-10-09
	* Author: Eric Norris, erictnorris@gmail.com		* Author: Eric Norris, erictnorris@gmail.com
	* Status: Accepted		* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/curl_share_persistence		* First Published at: http://wiki.php.net/rfc/curl_share_persistence
		+	* Superseded by: http://wiki.php.net/rfc/curl_share_persistence_improvement

	===== Introduction =====		===== Introduction =====

curl_user_agent

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/25 14:23		current
Line 3:		Line 3:
	* Date: 2021-06-25		* Date: 2021-06-25
	* Author: Michael Maroszek (maroszek@gmx.net)		* Author: Michael Maroszek (maroszek@gmx.net)
-	* Proposed Version: PHP 8.1	+	* Proposed Version: PHP 8.2
	* Status: Under Discussion		* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/curl_user_agent		* First Published at: http://wiki.php.net/rfc/curl_user_agent

curl-file-upload

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 19:		Line 19:
	</code>		</code>

-	This API is both invonvenient and insecure, it is impossible to send data starting with '@' to the POST, and any user data that is being re-sent via cURL need to be sanitized so that the data value does not start with @. In general, in-bound signalling usually vulnerable to all sorts of injections and better not done in this way.	+	This API is both inconvenient and insecure, it is impossible to send data starting with '@' to the POST, and any user data that is being re-sent via cURL need to be sanitized so that the data value does not start with @. In general, in-bound signalling usually vulnerable to all sorts of injections and better not done in this way.

	===== CurlFile proposal =====		===== CurlFile proposal =====

curl-oop

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/02/14 18:42		current
Line 217:		Line 217:
	Each existing unit test will be reviewed and duplicated as appropriate to cover the OOP version of the API.		Each existing unit test will be reviewed and duplicated as appropriate to cover the OOP version of the API.

-	* Work in progress: https://github.com/sgolemon/php-src/commits/curli Note that as a work in progress this may not 100% match the proposal above until it is complete.	+	* Work in progress: https://github.com/php/php-src/pull/13394 Note that as a work in progress this may not 100% match the proposal above until it is complete.

	===== Implementation =====		===== Implementation =====

curl-url-api

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/07/05 07:07		current
Line 3:		Line 3:
	* Date: 2022-06-21		* Date: 2022-06-21
	* Author: Pierrick Charron <pierrick@php.net>		* Author: Pierrick Charron <pierrick@php.net>
-	* Status: Voting	+	* Status: Declined
	* First Published at: https://wiki.php.net/rfc/curl-url-api		* First Published at: https://wiki.php.net/rfc/curl-url-api

Line 153:		Line 153:
	Voting opened on 2022-07-04 and closes on 2022-07-19		Voting opened on 2022-07-04 and closes on 2022-07-19

-	<doodle title="Add proposed new functional Curl URL API" auth="pierrick" voteType="single" closed="false">	+	<doodle title="Add proposed new functional Curl URL API" auth="pierrick" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

curl-wrappers-removal-rfc

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/05/09 10:11		current
Line 32:		Line 32:
	Vote starts April 17th, and ends April 24th		Vote starts April 17th, and ends April 24th

-	<doodle title="Should we remove curl-wrappers" auth="pierrick" voteType="single" closed="false">	+	<doodle title="Should we remove curl-wrappers" auth="pierrick" voteType="single" closed="true">
	* Yes, as of PHP5.5		* Yes, as of PHP5.5
	* Yes, but in PHP.next only		* Yes, but in PHP.next only

currying

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/06/07 11:49		current
Line 137:		Line 137:
	</code>		</code>

-	== Pitfalls ==	+	=== Pitfalls and criticism ===
-	= There are a few concerns to implement it that way =	+	== Performance ==
	How is performance affected because of the heavy use of Closure objects? I don’t know yet, any guesses?		How is performance affected because of the heavy use of Closure objects? I don’t know yet, any guesses?

-	= Error Handling =	+	== Error Handling ==
	Error messages could be misleading. E.g. not passing an argument to ''$func()'' would result in a warning for a missing argument when calling ''$func()'' without any mention of ''strpos()''. One way to overcome this problem would be to have ''class CurriedFunction extends Closure''. This subclass would contain additional properties for a nicer the error message. It would even be possible to override error handling for ''CurriedFunction::__invoke()'' to make it more specific.		Error messages could be misleading. E.g. not passing an argument to ''$func()'' would result in a warning for a missing argument when calling ''$func()'' without any mention of ''strpos()''. One way to overcome this problem would be to have ''class CurriedFunction extends Closure''. This subclass would contain additional properties for a nicer the error message. It would even be possible to override error handling for ''CurriedFunction::__invoke()'' to make it more specific.

custom_object_serialization

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/03/20 20:43		current
Line 2:		Line 2:
	* Date: 2019-01-24		* Date: 2019-01-24
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.4)
-	* Target Version: PHP 7.4	+
	* Implementation: https://github.com/php/php-src/pull/3761		* Implementation: https://github.com/php/php-src/pull/3761

customfactories

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/11/18 15:20		current
Line 120:		Line 120:

	Now "Foo" does not depend on any specific implementation, neither on an actual ObjectFactory nor on a specific Email implementation. But this comes with a price: At most places where the "new" operator would usually be used to instantiate classes, the ObjectFactory or some other kind of factory needs to be called. If the mechanism of Dependency Injection is consequently used, this results in a lot of additional typing and many classes will need the ObjectFactory getting injected by the surrounding framework.		Now "Foo" does not depend on any specific implementation, neither on an actual ObjectFactory nor on a specific Email implementation. But this comes with a price: At most places where the "new" operator would usually be used to instantiate classes, the ObjectFactory or some other kind of factory needs to be called. If the mechanism of Dependency Injection is consequently used, this results in a lot of additional typing and many classes will need the ObjectFactory getting injected by the surrounding framework.
-
	===== Proposal =====		===== Proposal =====

Line 153:		Line 152:
	class Foo {		class Foo {
	public function bar() {		public function bar() {
		+	// Instantiate by class name:
		+	$email = new Email();
		+	// or even instantiate by interface name (the factory needs to find the right implementation):
	$email = new EmailInterface();		$email = new EmailInterface();
	}		}
Line 174:		Line 176:
	[2] Robert Lemke, "FLOW3 Object Framework"		[2] Robert Lemke, "FLOW3 Object Framework"
	http://flow3.typo3.org/documentation/manuals/flow3/flow3.objectframework/		http://flow3.typo3.org/documentation/manuals/flow3/flow3.objectframework/
-

cyclic-replace

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/01/16 00:05		current
Line 4:		Line 4:
	* Last modification date : 2015-04-02		* Last modification date : 2015-04-02
	* Author: François Laupretre, francois@tekwire.net		* Author: François Laupretre, francois@tekwire.net
-	* Status: Draft	+	* Status: Abandoned
	* First Published at: http://wiki.php.net/rfc/cyclic-replace		* First Published at: http://wiki.php.net/rfc/cyclic-replace

data_encoding_api

Anonymous (anonymous@undisclosed.example.com) — 2025-11-27T10:35:50+00:00

2025/11/25 10:04		current
Line 522:		Line 522:
	$encodedUpper = "48656C6C6F20776F726C6421"; // using uppercase characters		$encodedUpper = "48656C6C6F20776F726C6421"; // using uppercase characters
	$encodedLower = "48656c6c6f20776f726c6421"; // using lowercase characters		$encodedLower = "48656c6c6f20776f726c6421"; // using lowercase characters
-		+	$encodedUpperWithSpaces = "48 65\n6C\t6C\r6F 2C 20 57 6F 72 6C 64 21";
		+	$encodedWithSpaces = "48 65\n6C\t6C\r6F 2c 20 57 6f 72 6C 64 21";
	echo base16_encode($data);		echo base16_encode($data);
	// returns "48656C6C6F20776F726C6421" the letters are uppercased by default		// returns "48656C6C6F20776F726C6421" the letters are uppercased by default
Line 530:		Line 532:

	echo base16_decode($encodedUpper);		echo base16_decode($encodedUpper);
		+	// returns 'Hello world!'
		+
		+	echo base16_decode($encodedUpperWithSpaces);
	// returns 'Hello world!'		// returns 'Hello world!'

Line 535:		Line 540:
	// throws a UnableToDecodeException exception		// throws a UnableToDecodeException exception
	// by default value is expected with uppercased letters		// by default value is expected with uppercased letters
		+
		+
		+	echo base16_decode($encodedWithSpaces);
		+	// throws a UnableToDecodeException exception
		+	// by default value is expected with uppercased letters
		+	// the example contains lowercased letters (the space do not affect decoding)


Line 542:		Line 553:
	echo base16_decode($encodedLower, variant: Base16::Upper, decodingMode: DecodingMode::Forgiving);		echo base16_decode($encodedLower, variant: Base16::Upper, decodingMode: DecodingMode::Forgiving);
	// 'Hello world!' the decoding is case-insensitive.		// 'Hello world!' the decoding is case-insensitive.
		+
		+	echo base16_decode($encodedWithSpaces, variant: Base16::Upper, decodingMode: DecodingMode::Forgiving);
		+	// 'Hello world!' the decoding is case-insensitive and is not affected by the whitespaces.

	</code>		</code>
Line 553:		Line 567:
	If the input includes lowercase characters, an `UnableToDecodeException` WILL be raised.		If the input includes lowercase characters, an `UnableToDecodeException` WILL be raised.
	To permit case-insensitive decoding, the ''DecodingMode::Forgiving'' mode MAY be used.		To permit case-insensitive decoding, the ''DecodingMode::Forgiving'' mode MAY be used.
		+
		+	As for all the encoding algorithms, whitespaces should not be taken into account during decoding.

data-classes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/04/18 14:22		current
Line 1:		Line 1:
-	====== PHP RFC: Data classes ======	+	Data classes were renamed to [[https://wiki.php.net/rfc/structs-v2\|structs]].
-		+
-	* Date: 2024-04-16	+
-	* Author: Ilija Tovilo, tovilo.ilija@gmail.com	+
-	* Status: Draft	+
-	* Target Version: PHP 8.x	+
-	* Implementation: https://github.com/php/php-src/pull/13800	+
-		+
-	===== Proposal =====	+
-		+
-	This RFC proposes to add data classes, which are classes with [[https://en.wikipedia.org/wiki/Value_semantics\|value semantics]].	+
-		+
-	<code php>	+
-	data class Position {	+
-	public function __construct(	+
-	public $x,	+
-	public $y,	+
-	) {}	+
-	}	+
-		+
-	$p1 = new Position(1, 2);	+
-	$p2 = $p1;	+
-	$p2->x++;	+
-		+
-	var_dump($p1 === $p2); // false	+
-		+
-	$p2->x--;	+
-	var_dump($p1 === $p2); // true	+
-	</code>	+
-		+
-	====== Data transfer objects ======	+
-		+
-	===== The problem =====	+
-		+
-	Classes are commonly used to model data in PHP. Such classes have many names (data transfer objects, plain old php objects, structs, etc.). This allows the developer to describe the shape of the data, thus documenting it and improving developer experience in IDEs.	+
-		+
-	Using classes for data comes with one significant downside: Objects are passed by reference, rather than by value. When dealing with mutable data, this makes it very easy to shoot yourself in the foot by exposing mutations to places that don't expect to see them.	+
-		+
-	Consider the following example:	+
-		+
-	<code php>	+
-	class Position {	+
-	public function __construct(	+
-	public $x,	+
-	public $y,	+
-	) {}	+
-	}	+
-		+
-	function createShapes() {	+
-	// Use same position for both shapes	+
-	$pos = new Position(10, 20);	+
-	$circle = new Circle(position: $pos, radius: 10);	+
-	$square = new Square(position: $pos, side: 20);	+
-	return [$circle, $square];	+
-	}	+
-		+
-	$shapes = createShapes();	+
-		+
-	function applyGravity() {	+
-	foreach ($shapes as $shape) {	+
-	*/ We're not physicists. :P /*	+
-	$shape->position->y--;	+
-	}	+
-	}	+
-		+
-	applyGravity($shape);	+
-		+
-	foreach ($shapes as $shape) {	+
-	var_dump($shape->position);	+
-	}	+
-	// Position(10, 18), Position(10, 18)??	+
-	</code>	+
-		+
-	Since both shapes are created with the same position, ''createShapes()'' tries to be resourceful and uses the same ''Position'' instance for both shapes. Unfortunately, ''applyGravity()'' is not aware of this optimization and applies its change to the same object twice.	+
-		+
-	What's the solution? ''position'' needs to be copied, but where? We can either copy it in ''createShapes()'' so that each shape has its own distinct position, or we can copy it in ''applyGravity()'', assuming that ''position'' may be referenced from somewhere else. For the latter case, we may mark ''Position'' as ''readonly'' to get some guarantees that we get it right. Which of these two approaches is better depends on how many positions can be shared, and how often they change. Unfortunately, either can lead to useless copies.	+
-		+
-	===== The solution =====	+
-		+
-	Like arrays, strings and other value types, data classes are //conceptually// copied when assigned to a variable, or when passed to a function.	+
-		+
-	With this description, let's reconsider the ''createShapes()'' from above.	+
-		+
-	<code php>	+
-	data class Position { ... }	+
-		+
-	function createShapes() {	+
-	// Use same position for both shapes	+
-	$pos = new Position(10, 20);	+
-	$circle = new Circle(position: $pos, radius: 10);	+
-	$square = new Square(position: $pos, side: 20);	+
-	return [$circle, $square];	+
-	}	+
-	</code>	+
-		+
-	//Conceptually//, ''$circle->position'' and ''$square->position'' are distinct objects at the end of this function. ''applyGravity()'' can no longer influence multiple references to ''position''. This completely avoids the "spooky action at a distance" problem.	+
-		+
-	====== Growable data structures ======	+
-		+
-	===== The problem =====	+
-		+
-	The same problem exists, and is in fact greatly exacerbated, for internal, growable data structures such as lists, stacks, queues, etc. that desire to provide APIs immune to action at a distance.	+
-		+
-	<code php>	+
-	// Pseudo-code for an internal class	+
-	class List {	+
-	public $storage = <malloced>;	+
-		+
-	public function append($element) {	+
-	$clone = clone $this; // including storage	+
-	$clone->storage->append($element);	+
-	return $clone;	+
-	}	+
-	}	+
-		+
-	// Userland	+
-	$list = new List();	+
-	for ($i = 0; $i < 1000; $i++) {	+
-	$list = $list->append($i);	+
-	}	+
-	</code>	+
-		+
-	Not only will this loop create a copy for each list object on each iteration, but it will also copy its entire storage. With this approach, time complexity of a single insert becomes O(n). For m inserts, it becomes O(m*n), which is catastrophic. Looking at the code above, it becomes evident that ''$list'' is not referenced from anywhere else. It is thus completely unnecessary to copy it.	+
-		+
-	And when it is shared, we only need a single copy, rather than a copy for each insertion.	+
-		+
-	<code php>	+
-	function appendAndPrint($list) {	+
-	$list = $list->append(2); // This copy may be necessary, because $list may still be referenced in the caller.	+
-	$list = $list->append(3); // This copy is always unnecessary.	+
-	var_dump($list); // [1, 2, 3]	+
-	}	+
-		+
-	$list = new List();	+
-	$list = $list->append(1); // This copy is also unnecessary.	+
-	appendAndPrint($list);	+
-	var_dump($list); // [1]	+
-	</code>	+
-		+
-	===== The solution =====	+
-		+
-	As a reminder, data classes are //conceptually// copied when assigned to a variable, or when passed to a function. When ''appendAndPrint()'' is called, ''$list'' is effectively already copied. Just like with arrays, the user doesn't need to think about creating explicit copies. The engine does it for you.	+
-		+
-	<code php>	+
-	function appendAndPrint($list) {	+
-	$list->append!(2);	+
-	$list->append!(3);	+
-	var_dump($list); // [1, 2, 3]	+
-	}	+
-		+
-	$list = new List();	+
-	$list->append!(1);	+
-	appendAndPrint($list);	+
-	var_dump($list); // [1]	+
-	</code>	+
-		+
-	Mind the ''!'' in ''append!()''. It denotes that the method call will mutate the data class, which makes every modification very explicit. It also has some technical benefits, which will be explained later.	+
-		+
-	One of the primary motivators of this RFC is to enable the possibility of introducing internal data structures, such as lists (e.g. Vector from php-ds) as a faster and stricter alternative to arrays, without introducing many of the pitfalls some other languages suffer from by making them reference types.	+
-		+
-	===== CoW 🐄 =====	+
-		+
-	But wait, this sounds familiar.	+
-		+
-	<blockquote>	+
-	What's the solution? ''position'' needs to be copied, but where? We can either copy it in ''createShapes()'' so that each shape has its own distinct position ... Unfortunately, either can lead to useless copies.	+
-		+
-	<cite>This RFC, minutes ago</cite>	+
-	</blockquote>	+
-		+
-	You may assume that data classes come with the same slowdown as creating a copy for each usage of a data class. However, data classes have a cool trick up their sleeves: Copy-on-write, or CoW for short. CoW is already used for both arrays and strings, so this is not a new concept to the PHP engine. PHP tracks the reference count for each allocation such as objects, arrays and strings. When value types are modified, PHP checks if the reference count is >1, and if so, it copies the element before performing a modification.	+
-		+
-	<code php>	+
-	function print($value) {	+
-	var_dump($value);	+
-	}	+
-		+
-	function appendAndPrint($value) {	+
-	$value[] = 'baz';	+
-	var_dump($value);	+
-	}	+
-		+
-	print(['foo', 'bar']);	+
-	appendAndPrint(['foo', 'bar']);	+
-		+
-	$array = ['foo', 'bar'];	+
-	print($array);	+
-	appendAndPrint($array);	+
-	</code>	+
-		+
-	//Note:// This code ignores the fact that array literals are constant, for simplicity.	+
-		+
-	With the rules described above, the only line performing potential copies is ''$value[] = 'baz';'', since it performs a modification of the array. The copy is also avoided unless ''$value'' is referenced from somewhere else, which is only the case when passing the local variable ''$array'' to ''appendAndPrint()''.	+
-		+
-	This is already how arrays work today. Data classes follow the exact same principle.	+
-		+
-	<code php>	+
-	function print($value) {	+
-	var_dump($value);	+
-	}	+
-		+
-	function modifyAndPrint($value) {	+
-	$value->x++;	+
-	var_dump($value);	+
-	}	+
-		+
-	print(new Position(1, 2));	+
-	appendAndPrint(new Position(1, 2));	+
-		+
-	$pos = new Position(1, 2);	+
-	print($pos);	+
-	appendAndPrint($pos);	+
-	</code>	+
-		+
-	Only one implicit copy happens, namely in ''modifyAndPrint()'' when ''$value'' is still referenced as ''$pos'' from the caller.	+
-		+
-	===== Equality/Identity =====	+
-		+
-	TODO	+
-		+
-	===== Method calls =====	+
-		+
-	TODO	+
-		+
-	===== References =====	+
-		+
-	TODO	+
-		+
-	===== Reflection =====	+
-		+
-	TODO	+
-		+
-	===== Performance =====	+
-		+
-	TODO	+
-		+
-	===== Backwards incompatible changes =====	+
-		+
-	TODO	+
-		+
-	===== Future scope =====	+
-		+
-	- Hashing for ''SplObjectStorage''.	+
-		+
-	===== Vote =====	+
-		+
-	Voting starts xxxx-xx-xx and ends xxxx-xx-xx.	+
-		+
-	As this is a language change, a 2/3 majority is required.	+
-		+
-	<doodle title="Introduce data classes in PHP 8.x?" auth="ilutov" voteType="single" closed="true">	+
-	* Yes	+
-	* No	+
-	</doodle>	+

dataclass

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/11/23 12:37		current
Line 335:		Line 335:
	* [[https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/records\|C# records]]		* [[https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/records\|C# records]]
	* [[https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/struct\|C# structs]]		* [[https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/struct\|C# structs]]
		+	* [[https://externals.io/message/122845\|PHP Structs]]
		+	* [[https://wiki.php.net/rfc/records\|PHP Records]] and [[https://externals.io/message/125975\|discussion]]

	===== Rejected Features =====		===== Rejected Features =====

date_improvements

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/01/12 13:03		current
Line 4:		Line 4:
	* Status: Draft		* Status: Draft
	* Target: 8.4		* Target: 8.4
		+	* Implementation: https://github.com/php/php-src/pull/13050 (DateInterval subclasses)

	===== Introduction =====		===== Introduction =====

date.timezone_warning_removal

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/02/25 00:06		current
Line 3:		Line 3:
	* Date: 2015-01-27		* Date: 2015-01-27
	* Author: Bob Weinand, bobwei9@hotmail.com		* Author: Bob Weinand, bobwei9@hotmail.com
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/date.timezone_warning_removal		* First Published at: https://wiki.php.net/rfc/date.timezone_warning_removal

datetime_and_daylight_saving_time

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/11/02 12:59		current
Line 3:		Line 3:
	* Date: 2011-10-18		* Date: 2011-10-18
	* Author: Daniel Convissor <danielc@php.net> with feedback from Derick Rethans <derick@php.net>		* Author: Daniel Convissor <danielc@php.net> with feedback from Derick Rethans <derick@php.net>
-	* Status: Approved ([[rfc:datetime_and_daylight_saving_time:vote\|voting results]])	+	* Status: Accepted ([[rfc:datetime_and_daylight_saving_time:vote\|voting results]])
	* First Published at: https://wiki.php.net/rfc/datetime_and_daylight_saving_time		* First Published at: https://wiki.php.net/rfc/datetime_and_daylight_saving_time

datetime_tostring

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/09/01 10:13		current
Line 3:		Line 3:
	* Date: 2012-09-01		* Date: 2012-09-01
	* Author: Will Fitch <willfitch@php.net>		* Author: Will Fitch <willfitch@php.net>
-	* Status: Under Discussion	+	* Status: Inactive

	===== Introduction =====		===== Introduction =====

datetime-exceptions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/01/04 20:29		current
Line 3:		Line 3:
	* Date: 2022-12-15 (First created: 2022-11-29)		* Date: 2022-12-15 (First created: 2022-11-29)
	* Author: Derick Rethans <derick@php.net>		* Author: Derick Rethans <derick@php.net>
-	* Status: Accepted	+	* Status: Implemented (2023-02-08)
	* First Published at: http://wiki.php.net/rfc/datetime-exceptions		* First Published at: http://wiki.php.net/rfc/datetime-exceptions

Line 120:		Line 120:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged into	+	- Version: PHP 8.3
-	- a link to the git commit(s)	+	- Commit: https://github.com/php/php-src/commit/66a1a911f1d6cd4b89c0bb5577fa77f1d6a2cb96
-	- a link to the PHP manual entry for the feature	+
-	- a link to the language specification section (if any)	+

	===== Rejected Features =====		===== Rejected Features =====

datetime-tostring

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/09/01 09:59		current
Line 3:		Line 3:
	* Date: 2012-09-01		* Date: 2012-09-01
	* Author: Will Fitch <willfitch@php.net>		* Author: Will Fitch <willfitch@php.net>
-	* Status: In Draft	+	* Status: Under Discussion

	===== Introduction =====		===== Introduction =====

dbc

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2015-02-09		* Date: 2015-02-09
	* Author: François Laupretre <francois@php.net>		* Author: François Laupretre <francois@php.net>
-	* Status: Discussion	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/dbc		* First Published at: http://wiki.php.net/rfc/dbc

dbc2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2015-02-10		* Date: 2015-02-10
	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>, Dmitry Stogov <dmitry@zend.com>, Joe Watkins <pthreads@pthreads.org>		* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>, Dmitry Stogov <dmitry@zend.com>, Joe Watkins <pthreads@pthreads.org>
-	* Status: Discussion	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/dbc2		* First Published at: http://wiki.php.net/rfc/dbc2

debug_backtrace_depth

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/04/09 04:06		current
Line 3:		Line 3:
	* Date: 2021-03-13		* Date: 2021-03-13
	* Author: Tyson Andre, tandre@php.net		* Author: Tyson Andre, tandre@php.net
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: https://wiki.php.net/rfc/debug_backtrace_depth		* First Published at: https://wiki.php.net/rfc/debug_backtrace_depth
	* Implementation: https://github.com/php/php-src/pull/6653		* Implementation: https://github.com/php/php-src/pull/6653

debug-info

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/03/06 14:22		current
Line 4:		Line 4:
	* Date: 2014-01-21		* Date: 2014-01-21
	* Author: Sara Golemon, pollita@php.net		* Author: Sara Golemon, pollita@php.net
-	* Status: Accepted	+	* Status: Accepted (implemented in 5.6)
	* First Published at: http://wiki.php.net/rfc/debug-info		* First Published at: http://wiki.php.net/rfc/debug-info

debugable-enums

Anonymous (anonymous@undisclosed.example.com) — 2026-04-18T00:33:35+00:00

2026/04/02 16:58		current
Line 3:		Line 3:
	* Date: 2026-03-12		* Date: 2026-03-12
	* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com		* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com
-	* Status: In voting	+	* Status: Pending implementation/landing
	* Implementation: https://github.com/php/php-src/pull/21425		* Implementation: https://github.com/php/php-src/pull/21425
	* Discussion thread: https://news-web.php.net/php.internals/130303		* Discussion thread: https://news-web.php.net/php.internals/130303

debugging_pdo_prepared_statement_emulation_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-11-17		* Date: 2016-11-17
	* Author: Adam Baratz adambaratz@php.net		* Author: Adam Baratz adambaratz@php.net
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* First Published at: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2		* First Published at: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2

debugging_pdo_prepared_statement_emulation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-10-17		* Date: 2016-10-17
	* Author: Adam Baratz adambaratz@php.net		* Author: Adam Baratz adambaratz@php.net
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* First Published at: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation		* First Published at: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation

debugoptions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/01/14 21:40		current
Line 10:		Line 10:
	===== Introduction =====		===== Introduction =====

-	Debug backtrace functions are a very useful debug tool. However, for big projects, the problem that often happens is that when something happens inside the code, the debug trace becomes so big it's unmanageable. This is because it includes the arguments, and those can be complex data arrays, huge objects, etc. so when the trace is prepared or printed out, the useful information is drowned in the mass of white noise.	+	Debug backtrace functions are a very useful debug tool. However, for big projects, the problem that often happens is that when something happens inside the code, the debug trace becomes so big it's unmanageable. This is because it always includes the arguments, and those can be complex data arrays, huge objects, etc. so when the trace is prepared or printed out, the useful information is drowned in the mass of white noise.

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

declare_vars

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Variable declarations before usage ======
	+	* Version: 0.1
	+	* Date: 2019-09-19
	+	* Authors: Sara Golemon, pollita@php.net; Andreas Braun, alcaeus@php.net
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/declare_vars

	+	===== Introduction =====
	+
	+	To allow for more strictness and type safety if a user wishes to have it, we need a way to make variable declarations explicit. When enabled, accessing an undeclared variable causes a compile-time error, regardless of whether the user is trying to read or write the variable. This RFC proposes a way to declare variables and to make the process optional for users.
	+
	+	===== Proposal =====
	+	==== Declaring variables ====
	+
	+	Variables can be declared by using the ''var'' keyword:
	+
	+	<code php>
	+	var $variable;
	+	</code>
	+
	+	This initialises the variable with the value ''NULL''. It is equivalent to the following statement:
	+
	+	<code php>
	+	$variable = null;
	+	</code>
	+
	+	Once a variable has been declared, redeclaring it triggers a compile-time error:
	+
	+	<code php>
	+	var $variable;
	+	var $variable; // Compile error: "Cannot redeclare variable $variable"
	+	</code>
	+
	+	When declaring a variable, users may also initialise the variable:
	+
	+	<code php>
	+	var $variable = 'Initial Value';
	+	</code>
	+
	+	Calling ''unset'' on a variable removes the declared variable from the current scope:
	+
	+	<code php>
	+	var $variable;
	+	unset($variable);
	+	var_dump($variable); // Notice: Undefined variable $variable
	+	</code>
	+
	+	==== Requiring variables to be declared before accessing them ====
	+
	+	With the new ''declare_vars'' directive, the engine will throw a compile error when trying to access a variable that hasn't been declared:
	+
	+	<code php>
	+	declare(declare_vars=1);
	+	$variable = 'value'; // Compile error: "Undeclared variable: $variable"
	+	var_dump($otherVariable); // Compile error: "Undeclared variable: $otherVariable"
	+	</code>
	+
	+	This is an alternative to the exception suggested in the [[engine_warnings\|Reclassifying engine warnings]] RFC when reading from an undefined variable. It further disallows implicitly declaring variables, allowing users to switch to this strict mode.
	+
	+	When variable declarations are required, variables can no longer be removed. Calling ''unset'' leads to a compile time error:
	+
	+	<code php>
	+	declare(declare_vars=1);
	+	var $variable;
	+	unset($variable); // Compile error: Cannot unset declared variable
	+	</code>
	+
	+	The ''declare(declare_vars=1)'' statement must not use block mode. Doing so leads to a compile error:
	+
	+	<code php>
	+	declare(declare_vars=1) {
	+	}
	+	</code>
	+
	+	==== Dynamic variables ====
	+
	+	Dynamic variables are evaluated at runtime. They can be declared and accessed as any other variables, but will throw an ''UndeclaredVariableError'' when trying to access a dynamic variable that hasn't been declared. Redeclaring a dynamic variable leads to a ''RedeclaredVariableError'', while trying to unset a declared variable triggers an ''IllegalUnsetError''. These errors extend the ''Error'' class.
	+
	+	<code php>
	+	declare(declare_vars=1);
	+	var $variableName = 'foo';
	+	var $$variableName = 'value';
	+
	+	var_dump($$variableName); // 'value'
	+	var_dump($$$variableName); // UndeclaredVariableError: Undeclared variable $value
	+
	+	var $$variableName; // RedeclaredVariableError: "Cannot redeclare variable $foo"
	+	unset($$variableName); // IllegalUnsetError: "Declared var $foo may not be unset"
	+	</code>
	+
	+	==== Why use a keyword for variable declarations? ====
	+
	+	The ''var'' keyword has been chosen as it already exists, which avoids introducing another keyword to the language (e.g. ''let''). The var keyword is also necessary to differentiate explicit from implicit declarations. Most importantly, the ''var'' keyword is necessary since a possible future introduction of typed variables could create an ambiguity in the parser:
	+
	+	<code php>
	+	require $file;
	+	</code>
	+
	+	This could either be a ''require'' statement that requires the file stored in ''$file'', or a variable declaration for ''$file'' of type ''require'' (which is a valid class name in PHP 7). Using a keyword to mark a variable declaration removes this ambiguity.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	No BC breaks are introduced by this RFC. The ''declare_vars'' directive is optional to prevent breaking existing implicit variable declarations or accessing undefined variables.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	PHP 8.0
	+
	+	===== Open Issues =====
	+	None
	+
	+	===== Future Scope =====
	+
	+	Thie RFC will be followed by a number of other RFCs to expand the functionality of explicit declarations. These are not part of the RFC; please limit discussion to the scope of this RFC.
	+
	+	==== Typed variables ====
	+
	+	In the future, variable declarations may optionally add a type to the variable:
	+
	+	<code php>
	+	var ?string $string;
	+	var ?int = null;
	+	var My\Object = new My\Object();
	+	</code>
	+
	+	==== Lexical scopes ====
	+
	+	A future RFC could introduce lexical scopes, allowing to better control where variables can be accessed:
	+
	+	<code php>
	+	var $unscopedVariable;
	+
	+	{
	+	var $scopedVariable;
	+	}
	+
	+	var_dump($unscopedVariable); // NULL
	+	var_dump($scopedVariable); // Compile error: "Undeclared variable $scopedVariable"
	+	</code>
	+
	+	==== Disallow dynamic object properties ====
	+
	+	The variable declaration logic could also be applied to class properties, which would disallow dynamic properties. This is part of a separate RFC and will use a separate ''declare'' switch, as users may want to enforce declaration of variables in code that should also dynamic properties for their class.
	+
	+	==== Constant variables ====
	+
	+	A future RFC may add support for constant variables, which can't be reassigned:
	+
	+	<code php>
	+	const $foo = 'value';
	+	$foo = 'other value'; // Compile error: "Can't assign value to constant variable $foo"
	+	</code>
	+
	+	===== Proposed Voting Choices =====
	+
	+	A yes/no vote.
	+
	+	===== Patches and Tests =====
	+
	+	A prototype implementation is available at https://github.com/sgolemon/php-src/tree/sgolemon.declared-vars (work in progress)
	+
	+	===== Implementation =====
	+	After the project is implemented, this section should contain
	+	- the version(s) it was merged into
	+	- a link to the git commit(s)
	+	- a link to the PHP manual entry for the feature
	+	- a link to the language specification section (if any)
	+
	+	===== References =====
	+	Links to external references, discussions or RFCs
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.

decode_html

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/09/06 18:56		current
Line 125:		Line 125:
	A new enum specifies supported HTML contexts. For the most part the enum specifies three internal properties:		A new enum specifies supported HTML contexts. For the most part the enum specifies three internal properties:

-	- Are character references decoded?	+	* Are character references decoded?
-	- Are ambiguous ampersand references interpreted?	+	* Are ambiguous ampersand references interpreted?
-	- Are NULL bytes replace or removed?	+	* Are NULL bytes replace or removed?

	While these could be handled via three boolean flags, that would require developers to understand the nuances involved in the different situations where they imply. By focusing the API on the kind of situations developers work in, the burden is removed to know the internal details of HTML parsing. For this reason there is overlap in ''Script'', ''Style'', and ''Comment'' contexts, because the parsing rules are identical.		While these could be handled via three boolean flags, that would require developers to understand the nuances involved in the different situations where they imply. By focusing the API on the kind of situations developers work in, the burden is removed to know the internal details of HTML parsing. For this reason there is overlap in ''Script'', ''Style'', and ''Comment'' contexts, because the parsing rules are identical.

dedicated_stream_bucket

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/04/11 13:01		current
Line 2:		Line 2:
	* Date: 2024-01-19		* Date: 2024-01-19
	* Author: Máté Kocsis <kocsismate@php.net>		* Author: Máté Kocsis <kocsismate@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target: next minor version (possibly PHP 8.4)		* Target: next minor version (possibly PHP 8.4)
	* Implementation: https://github.com/php/php-src/pull/13111		* Implementation: https://github.com/php/php-src/pull/13111

default_ctor

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2014-11-05		* Date: 2014-11-05
	* Author: Stas Malyshev, stas@php.net		* Author: Stas Malyshev, stas@php.net
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/default_ctor		* First Published at: http://wiki.php.net/rfc/default_ctor

default_encoding

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/02/14 06:34		current
Line 128:		Line 128:
	* http://svn.php.net/viewvc?view=revision&revision=332851		* http://svn.php.net/viewvc?view=revision&revision=332851
	* http://svn.php.net/viewvc?view=revision&revision=332852		* http://svn.php.net/viewvc?view=revision&revision=332852
		+	* http://svn.php.net/viewvc?view=revision&revision=332857

	===== Changelog =====		===== Changelog =====

default_expression

Anonymous (anonymous@undisclosed.example.com) — 2026-01-23T23:09:02+00:00

2025/04/03 13:08		current
Line 4:		Line 4:
	* Date: 2024-08-24		* Date: 2024-08-24
	* Author: Paul Morris <bilge@scriptfusion.com>		* Author: Paul Morris <bilge@scriptfusion.com>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Target Version: PHP 8.5		* Target Version: PHP 8.5
	* Implementation: https://github.com/php/php-src/pull/15437		* Implementation: https://github.com/php/php-src/pull/15437

default-session-strict-mode

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/03/21 11:30		current
Line 3:		Line 3:
	* Date: 2018-02-13		* Date: 2018-02-13
	* Author: Pieter Hordijk, peehaa@php.net		* Author: Pieter Hordijk, peehaa@php.net
-	* Status: Draft	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/default-session-strict-mode		* First Published at: http://wiki.php.net/rfc/default-session-strict-mode

define-negative-execution-time

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Your Title Here ======
	+	* Version: 0.9
	+	* Date: 2024-04-11
	+	* Author: Robert Landers, landers.robert@gmail.com
	+	* Status: Draft (or Under Discussion or Accepted or Declined)
	+	* First Published at: http://wiki.php.net/rfc/define-negative-execution-time

	+	===== Introduction =====
	+
	+	Currently, a negative max execution time may be set to a negative number without warning or error. The documentation does not define what happens when a negative number is given, and this RFC deprecates passing a negative number.
	+
	+	===== Proposal =====
	+
	+	Given a max_execution_time either via a php.ini setting or via set_time_limit() will result in a deprecation notice from 8.4+ and a fatal error in 9.0+. Numbers greater than 999,999,999 (31 years, 259 days) will be set to 0 (unlimited).
	+
	+	===== Backward Incompatible Changes =====
	+
	+	* Legacy code passing a negative number will receive a deprecation notice.
	+
	+	===== Proposed PHP Version(s) =====
	+	8.4: deprecation notice
	+	9.0: fatal error
	+
	+	===== RFC Impact =====
	+	==== To SAPIs ====
	+	The potential of a fatal error while applying the configuration.
	+
	+	==== To Existing Extensions ====
	+	None
	+
	+	==== To Opcache ====
	+	None
	+
	+	===== Open Issues =====
	+	Not yet.
	+
	+	===== Unaffected PHP Functionality =====
	+	No change for positive integers in the bounds.
	+
	+	===== Proposed Voting Choices =====
	+
	+	* yes: to apply a deprecation warning and fatal error in the next major version
	+	* no: to keep it undefined
	+
	+	===== Patches and Tests =====
	+
	+	PR conforming setting negative numbers to 0: https://github.com/php/php-src/pull/13942
	+
	+	===== Implementation =====
	+	After the project is implemented, this section should contain
	+	- the version(s) it was merged into
	+	- a link to the git commit(s)
	+	- a link to the PHP manual entry for the feature
	+	- a link to the language specification section (if any)
	+
	+	===== References =====
	+	Links to external references, discussions or RFCs
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.

delayedtargetvalidation_attribute

Anonymous (anonymous@undisclosed.example.com) — 2025-08-20T07:41:59+00:00

2025/08/01 14:23		current
Line 3:		Line 3:
	* Date: 2025.06.17		* Date: 2025.06.17
	* 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.5
	* First Published at: https://wiki.php.net/rfc/DelayedTargetValidation_attribute		* First Published at: https://wiki.php.net/rfc/DelayedTargetValidation_attribute
		+	* Implementation: https://github.com/php/php-src/pull/18817

	===== Introduction =====		===== Introduction =====

deprecate_curly_braces_array_access

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/07/19 15:30		current
Line 4:		Line 4:
	* Status: Implemented (in PHP 7.4)		* Status: Implemented (in PHP 7.4)
	* Discussion: https://externals.io/message/104744		* Discussion: https://externals.io/message/104744
-	* Target version: PHP 7.4	+	* Targets: PHP 7.4
	* Implementation: https://github.com/php/php-src/pull/4416		* Implementation: https://github.com/php/php-src/pull/4416

deprecate_dollar_brace_string_interpolation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/04/22 12:30		current
Line 3:		Line 3:
	* Date: 2021-03-13		* Date: 2021-03-13
	* Author: Ilija Tovilo, tovilo.ilija@gmail.com		* Author: Ilija Tovilo, tovilo.ilija@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.2		* Target Version: PHP 8.2
	* Implementation: https://github.com/php/php-src/pull/8212		* Implementation: https://github.com/php/php-src/pull/8212

deprecate_dynamic_properties

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/11/26 09:03		current
Line 2:		Line 2:
	* Date: 2021-08-23		* Date: 2021-08-23
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.2		* Target Version: PHP 8.2
	* Implementation: https://github.com/php/php-src/pull/7571		* Implementation: https://github.com/php/php-src/pull/7571

deprecate_functions_with_overloaded_signatures

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/08/07 09:07		current
Line 3:		Line 3:
	* Author: Máté Kocsis <kocsismate@php.net>		* Author: Máté Kocsis <kocsismate@php.net>
	* Target version: PHP 8.3		* Target version: PHP 8.3
-	* Status: Accepted	+	* Status: Implemented
	* Implementation: https://github.com/php/php-src/pull/11703		* Implementation: https://github.com/php/php-src/pull/11703

deprecate_ini_set_get_aliases

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/01/31 07:46		current
Line 173:		Line 173:
	===== Future Scope =====		===== Future Scope =====

-	None. If proposal 3 (Add E_DEPRECATE error) is rejected, adding E_DEPRECATE error will be future decision.	+	* If proposal 3 (Add E_DEPRECATE error) is rejected, adding E_DEPRECATE error will be future decision.
		+	* All INI values in the manual should be able to be easily searchable.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

deprecate_mb_ereg_replace_eval_option

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/07/09 14:25		current
Line 3:		Line 3:
	* Date: 2016-01-04		* Date: 2016-01-04
	* Author: Rouven Weßling, me@rouvenwessling.de		* Author: Rouven Weßling, me@rouvenwessling.de
-	* Status: Accepted	+	* Status: Implemented (PHP 7.1)
	* First Published at: https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option		* First Published at: https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option

Line 49:		Line 49:
	===== Patches and Tests =====		===== Patches and Tests =====

-	A patch is available: <https://github.com/php/php-src/pull/1994>.	+	A patch is available: <https://github.com/php/php-src/pull/1994> (merged).

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

	[[rfc:remove_preg_replace_eval_modifier\| RFC: Remove preg_replace /e modifier]]		[[rfc:remove_preg_replace_eval_modifier\| RFC: Remove preg_replace /e modifier]]

deprecate_mcrypt_rand

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/11/04 19:24		current
Line 3:		Line 3:
	* Date: 2014-07-08		* Date: 2014-07-08
	* Author: Scott Arciszewski, scott@arciszewski.me		* Author: Scott Arciszewski, scott@arciszewski.me
-	* Status: Draft	+	* Status: Obsoleted by [[rfc/mcrypt-viking-funeral]]
	* First Published at: http://wiki.php.net/rfc/deprecate_mcrypt_rand		* First Published at: http://wiki.php.net/rfc/deprecate_mcrypt_rand

deprecate_null_to_scalar_internal_arg

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/02/17 11:53		current
Line 82:		Line 82:
	===== Vote =====		===== Vote =====

-	Voting started 2020-01-26 and ended on 2020-02-09.	+	Voting started 2021-01-26 and ended on 2021-02-09.

	<doodle title="Deprecate passing null to non-nullable arguments of internal functions?" auth="nikic" voteType="single" closed="true">		<doodle title="Deprecate passing null to non-nullable arguments of internal functions?" auth="nikic" voteType="single" closed="true">

deprecate_partially_supported_callables

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/10/22 08:01		current
Line 2:		Line 2:
	* Date: 2021-09-02		* Date: 2021-09-02
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.2		* Target Version: PHP 8.2
	* Implementation: https://github.com/php/php-src/pull/7446		* Implementation: https://github.com/php/php-src/pull/7446

deprecate_pdo_null

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Deprecate PDO::PARAM_NULL ======
	+	* Version: 0.1
	+	* Date: 2017-05-15
	+	* Author: Adam Baratz adambaratz@php.net
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/deprecate_pdo_null
	+
	+	===== Introduction =====
	+	PDO defines a NULL type, but this concept is not part of the SQL standard. Types are nullable, but there is no type that can only have that value.
	+
	+	The presence of this type is potentially confusing to users. Supporting it adds some weight to PDO. A handful of people on the internals mail list have asked for it to be removed.
	+
	+	===== Proposal =====
	+	Uses of ''PDO::PARAM_NULL'' in the next PHP 7.x would result in deprecation notices. The const and related code would be removed in PHP 7.x+1.
	+
	+	Notices could be produced by these methods:
	+	* ''PDO::quote''
	+	* ''PDOStatement::bindColumn''
	+	* ''PDOStatement::bindParam''
	+	* ''PDOStatement::bindValue''
	+
	+	None of the supported PDO drivers rely on this type to bind null values. It's functionally equivalent to use null with any of the other types. I found four drivers on Pecl with PHP7 support: msphpsql, pdo_ibm, pdo_informix, pdo_sqlanywhere. Some will require modifications to compile once this const is removed, but they won't lose functionality either.
	+
	+	Put another way, any code like this:
	+	<code php>
	+	$statement->bindValue(1, null, PDO::PARAM_NULL);
	+	</code>
	+
	+	Can be replaced by this:
	+	<code php>
	+	$statement->bindValue(1, null);
	+	</code>
	+
	+	===== Proposed Voting Choices =====
	+	This project requires a 50%+1 majority.

deprecate_pear_recommend_composer

Anonymous (anonymous@undisclosed.example.com) — 2025-10-09T14:10:37+00:00

2025/10/09 10:28		current
Line 3:		Line 3:
	* Date: 2025-10-09		* Date: 2025-10-09
	* Author: James Titcumb, asgrim@php.net		* Author: James Titcumb, asgrim@php.net
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Implementation: n/a		* Implementation: n/a

deprecate_php_short_tags_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/08/06 12:10		current
Line 2:		Line 2:
	* Date: 2019-07-23		* Date: 2019-07-23
	* Author: George Peter Banyard <girgias@php.net>, Nikita Popov <nikic@php.net>		* Author: George Peter Banyard <girgias@php.net>, Nikita Popov <nikic@php.net>
-	* Status: Voting	+	* Status: Declined
	* Target version: PHP 7.4		* Target version: PHP 7.4
	* Implementation: https://github.com/php/php-src/pull/4263		* Implementation: https://github.com/php/php-src/pull/4263
Line 75:		Line 75:
	Voting started on 2019-08-06 at 11:30 UTC and is expected to last two (2) weeks until 2019-08-20		Voting started on 2019-08-06 at 11:30 UTC and is expected to last two (2) weeks until 2019-08-20

-	<doodle title="Deprecate and remove short open tags as proposed?" auth="girgias" voteType="single" closed="false">	+	<doodle title="Deprecate and remove short open tags as proposed?" auth="girgias" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

deprecate_php_short_tags

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/08/06 11:18		current
Line 3:		Line 3:
	* Date: 2019-03-20		* Date: 2019-03-20
	* Author: George Peter Banyard, <girgias@php.net>		* Author: George Peter Banyard, <girgias@php.net>
-	* Status: Accepted	+	* Status: Accepted on 2019-04-24, rendered obsolete by [[rfc:deprecate_php_short_tags_v2\|PHP RFC: Deprecate short open tags, again]] on 2019-07-23
	* Target Version: PHP 7.4		* Target Version: PHP 7.4
	* Implementation: https://github.com/php/php-src/pull/3972		* Implementation: https://github.com/php/php-src/pull/3972

deprecate_ticks

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/10 13:19		current
Line 2:		Line 2:
	* Date: 2021-05-11		* Date: 2021-05-11
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Target Version: PHP 8.1		* Target Version: PHP 8.1
	* Implementation: https://github.com/php/php-src/pull/6967		* Implementation: https://github.com/php/php-src/pull/6967
		+	* Discussion: https://externals.io/message/114368

	===== Introduction =====		===== Introduction =====

deprecate-and-remove-ext-interbase

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/04/23 16:52		current
Line 4:		Line 4:
	* Date: 2019-03-22		* Date: 2019-03-22
	* Author: Kalle Sommer Nielsen <kalle@php.net>		* Author: Kalle Sommer Nielsen <kalle@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase		* First Published at: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

deprecate-and-remove-ext-wddx

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/01/31 22:14		current
Line 4:		Line 4:
	* Date: 2018-01-17		* Date: 2018-01-17
	* Author: Christoph M. Becker, <cmb@php.net>		* Author: Christoph M. Becker, <cmb@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx		* First Published at: https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx

Line 57:		Line 57:
	===== Implementation =====		===== Implementation =====

-	After the project is implemented, this section should contain	+	- [[http://git.php.net/?p=php-src.git;a=commit;h=6bbb18a0b6bef11222caaa55c00abdbcbb55d54b\|Applied]] to PHP-7.4
-	- the version(s) it was merged into	+	- [[http://svn.php.net/viewvc?view=revision&revision=347028\|Documentation]]
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+

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

deprecate-and-remove-intl_idna_variant_2003

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 49:		Line 49:
	- PR #2355 has been merged into master (which is supposed to become PHP-7.2) with [[https://github.com/php/php-src/commit/6cfbb7f9bd4576f8f6172a33d49e7498b3b617e1\|commit 6cfbb7f9]].		- PR #2355 has been merged into master (which is supposed to become PHP-7.2) with [[https://github.com/php/php-src/commit/6cfbb7f9bd4576f8f6172a33d49e7498b3b617e1\|commit 6cfbb7f9]].
	- The PHP manual has been [[http://svn.php.net/viewvc?view=revision&revision=341894\|updated]]. The migration guide will be written based on UPGRADING, which already has a respective note.		- The PHP manual has been [[http://svn.php.net/viewvc?view=revision&revision=341894\|updated]]. The migration guide will be written based on UPGRADING, which already has a respective note.
		+	- [[http://git.php.net/?p=php-src.git;a=commit;h=3d15a6f86b56c8acbf7363fb5e70a054918dbd64\|Removed for PHP 8]]

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

deprecate-backtick-operator-v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/10/31 17:46		current
Line 3:		Line 3:
	* Date: 2019-10-04		* Date: 2019-10-04
	* Author: Mark Randall, marandall@php.net		* Author: Mark Randall, marandall@php.net
-	* Status: Voting	+	* Status: Declined
	* First Published at:https://wiki.php.net/rfc/deprecate-backtick-operator-v2		* First Published at:https://wiki.php.net/rfc/deprecate-backtick-operator-v2
	* Target: 8.0		* Target: 8.0
Line 56:		Line 56:
	Voting started 2019-10-31 and will end 2019-11-15. A 2/3 majority is required.		Voting started 2019-10-31 and will end 2019-11-15. A 2/3 majority is required.

-	<doodle title="Deprecate backtick operator in PHP 8.0?" auth="marandall" voteType="single" closed="false">	+	<doodle title="Deprecate backtick operator in PHP 8.0?" auth="marandall" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

deprecate-backtick-operator

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/02/11 20:19		current
Line 15:		Line 15:
	===== Proposal =====		===== Proposal =====

-	This RFC proposes to deprecate (E_DEPRECATED) it in PHP 7.3 and suggest to use ''shell_exec()'' instead:	+	This RFC proposes to deprecate (by triggering one among E_DEPRECATED, E_STRICT or E_NOTICE) it in PHP 7.3 and suggest to use ''shell_exec()'' instead:

	* in case PHP decided in future to use backtick enclosed strings for Unicode strings		* in case PHP decided in future to use backtick enclosed strings for Unicode strings

deprecate-bareword-strings

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2017-03-05		* Date: 2017-03-05
	* Author: Rowan Collins rowan.collins@gmail.com		* Author: Rowan Collins rowan.collins@gmail.com
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* First Published at: http://wiki.php.net/rfc/deprecate-bareword-strings		* First Published at: http://wiki.php.net/rfc/deprecate-bareword-strings

deprecate-boolean-string-coercion

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/25 13:05		current
Line 26:		Line 26:
	is common:		is common:

-	- <php>ini_set()</php>	+	* <php>ini_set()</php>

	===== Rationale =====		===== Rationale =====

deprecate-function-bool-type-juggling

Anonymous (anonymous@undisclosed.example.com) — 2025-08-04T12:02:44+00:00

2025/07/21 12:19		current
Line 4:		Line 4:
	* Date: 2025-06-02		* Date: 2025-06-02
	* Author: Gina Peter Banyard <girgias@php.net>		* Author: Gina Peter Banyard <girgias@php.net>
-	* Status: In Voting	+	* Status: Declined
	* Target Version: PHP 8.5		* Target Version: PHP 8.5
	* Implementation: https://github.com/php/php-src/pull/18879		* Implementation: https://github.com/php/php-src/pull/18879
Line 268:		Line 268:
	Voting started on 2025-07-21 and will end on 2025-08-04.		Voting started on 2025-07-21 and will end on 2025-08-04.

-	<doodle title="Accept Deprecate type juggling to and from bool type within the function type juggling context RFC?" auth="girgias" voteType="single" closed="false">	+	<doodle title="Accept Deprecate type juggling to and from bool type within the function type juggling context RFC?" auth="girgias" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

deprecate-fuzzy-and-null-casts

Anonymous (anonymous@undisclosed.example.com) — 2025-11-07T09:28:20+00:00

2025/10/29 09:36		current
Line 1:		Line 1:
-	====== PHP RFC: Deprecate Fuzzy Scalar Casts and Null Casts ======	+	====== PHP RFC: Deprecate Fuzzy Scalar Casts ======

	* Version: 1.0		* Version: 1.0
Line 12:		Line 12:
	PHP's explicit type casting operators (<php>(int)</php>, <php>(float)</php>, <php>(bool)</php>, <php>(string)</php>, <php>(array)</php>, <php>(object)</php>) have historically been maximally permissive, performing lossy conversions when the input value cannot be fully represented in the target type. This behavior, inherited from early PHP versions, creates inconsistencies between explicit casts and function parameter type checking, and can mask bugs by silently converting problematic values.		PHP's explicit type casting operators (<php>(int)</php>, <php>(float)</php>, <php>(bool)</php>, <php>(string)</php>, <php>(array)</php>, <php>(object)</php>) have historically been maximally permissive, performing lossy conversions when the input value cannot be fully represented in the target type. This behavior, inherited from early PHP versions, creates inconsistencies between explicit casts and function parameter type checking, and can mask bugs by silently converting problematic values.

-	This RFC addresses two particularly problematic categories of casts:	+	This RFC addresses a particularly problematic category of casts:

-	1. Fuzzy casts: conversions where information is lost or transformed in unexpected ways:	+	Fuzzy casts: conversions where information is lost or transformed in unexpected ways:

	<PHP>		<PHP>
Line 28:		Line 28:
	</PHP>		</PHP>

-	**2. Null casts**: conversions where <php>null</php> is coerced to type-specific default values, masking the absence of data:	+	This RFC proposes to **deprecate fuzzy casts in PHP 8.6 and make them throw <php>TypeError</php> in PHP 9.0, aligning explicit cast behavior with the existing** validation rules already used for typed function parameters in non-strict mode.

-	<PHP>	+	Important: This RFC specifically targets partial string conversions and **scalar-to-object casts**. Well-formed numeric strings (e.g., <php>"123"</php>, <php>"12.5"</php>) will continue to work as expected.
-	<?php	+
-	(int) null; // Returns 0 (null becomes zero)	+
-	(string) null; // Returns "" (null becomes empty string)	+
-	(bool) null; // Returns false (null becomes false)	+
-	(array) null; // Returns [] (null becomes empty array)	+
-	(object) null; // Returns stdClass object (null becomes empty object)	+
-	?>	+
-	</PHP>	+
-		+
-	This RFC proposes to deprecate both fuzzy casts and null casts in PHP 8.6 and make them throw <php>TypeError</php> in PHP 9.0, aligning explicit cast behavior with the existing validation rules already used for typed function parameters in non-strict mode.	+
-		+
-	Important: This RFC specifically targets partial string conversions and **null conversions**. Well-formed numeric strings (e.g., <php>"123"</php>, <php>"12.5"</php>) will continue to work as expected.	+

	===== Background and Motivation =====		===== Background and Motivation =====
Line 59:		Line 47:
	==== The Inconsistency Problem ====		==== The Inconsistency Problem ====

-	Consider these examples:	+	Consider this example:

	<PHP>		<PHP>
Line 72:		Line 60:
	// Explicit cast - permissive truncation		// Explicit cast - permissive truncation
	$result = (int) "123abc"; // 123 (no error, silently truncates "abc")		$result = (int) "123abc"; // 123 (no error, silently truncates "abc")
-	?>
-	</PHP>
-
-	<PHP>
-	<?php
-	// Function parameter type checking - rejects null
-	function calculate(int $count): void {
-	var_dump($count);
-	}
-
-	calculate(null); // TypeError: Cannot pass null to non-nullable parameter
-
-	// Explicit cast - converts null to 0
-	$result = (int) null; // 0 (no error, null becomes zero)
	?>		?>
	</PHP>		</PHP>
Line 93:		Line 67:
	==== Security and Correctness Issues ====		==== Security and Correctness Issues ====

-	Both fuzzy casts and null casts can introduce security vulnerabilities and correctness issues:	+	Fuzzy casts can introduce security vulnerabilities and correctness issues:
-		+
-	Fuzzy cast issues:	+

	<PHP>		<PHP>
Line 110:		Line 82:
	</PHP>		</PHP>

-	Null cast issues:	+	In these cases, invalid input is silently accepted instead of failing fast, making bugs harder to detect and fix.
-		+
-	<PHP>	+
-	<?php	+
-	// Ambiguity: is 0 a valid value or was it null?	+
-	$age = (int) $row['age']; // If $row['age'] is null, becomes 0	+
-	if ($age === 0) {	+
-	// Is the user a newborn, or was age missing?	+
-	}	+
-		+
-	// Logic error: null becomes falsy	+
-	$hasOptedIn = (bool) $userData['newsletter']; // null becomes false	+
-	// User never answered, but we treat it as "no"	+
-		+
-	// Data loss: null becomes empty string	+
-	$middleName = (string) $person['middle_name']; // null becomes ""	+
-	// Cannot distinguish between empty string and missing value	+
-	?>	+
-	</PHP>	+
-		+
-	In all these cases, invalid or missing input is silently accepted instead of failing fast, making bugs harder to detect and fix.	+

	==== Developer Expectations ====		==== Developer Expectations ====
Line 143:		Line 95:
	===== Current Behavior =====		===== Current Behavior =====

-	PHP's explicit scalar cast operators currently exhibit two problematic behaviors:	+	PHP's explicit scalar cast operators currently exhibit problematic fuzzy conversion behavior:

	==== Fuzzy Conversions ====		==== Fuzzy Conversions ====
Line 187:		Line 139:

	While boolean casts don't perform partial parsing, they still exhibit counterintuitive behavior where <php>"0"</php> is falsy but <php>"false"</php> is truthy.		While boolean casts don't perform partial parsing, they still exhibit counterintuitive behavior where <php>"0"</php> is falsy but <php>"false"</php> is truthy.
-
-	==== Null Conversions ====
-
-	All cast operators convert <php>null</php> to type-specific default values:
-
-	<PHP>
-	<?php
-	// Scalar conversions
-	(int) null; // 0 ⚠️ (null becomes zero)
-	(float) null; // 0.0 ⚠️ (null becomes zero)
-	(string) null; // "" ⚠️ (null becomes empty string)
-	(bool) null; // false ⚠️ (null becomes false)
-
-	// Compound type conversions
-	(array) null; // [] ⚠️ (null becomes empty array)
-	(object) null; // object(stdClass)#1 (0) {} ⚠️ (null becomes empty object)
-	?>
-	</PHP>
-
-	This behavior makes it impossible to distinguish between a legitimate value and the absence of a value:
-
-	<PHP>
-	<?php
-	$age = (int) $row['age']; // If null, becomes 0
-	// Problem: 0 could mean "newborn" or "missing data"
-
-	$name = (string) $row['name']; // If null, becomes ""
-	// Problem: "" could mean "no name" or "missing data"
-
-	$tags = (array) $row['tags']; // If null, becomes []
-	// Problem: [] could mean "no tags" or "missing data"
-	?>
-	</PHP>

	==== Comparison with Function Parameters ====		==== Comparison with Function Parameters ====

-	In contrast, typed function parameters in non-strict mode reject both malformed strings and null:	+	In contrast, typed function parameters in non-strict mode reject malformed strings:

	<PHP>		<PHP>
	<?php		<?php
	function test(int $i): int { return $i; }		function test(int $i): int { return $i; }
		+
		+	// Valid conversions - accepted
		+	test("123"); // 123 (valid numeric string)

	// Fuzzy conversions - rejected		// Fuzzy conversions - rejected
-	test("123"); // 123 (valid numeric string)
	test("123abc"); // TypeError: Cannot convert string to int		test("123abc"); // TypeError: Cannot convert string to int
-
-	// Null conversions - rejected
-	test(null); // TypeError: Cannot pass null to non-nullable parameter
	?>		?>
	</PHP>		</PHP>
Line 242:		Line 160:
	===== Proposal =====		===== Proposal =====

-	This RFC proposes a two-phase deprecation of both fuzzy scalar casts and null casts:	+	This RFC proposes a two-phase deprecation of fuzzy scalar casts:

	==== Phase 1: PHP 8.6 - Deprecation Notice ====		==== Phase 1: PHP 8.6 - Deprecation Notice ====

-	In PHP 8.6, both fuzzy casts and null casts will emit an <php>E_DEPRECATED</php> notice:	+	In PHP 8.6, fuzzy casts will emit an <php>E_DEPRECATED</php> notice when a string value can only be partially converted to the target scalar type, or when a scalar is cast to <php>(object)</php>:
-		+
-	Fuzzy casts - when a string value can only be partially converted to the target scalar type, or when a scalar is cast to <php>(object)</php>:	+
-		+
-	Null casts - when <php>null</php> is cast to any type:	+

	<PHP>		<PHP>
Line 275:		Line 189:
	(object) "hello"; // Deprecated: Conversion from string to object is deprecated		(object) "hello"; // Deprecated: Conversion from string to object is deprecated
	// Returns: stdClass Object ( [scalar] => "hello" )		// Returns: stdClass Object ( [scalar] => "hello" )
-
-	// Null casts - emit E_DEPRECATED
-	(int) null; // Deprecated: Implicit conversion from null to int is deprecated
-	// Returns: 0
-
-	(string) null; // Deprecated: Implicit conversion from null to string is deprecated
-	// Returns: ""
-
-	(array) null; // Deprecated: Implicit conversion from null to array is deprecated
-	// Returns: []
	?>		?>
	</PHP>		</PHP>

-	The deprecation notice will clearly indicate:	+	The deprecation notice will clearly indicate the original value, the target type, and the nature of the problematic conversion, and that these conversions will become errors in PHP 9.0.
-	* For fuzzy casts: The original value, the target type, and the nature of the problematic conversion	+
-	* For null casts: That the conversion from null to the target type is deprecated	+
-	* That these conversions will become errors in PHP 9.0	+

	==== Phase 2: PHP 9.0 - TypeError ====		==== Phase 2: PHP 9.0 - TypeError ====

-	In PHP 9.0, both fuzzy casts and null casts will throw a <php>TypeError</php> instead of performing conversion:	+	In PHP 9.0, fuzzy casts will throw a <php>TypeError</php> instead of performing conversion:

	<PHP>		<PHP>
Line 310:		Line 211:
	(object) 42; // TypeError: Cannot convert int to object		(object) 42; // TypeError: Cannot convert int to object
	(object) "hello"; // TypeError: Cannot convert string to object		(object) "hello"; // TypeError: Cannot convert string to object
-
-	// Null casts - throw TypeError
-	(int) null; // TypeError: Cannot convert null to int
-	(string) null; // TypeError: Cannot convert null to string
-	(bool) null; // TypeError: Cannot convert null to bool
-	(array) null; // TypeError: Cannot convert null to array
-	(object) null; // TypeError: Cannot convert null to object
	?>		?>
	</PHP>		</PHP>
Line 322:		Line 216:
	This aligns explicit cast behavior with the validation rules already used for typed function parameters in non-strict mode.		This aligns explicit cast behavior with the validation rules already used for typed function parameters in non-strict mode.

-	Note: These are not new validation rules. Function parameters in non-strict mode have rejected fuzzy conversions and null values since PHP 7.0. This RFC simply applies the same proven, consistent behavior to explicit cast operators.	+	Note: These are not new validation rules. Function parameters in non-strict mode have rejected fuzzy conversions since PHP 7.0. This RFC simply applies the same proven, consistent behavior to explicit cast operators.

	===== Scope and Affected Cases =====		===== Scope and Affected Cases =====
Line 398:		Line 292:
	// Or for boolean strings:		// Or for boolean strings:
	$enabled = filter_var($value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE);		$enabled = filter_var($value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE);
-	?>
-	</PHP>
-
-	==== What is Considered a Null Cast? ====
-
-	A null cast occurs when:
-
-	- The input value is <php>null</php>
-	- Any explicit cast operator is used on it
-
-	Examples of null casts (affected by this RFC):
-
-	<PHP>
-	<?php
-	(int) null; // ✗ Null cast to int
-	(float) null; // ✗ Null cast to float
-	(string) null; // ✗ Null cast to string
-	(bool) null; // ✗ Null cast to bool
-	(array) null; // ✗ Null cast to array
-	(object) null; // ✗ Null cast to object
-	?>
-	</PHP>
-
-	All null casts are deprecated because they mask the absence of data and create ambiguity.
-
-	Migration strategies for null handling:
-
-	<PHP>
-	<?php
-	// Option 1: Use null coalescing operator
-	$age = $row['age'] ?? 0; // Explicit default value
-
-	// Option 2: Explicit null check
-	if ($value !== null) {
-	$result = (int) $value;
-	} else {
-	// Handle null case explicitly
-	}
-
-	// Option 3: Use nullable types in function signatures
-	function process(?int $value): void {
-	if ($value === null) {
-	// Handle null explicitly
-	} else {
-	// Process non-null value
-	}
-	}
	?>		?>
	</PHP>		</PHP>
Line 458:		Line 305:
	\| String (fuzzy) \| <php>(float) "12.5foo"</php> \| 12.5 \| E_DEPRECATED + 12.5 \| TypeError \|		\| String (fuzzy) \| <php>(float) "12.5foo"</php> \| 12.5 \| E_DEPRECATED + 12.5 \| TypeError \|
	\| String (non-numeric) \| <php>(int) "abc"</php> \| 0 \| 0 \| 0 \|		\| String (non-numeric) \| <php>(int) "abc"</php> \| 0 \| 0 \| 0 \|
-	\| null \| <php>(int) null</php> \| 0 \| E_DEPRECATED + 0 \| TypeError \|
-	\| null \| <php>(string) null</php> \| "" \| E_DEPRECATED + "" \| TypeError \|
-	\| null \| <php>(bool) null</php> \| false \| E_DEPRECATED + false \| TypeError \|
-	\| null \| <php>(array) null</php> \| [] \| E_DEPRECATED + [] \| TypeError \|
-	\| null \| <php>(object) null</php> \| empty <php>stdClass</php> \| E_DEPRECATED + empty <php>stdClass</php> \| TypeError \|
	\| Scalar (fuzzy) \| <php>(object) 42</php> \| <php>stdClass</php> with <php>scalar</php> property \| E_DEPRECATED + <php>stdClass</php> \| TypeError \|		\| Scalar (fuzzy) \| <php>(object) 42</php> \| <php>stdClass</php> with <php>scalar</php> property \| E_DEPRECATED + <php>stdClass</php> \| TypeError \|
	\| Scalar (fuzzy) \| <php>(object) "hello"</php> \| <php>stdClass</php> with <php>scalar</php> property \| E_DEPRECATED + <php>stdClass</php> \| TypeError \|		\| Scalar (fuzzy) \| <php>(object) "hello"</php> \| <php>stdClass</php> with <php>scalar</php> property \| E_DEPRECATED + <php>stdClass</php> \| TypeError \|
Line 471:		Line 313:
	===== Backward Compatibility Impact =====		===== Backward Compatibility Impact =====

-	This RFC introduces backward incompatible changes that will affect existing code relying on fuzzy cast or null cast behavior.	+	This RFC introduces backward incompatible changes that will affect existing code relying on fuzzy cast behavior.

	==== Potential Impact ====		==== Potential Impact ====

-	Code that currently relies on fuzzy casts or null casts will need to be updated. Common patterns that will be affected include:	+	Code that currently relies on fuzzy casts will need to be updated. Common patterns that will be affected include:
-		+
-	Fuzzy cast patterns:	+

	<PHP>		<PHP>
Line 492:		Line 332:
	// Scalar to object wrapping		// Scalar to object wrapping
	$wrapped = (object) $someScalar; // Creates stdClass with 'scalar' property		$wrapped = (object) $someScalar; // Creates stdClass with 'scalar' property
-	?>
-	</PHP>
-
-	Null cast patterns:
-
-	<PHP>
-	<?php
-	// Database columns that may be NULL
-	$age = (int) $row['age']; // If $row['age'] is null, becomes 0
-
-	// Optional form fields
-	$middleName = (string) ($_POST['middle_name'] ?? null); // null becomes ""
-
-	// API responses with optional fields
-	$count = (int) $response['count']; // If 'count' is null, becomes 0
-
-	// Configuration with optional values
-	$maxRetries = (int) $config['max_retries']; // null becomes 0
	?>		?>
	</PHP>		</PHP>
Line 515:		Line 337:
	==== Migration Path ====		==== Migration Path ====

-	Developers have several options to migrate away from fuzzy casts and null casts:	+	Developers have several options to migrate away from fuzzy casts:
-		+
-	For fuzzy casts:	+

	Option 1: Validate before casting		Option 1: Validate before casting
Line 547:		Line 367:
	</PHP>		</PHP>

-	For null casts:	+	**Option 3: For scalar to object casts**

-	Option 1: Use null coalescing operator	+	Create a proper object structure or use an array:
-		+
-	<PHP>	+
-	<?php	+
-	// Provide explicit default value	+
-	$age = $row['age'] ?? 0; // 0 is the intended default	+
-	$name = $row['name'] ?? ''; // Empty string is the intended default	+
-	$tags = $row['tags'] ?? []; // Empty array is the intended default	+
-	?>	+
-	</PHP>	+
-		+
-	Option 2: Explicit null check	+
-		+
-	<PHP>	+
-	<?php	+
-	if ($value !== null) {	+
-	$result = (int) $value;	+
-	} else {	+
-	// Handle null case explicitly	+
-	throw new ValueError("Value cannot be null");	+
-	// Or provide a default:	+
-	// $result = 0;	+
-	}	+
-	?>	+
-	</PHP>	+
-		+
-	Option 3: Use nullable types	+
-		+
-	<PHP>	+
-	<?php	+
-	// Accept and preserve null in type system	+
-	function process(?int $value): void {	+
-	if ($value === null) {	+
-	// Handle null explicitly	+
-	} else {	+
-	// Process non-null value	+
-	}	+
-	}	+
-		+
-	// Or at variable level	+
-	$age = $row['age']; // Keep as ?int, don't cast	+
-	if ($age !== null) {	+
-	// Work with non-null int	+
-	}	+
-	?>	+
-	</PHP>	+
-		+
-	For scalar to object casts (fuzzy cast):	+
-		+
-	Option 1: Create a proper object structure	+

	<PHP>		<PHP>
Line 605:		Line 376:
	$obj = (object) 42;		$obj = (object) 42;

-	// Use:	+	// Option A: Create proper object structure
	$obj = new stdClass();		$obj = new stdClass();
	$obj->value = 42;		$obj->value = 42;

-	// Or create a proper class:	+	// Option B: Or create a proper class
	class ValueWrapper {		class ValueWrapper {
	public function __construct(public mixed $value) {}		public function __construct(public mixed $value) {}
	}		}
	$obj = new ValueWrapper(42);		$obj = new ValueWrapper(42);
-	?>
-	</PHP>

-	Option 2: Use an array if you need a key-value structure	+	// Option C: Use an array if you need a key-value structure
-		+	$data = ['value' => 42];
-	<PHP>	+
-	<?php	+
-	// Instead of:	+
-	$obj = (object) "hello";	+
-		+
-	// Use:	+
-	$data = ['value' => 'hello'];	+
	// Or if object is required:		// Or if object is required:
-	$obj = (object) ['value' => 'hello'];	+	$obj = (object) ['value' => 42];
-	?>	+
-	</PHP>	+

-	Option 3: Question whether object wrapping is necessary	+	// Option D: Question whether object wrapping is necessary
-		+
-	<PHP>	+
-	<?php	+
	// Often, the scalar value can be used directly		// Often, the scalar value can be used directly
-	// Instead of:	+	processValue(42); // Instead of processObject((object) 42)
-	$obj = (object) $count;	+
-	processObject($obj);	+
-		+
-	// Consider:	+
-	processValue($count);	+
	?>		?>
	</PHP>		</PHP>
Line 647:		Line 399:
	==== Detection and Tooling ====		==== Detection and Tooling ====

-	To help developers identify fuzzy casts and null casts in their codebase:	+	To help developers identify fuzzy casts in their codebase:

	* PHP 8.6: The deprecation notices will appear in error logs, making it easy to find affected code		* PHP 8.6: The deprecation notices will appear in error logs, making it easy to find affected code
-	* Static analysis tools: Tools like PHPStan and Psalm can be updated to detect potential fuzzy casts and null casts	+	* Static analysis tools: Tools like PHPStan and Psalm can be updated to detect potential fuzzy casts
-	* Code review: Search for cast patterns like <php>(int)</php>, <php>(float)</php>, <php>(string)</php>, <php>(object)</php> applied to variables that may be null or contain malformed data	+	* Code review: Search for cast patterns like <php>(int)</php>, <php>(float)</php>, <php>(object)</php> applied to variables that may contain malformed data

	===== Rationale =====		===== Rationale =====
Line 663:		Line 415:
	==== Why These Specific Cases? ====		==== Why These Specific Cases? ====

-	This RFC focuses specifically on fuzzy casts (including partial string conversions and scalar to object casts) and null casts because:	+	This RFC focuses specifically on fuzzy casts (including partial string conversions and scalar to object casts) because:

-	* These are the cases where explicit casts diverge from function parameter validation in non-strict mode	+	* These are cases where explicit casts diverge from function parameter validation in non-strict mode
-	* They represent the most problematic cases (silent data loss and ambiguity)	+	* They represent problematic cases of silent data loss
-	* They are the most likely to mask bugs and cause subtle errors	+	* They are likely to mask bugs and cause subtle errors
	* Function parameters already reject these conversions, providing a proven precedent		* Function parameters already reject these conversions, providing a proven precedent

Line 673:		Line 425:
	* Partial string conversions discard trailing data, making malformed input appear valid		* Partial string conversions discard trailing data, making malformed input appear valid
	* Scalar to object casts create objects with an arbitrary <php>scalar</php> property that has no meaningful semantic value		* Scalar to object casts create objects with an arbitrary <php>scalar</php> property that has no meaningful semantic value
-
-	Null casts make it impossible to distinguish between legitimate values (0, "", [], false) and missing data (null).

	Other cast behaviors (e.g., <php>(int) "abc"</php> returning 0) are not addressed by this RFC because:		Other cast behaviors (e.g., <php>(int) "abc"</php> returning 0) are not addressed by this RFC because:
	* They are well-documented and widely understood		* They are well-documented and widely understood
	* They don't involve data loss (the entire string is "consumed")		* They don't involve data loss (the entire string is "consumed")
-	* They don't create ambiguity about data presence
	* Changing them would require broader discussion and different tradeoffs		* Changing them would require broader discussion and different tradeoffs

Line 700:		Line 449:
	===== Examples and Use Cases =====		===== Examples and Use Cases =====

-	==== Example 1: Database Column with NULL ====	+	==== Example 1: Database Column with Corruption ====
-		+
-	<PHP>	+
-	<?php	+
-	// Current behavior - null becomes 0, creating ambiguity	+
-	$row = ['age' => null];	+
-	$age = (int) $row['age']; // 0 (is this a newborn or missing data?)	+
-		+
-	if ($age === 0) {	+
-	echo "Baby!"; // Wrong! This is actually missing data	+
-	}	+
-		+
-	// PHP 8.6 - deprecation notice	+
-	$age = (int) $row['age'];	+
-	// Deprecated: Implicit conversion from null to int is deprecated	+
-		+
-	// PHP 9.0 - explicit error	+
-	$age = (int) $row['age'];	+
-	// TypeError: Cannot convert null to int	+
-		+
-	// Recommended migration - explicit null handling	+
-	$age = $row['age'] ?? throw new RuntimeException("Age is required");	+
-	// Or with default:	+
-	$age = $row['age'] ?? 0; // Explicitly choosing 0 as default	+
-	?>	+
-	</PHP>	+
-		+
-	==== Example 2: Database Column with Corruption ====	+

	<PHP>		<PHP>
Line 751:		Line 473:
	</PHP>		</PHP>

-	==== Example 3: API Response with Units ====	+	==== Example 2: API Response with Units ====

	<PHP>		<PHP>
Line 772:		Line 494:
	</PHP>		</PHP>

-	==== Example 4: Configuration with Sanitization ====	+	==== Example 3: Configuration with Sanitization ====

	<PHP>		<PHP>
Line 797:		Line 519:
	===== Proposed PHP Version =====		===== Proposed PHP Version =====

-	* PHP 8.6: Emit <php>E_DEPRECATED</php> for fuzzy casts and null casts	+	* PHP 8.6: Emit <php>E_DEPRECATED</php> for fuzzy casts
-	* PHP 9.0: Throw <php>TypeError</php> for fuzzy casts and null casts	+	* PHP 9.0: Throw <php>TypeError</php> for fuzzy casts

	===== Voting Choices =====		===== Voting Choices =====

-	These are 2 simple yes/no vote requiring a 2/3 majority.	+	This is a simple yes/no vote requiring a 2/3 majority.

	<doodle title="Accept deprecation of fuzzy scalar casts for PHP 8.6/9.0?" voteType="single" closed="false">		<doodle title="Accept deprecation of fuzzy scalar casts for PHP 8.6/9.0?" voteType="single" closed="false">
-	* Yes
-	* No
-	* Abstain
-	</doodle>
-
-	<doodle title="Accept deprecation of null cast for PHP 8.6/9.0?" voteType="single" closed="false">
	* Yes		* Yes
	* No		* No

deprecate-fuzzy-casts

Anonymous (anonymous@undisclosed.example.com) — 2026-01-26T09:00:06+00:00

2026/01/26 08:53		current
Line 1:		Line 1:
-	====== PHP RFC: Deprecate Fuzzy Type Casts ======	+	====== PHP RFC: Deprecate Fuzzy Type Casts and Allow Stringable in Strict Mode ======

	* Version: 1.0		* Version: 1.0
Line 5:		Line 5:
	* Author: Alexandre Daubois <alexandredaubois@php.net>, Nicolas Grekas <nicolasgrekas@php.net>		* Author: Alexandre Daubois <alexandredaubois@php.net>, Nicolas Grekas <nicolasgrekas@php.net>
	* Status: Under discussion		* Status: Under discussion
-	* Target Version: PHP 8.6 (deprecation), PHP 9.0 (TypeError)	+	* Target Version: PHP 8.6 (deprecation and Stringable support), PHP 9.0 (TypeError)
	* Implementation: https://github.com/alexandre-daubois/php-src/pull/16		* Implementation: https://github.com/alexandre-daubois/php-src/pull/16

	===== Summary =====		===== Summary =====

-	This RFC seeks to address inconsistencies in scalar conversion behavior where explicit casts can perform lossy conversions ("fuzzy casts"), silently discarding part of the input.	+	This RFC seeks to address two differences in scalar conversion behavior:

-	This RFC proposes:	+	* Explicit casts can perform lossy conversions ("fuzzy casts"), silently discarding part of the input.
		+	* In strict typing mode (<php>declare(strict_types=1)</php>), <php>string</php> type declarations reject <php>Stringable</php> values even though they have a well-defined string representation.

-	* PHP 8.6: emit <php>E_DEPRECATED</php> for fuzzy casts.	+	This RFC changes both behaviors:
		+
		+	* PHP 8.6: emit <php>E_DEPRECATED</php> for fuzzy casts; accept <php>Stringable</php> for <php>string</php> parameters in strict mode.
	* PHP 9.0: throw <php>TypeError</php> for fuzzy casts.		* PHP 9.0: throw <php>TypeError</php> for fuzzy casts.

	===== Introduction =====		===== Introduction =====

-	PHP's type conversion system contains differences between explicit casts and scalar type checks.	+	PHP's type conversion system contains differences between explicit casts and scalar type checks. This RFC addresses two issues:
		+
		+	Issue 1: Fuzzy Casts

	PHP's explicit cast operators can discard part of the input when it cannot be fully represented in the target type:		PHP's explicit cast operators can discard part of the input when it cannot be fully represented in the target type:
Line 28:		Line 33:
	(float) "12.34foo"; // 12.34 (discards "foo")		(float) "12.34foo"; // 12.34 (discards "foo")
	(object) 42; // stdClass { scalar: 42 }		(object) 42; // stdClass { scalar: 42 }
		+	?>
		+	</PHP>
		+
		+	Issue 2: Stringable Objects in Strict Mode
		+
		+	Strict mode rejects <php>Stringable</php> objects for <php>string</php> parameters, despite <php>Stringable</php> being an explicit contract for safe string conversion:
		+
		+	<PHP>
		+	<?php
		+	declare(strict_types=1);
		+
		+	function process(string $value): void { }
		+
		+	$obj = new class implements Stringable {
		+	public function __toString(): string { return "hello"; }
		+	};
		+
		+	process($obj); // TypeError (works in non-strict mode)
	?>		?>
	</PHP>		</PHP>
Line 39:		Line 62:

	===== Motivation =====		===== Motivation =====
		+
		+	==== Fuzzy Casts ====

	Since PHP 7.0, scalar type declarations in the default typing mode reject partial string conversions (<php>process("123abc")</php> throws <php>TypeError</php>), yet explicit casts can truncate (<php>(int) "123abc"</php> returns 123). This difference has several effects:		Since PHP 7.0, scalar type declarations in the default typing mode reject partial string conversions (<php>process("123abc")</php> throws <php>TypeError</php>), yet explicit casts can truncate (<php>(int) "123abc"</php> returns 123). This difference has several effects:
Line 49:		Line 74:
	Making explicit casts follow the same acceptance rules as scalar type checks reduces the incentive to "cast to make it pass" and encourages either valid coercion or explicit parsing.		Making explicit casts follow the same acceptance rules as scalar type checks reduces the incentive to "cast to make it pass" and encourages either valid coercion or explicit parsing.
	This reduces the number of conversion rules that need to be remembered and reduces reliance on explicit casts to satisfy scalar type declarations.		This reduces the number of conversion rules that need to be remembered and reduces reliance on explicit casts to satisfy scalar type declarations.
		+
		+	==== Stringable Objects in Strict Mode ====
		+
		+	In strict typing mode, passing a <php>Stringable</php> object to a <php>string</php> parameter throws <php>TypeError</php>. In the default typing mode, the same call is accepted.
		+
		+	This results in patterns such as:
		+
		+	* using unions like <php>string\|Stringable</php> and casting manually, or
		+	* requiring callers to cast with <php>(string) $value</php>.
		+
		+	This RFC proposes accepting <php>Stringable</php> in strict mode for <php>string</php> parameters, as part of reducing special cases in conversion behavior.
		+
		+	This also matches the longer-term direction of reducing the gap between typing modes (see the [[https://github.com/Girgias/unify-typing-modes-rfc\|Unify PHP's typing modes]] gist).

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

-	=== Phase 1: PHP 8.6 - Deprecation ===	+	==== Fuzzy Scalar Casts ====

-	Important note: These behaviors are not arbitrary decisions. The proposed validation rules already exist for function arguments, regardless of the mode strictness.	+	=== Phase 1: PHP 8.6 - Deprecation ===

	Fuzzy casts emit <php>E_DEPRECATED</php>:		Fuzzy casts emit <php>E_DEPRECATED</php>:
Line 84:		Line 122:

	This aligns explicit casts with scalar type coercion rules used by the engine in the default (coercive) typing mode.		This aligns explicit casts with scalar type coercion rules used by the engine in the default (coercive) typing mode.
		+
		+	==== Stringable Objects in Strict Mode ====
		+
		+	=== PHP 8.6 ===
		+
		+	Strict mode will accept <php>Stringable</php> objects for <php>string</php> parameters, converting them via <php>__toString()</php>:
		+
		+	<PHP>
		+	<?php
		+	declare(strict_types=1);
		+
		+	function greet(string $name): string { return "Hello, $name!"; }
		+
		+	$user = new class implements Stringable {
		+	public function __toString(): string { return "John"; }
		+	};
		+
		+	greet($user); // PHP 8.5: TypeError, PHP 8.6: "Hello, John!"
		+	?>
		+	</PHP>
		+
		+	No deprecation in PHP 8.6; this is a relaxation of strict mode restrictions.

	===== Scope and Affected Cases =====		===== Scope and Affected Cases =====

	The proposed fuzzy cast rules align with existing validation used by scalar type declarations in the default (coercive) typing mode since PHP 7.0.		The proposed fuzzy cast rules align with existing validation used by scalar type declarations in the default (coercive) typing mode since PHP 7.0.
-
-	Important note: These behaviors are not arbitrary decisions. The proposed validation rules already exist for function arguments, regardless of the mode strictness.

	^ Input ^ Cast ^ Current ^ PHP 8.6 ^ PHP 9.0 ^		^ Input ^ Cast ^ Current ^ PHP 8.6 ^ PHP 9.0 ^
Line 100:		Line 158:
	\| <php>['a'=>1]</php> \| <php>(object)</php> \| <php>stdClass{a:1}</php> \| Unchanged \| Unchanged \|		\| <php>['a'=>1]</php> \| <php>(object)</php> \| <php>stdClass{a:1}</php> \| Unchanged \| Unchanged \|
	\| <php>"false"</php> \| <php>(bool)</php> \| true \| Unchanged \| Unchanged \|		\| <php>"false"</php> \| <php>(bool)</php> \| true \| Unchanged \| Unchanged \|
		+	\| Stringable (non-strict mode) \| String parameter \| Converts \| Converts \| — \|
		+	\| Stringable (strict mode) \| String parameter \| TypeError \| Converts \| — \|

	Note: Boolean casts use truthiness rules, not numeric parsing, they are unaffected. Float-to-int precision loss (<php>(int) 12.5</php>) is covered by [[rfc:implicit-float-int-deprecate\|a separate RFC]].		Note: Boolean casts use truthiness rules, not numeric parsing, they are unaffected. Float-to-int precision loss (<php>(int) 12.5</php>) is covered by [[rfc:implicit-float-int-deprecate\|a separate RFC]].

	===== Backward Compatibility Impact =====		===== Backward Compatibility Impact =====
		+
		+	==== Fuzzy Casts ====

	Affected patterns:		Affected patterns:
Line 141:		Line 203:

	Deprecation notices in PHP 8.6 will identify affected code. Static analysis tools (PHPStan, Psalm) can also detect these patterns.		Deprecation notices in PHP 8.6 will identify affected code. Static analysis tools (PHPStan, Psalm) can also detect these patterns.
		+
		+	==== Stringable in Strict Mode ====
		+
		+	Code that relies on strict mode rejecting <php>Stringable</php> objects will need adjustment. This is expected to be rare.

	===== Related Functions =====		===== Related Functions =====
Line 150:		Line 216:
	===== Proposed PHP Version =====		===== Proposed PHP Version =====

-	* PHP 8.6: Emit <php>E_DEPRECATED</php> for fuzzy casts	+	* PHP 8.6: Emit <php>E_DEPRECATED</php> for fuzzy casts; accept <php>Stringable</php> for string parameters in strict mode
	* PHP 9.0: Throw <php>TypeError</php> for fuzzy casts		* PHP 9.0: Throw <php>TypeError</php> for fuzzy casts

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

-	Testing against the Symfony codebase raised only a few dozen deprecations across components, bundles, and bridges.	+	Testing against the Symfony codebase raised only a few dozen deprecations across components, bundles, and bridges. Symfony doesn't use strict types, so no impact from the <php>Stringable</php> change.

	===== Vote =====		===== Vote =====
Line 161:		Line 227:
	Single yes/no vote requiring 2/3 majority.		Single yes/no vote requiring 2/3 majority.

-	<doodle title="Deprecate fuzzy casts in PHP 8.6?" voteType="single" closed="false">	+	<doodle title="Deprecate fuzzy casts and allow Stringable in strict mode in PHP 8.6?" voteType="single" closed="false">
	* Yes		* Yes
	* No		* No
Line 176:		Line 242:
	* PHP filter_var() Documentation: https://www.php.net/manual/en/function.filter-var.php		* PHP filter_var() Documentation: https://www.php.net/manual/en/function.filter-var.php
	* RFC: Deprecate implicit float to int conversions: https://wiki.php.net/rfc/implicit-float-int-deprecate		* RFC: Deprecate implicit float to int conversions: https://wiki.php.net/rfc/implicit-float-int-deprecate
		+	* Unify PHP's typing modes (context/motivation): https://github.com/Girgias/unify-typing-modes-rfc
	* Discussion thread: https://news-web.php.net/php.internals/129884		* Discussion thread: https://news-web.php.net/php.internals/129884

deprecate-get-post-sessions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/04/23 17:01		current
Line 4:		Line 4:
	* Date: 2024-03-03		* Date: 2024-03-03
	* Authors: Kamil Tekiela <dharman@php.net>		* Authors: Kamil Tekiela <dharman@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.4		* Target Version: PHP 8.4
	* Implementation: https://github.com/php/php-src/pull/13578		* Implementation: https://github.com/php/php-src/pull/13578
Line 81:		Line 81:
	</doodle>		</doodle>

		+	===== Implementation =====

		+	- merged into ''master'' (will become PHP-8.4)
		+	- merged as [[https://github.com/php/php-src/commit/c5bce0d8a2e6794cd6809e4047dd1f488fa3459b]]
		+	- documentation update pending

deprecate-implicitly-nullable-types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/03/13 18:22		current
Line 4:		Line 4:
	* Date: 2023-12-20		* Date: 2023-12-20
	* Authors: Máté Kocsis <kocsismate@php.net>, Gina Peter Banyard <girgias@php.net>		* Authors: Máté Kocsis <kocsismate@php.net>, Gina Peter Banyard <girgias@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.4		* Target Version: PHP 8.4
	* Implementation: [[https://github.com/php/php-src/pull/12959\|https://github.com/php/php-src/pull/12959]]		* Implementation: [[https://github.com/php/php-src/pull/12959\|https://github.com/php/php-src/pull/12959]]

deprecate-incomplete-class-instantiation

Anonymous (anonymous@undisclosed.example.com) — 2026-03-03T18:11:20+00:00

2026/03/03 17:53		current
Line 106:		Line 106:
	===== References =====		===== References =====

-	Links to external references, discussions, or RFCs.	+	* Mailing List Discussion: https://news-web.php.net/php.internals/130246

	===== Rejected Features =====		===== Rejected Features =====

deprecate-inconsistent-cast-keywords

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/12/07 16:16		current
Line 3:		Line 3:
	* Date: 2017-12-07		* Date: 2017-12-07
	* Author: Chris Wright <daverandom@php.net>		* Author: Chris Wright <daverandom@php.net>
-	* Status: Draft	+	* Status: Inactive
	* First Published at: https://wiki.php.net/rfc/deprecate-inconsistent-cast-keywords		* First Published at: https://wiki.php.net/rfc/deprecate-inconsistent-cast-keywords

deprecate-ini-functions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 5:		Line 5:
	* Modified Date: 2014-03-13		* Modified Date: 2014-03-13
	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>		* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>
-	* Status: Draft	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/deprecate-ini-functions		* First Published at: http://wiki.php.net/rfc/deprecate-ini-functions

deprecate-json_encode-nonserializable

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/09/05 08:44		current
Line 1:		Line 1:
	====== PHP RFC: Deprecate json_encode() on classes marked as non-serializable ======		====== PHP RFC: Deprecate json_encode() on classes marked as non-serializable ======
-	* Version: 0.10	+	* Version: 0.11
	* Date: 2024-09-05		* Date: 2024-09-05
	* Author: Philip Hofstetter, phofstetter@sensational.ch		* Author: Philip Hofstetter, phofstetter@sensational.ch
Line 45:		Line 45:
	At the time of writing this RFC, the following list of classes (and their subclasses) are affected by this RFC and calling <php>json_encode()</php> on them will throw a deprecation warning in the future.		At the time of writing this RFC, the following list of classes (and their subclasses) are affected by this RFC and calling <php>json_encode()</php> on them will throw a deprecation warning in the future.

-	Most of them are currently json-encoded as ''%%{}%%'', no matter what they represent internally (some of these, like <php>PDOStatement</php> have public properties which are present in the output of <php>json_encode()</php>).	+	Some of those are containers of a sort, where this encoding is especially misleading (aside of <php>Generator</php> which was the motivator for this RFC, <php>WeakMap</php> stands out specifically).
		+
		+	Most of the non-serializable classes have no public properties and thus encode as ''%%{}%%''.
		+
		+	Those which currently do have public properties are still mostly meant for internal usage and thus not ideal candidates to <php>json_encode()</php> them. However, if code wants to explicitly turn any such instances into JSON in light of the deprecation currently proposed, casting such instances into <php>array</php> before JSON encoding them is a valid workaround.
		+
		+	<code php>
		+	$a = new SimpleXmlElement('<a><b>3</b><c>foo</c></a>');
		+	echo json_encode($a); // {"b":"3","c":"foo"}, with deprecation warning
		+	echo json_enode((array) $a); // {"b":"3","c":"foo"}, no deprecation warning
		+	</code>
		+
		+	=== Classes with public fields appearing in json_encode() output ===
		+	* CURLFile (has three public properties)
		+	* PDORow (has one public property, queryString)
		+	* PDOStatement (has one public property, queryString)
		+	* SimpleXMLElement (might be useful)
		+	* ReflectionAttribute
		+	* ReflectionClass
		+	* ReflectionClassConstant
		+	* ReflectionConstant
		+	* ReflectionExtension
		+	* ReflectionFiber
		+	* ReflectionFunctionAbstract
		+	* ReflectionGenerator
		+	* ReflectionParameter
		+	* ReflectionProperty
		+	* ReflectionReference
		+	* ReflectionType
		+	* ReflectionZendExtension

-	Some of those are containers of a sort, where this encoding is especially misleading (aside of <php>Generator</php> which was the motivator for this RFC, <php>WeakMap</php> stands out specifically)

	=== Backed by temporary resources ===		=== Backed by temporary resources ===
	* AddressInfo		* AddressInfo
-	* CURLFile
	* Collator		* Collator
	* CurlHandle		* CurlHandle
	* CurlMultiHandle		* CurlMultiHandle
	* CurlShareHandle		* CurlShareHandle
-	* DOMXPath
	* DOMXPath		* DOMXPath
	* Dba\Connection		* Dba\Connection
Line 64:		Line 90:
	* Dom\TokenList		* Dom\TokenList
	* Dom\XPath		* Dom\XPath
		+	* Dom\XMLDocument
	* EnchantBroker		* EnchantBroker
	* EnchantDictionary		* EnchantDictionary
Line 93:		Line 120:
	* OpenSSLCertificateSigningRequest		* OpenSSLCertificateSigningRequest
	* PDO		* PDO
-	* PDORow
-	* PDOStatement
	* Pdo\Dblib		* Pdo\Dblib
	* Pdo\Firebird		* Pdo\Firebird
Line 110:		Line 135:
	* SQLite3Stmt		* SQLite3Stmt
	* Shmop		* Shmop
-	* SimpleXMLElement
	* Soap\Sdl		* Soap\Sdl
	* Soap\Url		* Soap\Url
Line 130:		Line 154:
	* Generator		* Generator
	* InternalIterator		* InternalIterator
-	* ReflectionAttribute
-	* ReflectionClass
-	* ReflectionClassConstant
-	* ReflectionConstant
-	* ReflectionExtension
-	* ReflectionFiber
-	* ReflectionFunctionAbstract
-	* ReflectionGenerator
-	* ReflectionParameter
-	* ReflectionProperty
-	* ReflectionReference
-	* ReflectionType
-	* ReflectionZendExtension
	* SensitiveParameterValue		* SensitiveParameterValue
	* WeakMap		* WeakMap
	* WeakReference		* WeakReference
		+

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

deprecate-pear-include-composer

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/09/08 14:56		current
Line 14:		Line 14:
	===== Proposal =====		===== Proposal =====

-	As PEAR becomes less relevant, we should deprecate it in favor of more modern, community chosen tools — specifically composer.	+	As PEAR becomes less relevant, we should deprecate bundling it in favor of more modern, community chosen tools — specifically composer.

	PEAR however also comprises PECL, so this RFC also proposes that we move to [[https://github.com/FriendsOfPHP/pickle\|pickle]], an alternative written (primarily) by Anatol Belski and Pierre Joye. Pickle is based on composer and backwards compatible with pecl packages as well as supporting RCS systems similar to composer.		PEAR however also comprises PECL, so this RFC also proposes that we move to [[https://github.com/FriendsOfPHP/pickle\|pickle]], an alternative written (primarily) by Anatol Belski and Pierre Joye. Pickle is based on composer and backwards compatible with pecl packages as well as supporting RCS systems similar to composer.

-	We would like to deprecate pear/pecl in 7.2, and unbundle them in 8.0. At the same time, we'd like to include composer/pickle as //optional// (under build flags ''--with-composer'' and ''--with-pickle'') for 7.2, then enabled by default in 7.3.	+	We would like to deprecate bundling pear/pecl in 7.2, and unbundle them in 8.0. At the same time, we'd like to include composer/pickle as //optional// (under build flags ''--with-composer'' and ''--with-pickle'') for 7.2, then enabled by default in 7.3.

	The deprecation would come in the form of updating documentation on php.net (e.g. [[http://php.net/manual/en/configure.about.php\|configure flags]]) and with a notice at the end of ./configure and during the "make" steps.		The deprecation would come in the form of updating documentation on php.net (e.g. [[http://php.net/manual/en/configure.about.php\|configure flags]]) and with a notice at the end of ./configure and during the "make" steps.

deprecate-png-jpeg-2wbmp

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 54:		Line 54:
	- PR #2164 has been merged into master (what is supposed to become PHP-7.2) with https://github.com/php/php-src/commit/189bbb58		- PR #2164 has been merged into master (what is supposed to become PHP-7.2) with https://github.com/php/php-src/commit/189bbb58
	- The deprecation and removal has been documented with http://svn.php.net/viewvc?view=revision&revision=341003		- The deprecation and removal has been documented with http://svn.php.net/viewvc?view=revision&revision=341003
		+	- [[http://git.php.net/?p=php-src.git;a=commit;h=e9736638828f3037b1b04fc02718d8d04351f9e0\|Removed for PHP 8]]
	- The language specification is not affected by this RFC		- The language specification is not affected by this RFC

deprecate-uniqid

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/05/10 14:25		current
Line 10:		Line 10:

	===== Proposal =====		===== Proposal =====
-	This RFC proposes to emit deprecation warnings for any usage of ''uniqid()''. Current usages should be replaced with either ''random_bytes()'' (in combination with ''bin2hex()'' or any other encoding of choice) or an UUID implementation of the developer's choice.	+	This RFC proposes to emit deprecation warnings for any usage of ''uniqid()''. Current usages should be replaced with either ''bin2hex(random_bytes(16))'' (or any other encoding of choice) or an UUID implementation.

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

deprecate-unuseful-crypt-constants

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/03/04 10:48		current
Line 2:		Line 2:
	* Version: 0.9		* Version: 0.9
	* Date: 2023-03-04		* Date: 2023-03-04
-	* Author: Michael Voříšek, vorismi3@fjfi.cvut.cz	+	* Author: -
-	* Status: Draft	+	* Status: Withdrawn, replaced by https://wiki.php.net/rfc/deprecations_php_8_3
	* Implementation: https://github.com/php/php-src/pull/10773		* Implementation: https://github.com/php/php-src/pull/10773

deprecated_attribute

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/07/02 07:46		current
Line 4:		Line 4:
	* Date: 2024-05-04		* Date: 2024-05-04
	* Author: Benjamin Eberlei, Tim Düsterhus		* Author: Benjamin Eberlei, Tim Düsterhus
-	* Status: Accepted	+	* Status: Implemented
		+	* Target Version: PHP 8.4
		+	* Implementation: https://github.com/php/php-src/commit/72c874691b99a88feada151fca337ff9e471c31e, https://github.com/php/php-src/commit/29f98e748568ebd66aaae061c0dcefbba92ca058
	* First Published at: http://wiki.php.net/rfc/deprecated_attribute		* First Published at: http://wiki.php.net/rfc/deprecated_attribute

Line 281:		Line 283:
	===== Implementation =====		===== Implementation =====

-	* Attribute: https://github.com/php/php-src/commit/72c874691b99a88feada151fca337ff9e471c31e	+	* Creating the Attribute: https://github.com/php/php-src/commit/72c874691b99a88feada151fca337ff9e471c31e
		+	* Using the Attribute in Stubs: https://github.com/php/php-src/commit/29f98e748568ebd66aaae061c0dcefbba92ca058

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

deprecated_traits

Anonymous (anonymous@undisclosed.example.com) — 2025-09-05T19:31:39+00:00

2025/08/08 01:11		current
Line 3:		Line 3:
	* Date: 2025-07-05		* Date: 2025-07-05
	* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com		* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com
-	* Status: Pending implementation / landing	+	* Status: Implemented
	* Implementation: https://github.com/php/php-src/pull/19045		* Implementation: https://github.com/php/php-src/pull/19045

deprecated-modifier

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2012-12-25		* Date: 2012-12-25
	* Author: Yussuf Khalil <dev@pp3345.de>		* Author: Yussuf Khalil <dev@pp3345.de>
-	* Status: Inactive	+	* Status: Obsolete
	* First Published at: https://wiki.php.net/rfc/deprecated-modifier		* First Published at: https://wiki.php.net/rfc/deprecated-modifier
		+
		+	> This proposal has been superseded by [[rfc:deprecated_attribute\|#[\Deprecated] Attribute]], which has been implemented in PHP 8.4.

	===== Introduction =====		===== Introduction =====

deprecations_php_7_1

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/10/29 16:21		current
Line 1:		Line 1:
-	====== PHP RFC: Deprecations for PHP 7.2 ======	+	====== PHP RFC: Deprecations for PHP 7.1 ======
-	* Date: 2015-12-28	+
-	* Author: Nikita Popov <nikic@php.net>	+
-	* Status: Under Discussion	+
-	* Discussion: http://markmail.org/message/axruwwohcjwxsjem	+

-	===== Introduction =====	+	Superseded by [[https://wiki.php.net/rfc/deprecations_php_7_2]].
-		+
-	This is a draft RFC for multiple deprecations targeting PHP 7.2. The RFC proposes to deprecate the listed functionality in PHP 7.2 and remove it no later than in PHP 8.0.	+
-		+
-	The following list provides a short overview of the functionality targeted for deprecation, while more detailed explanation is provided in the Proposal section:	+
-		+
-	* ''%%__autoload%%''	+
-	* ''$php_errormsg''	+
-	* ''create_function()''	+
-	* ''mbstring.func_overload''	+
-	* ''(unset)'' cast	+
-	* ''parse_str()'' without second argument	+
-	* ''gmp_random()''	+
-	* ''(binary)'' cast and ''%%b""%%'' literals	+
-	* ''each()''	+
-	* ''assert()'' with string argument	+
-	* ''$errcontext'' argument of error handler	+
-		+
-	===== Proposal =====	+
-		+
-	==== __autoload ====	+
-		+
-	The magic [[http://php.net/__autoload\|__autoload]] function has been superseded by [[http://php.net/spl_autoload_register\|spl_autoload_register]] in PHP 5.1 and its use discouraged in the documentation. One primary advantage of ''spl_autoload_register()'' is the ability to provide multiple chained autoloaders, thus easing library interoperability. Both mechanism are mutually exclusive, i.e. code using ''%%__autoload()%%'' cannot interoperate with code using ''spl_autoload_register()''. As the latter is much more commonly used and also employed by Composer, the ''%%__autoload()%%'' mechanism has only very limited applicability nowadays.	+
-		+
-	Proposed action: A deprecation notice is thrown when a global function with name ''%%__autoload()%%'' is encountered during compilation.	+
-		+
-	==== $php_errormsg ====	+
-		+
-	The [[http://php.net/manual/en/reserved.variables.phperrormsg.php\|$php_errormsg]] variable is created in the local scope whenever a non-fatal error is thrown, if the ''track_errors'' ini setting is enabled (disabled by default) and the error has not been consumed by an error handler.	+
-		+
-	Apart from being ini-dependent language behavior, this behavior is highly magic and the [[http://php.net/error_get_last\|error_get_last]] function provides a cleaner way of retrieving the last error. Since PHP 7 additionally the [[http://php.net/manual/en/function.error-clear-last.php\|error_clear_last]] function is available, thus covering the last possible use-cases for ''$php_errormsg'' without magic scope manipulation.	+
-		+
-	Proposed action: A deprecation notice is thrown if the ''track_errors'' ini setting is enabled.	+
-		+
-	==== create_function() ====	+
-		+
-	[[http://php.net/create_function\|create_function()]] is a thin wrapper around the ''eval()'' language construct, allowing the creation of a function with a generated function name and the argument list and body code provided as string arguments. Before the introduction of closures in PHP 5.3 it provided a way to create something akin to lambda functions.	+
-		+
-	Due to the nature of its operation ''create_function()'', apart from being a potential source of security issues, has very bad performance and memory usage characteristics and the use of real closures is in every way preferable.	+
-		+
-	Proposed action: Mark the function as deprecated, thus issuing a deprecation notice on every call.	+
-		+
-	==== mbstring.func_overload ====	+
-		+
-	The [[http://php.net/manual/en/mbstring.overload.php\|mbstring.func_overload]] ini setting allows replacing a certain subset of string functions with analogs from the mbstring extension. For example ''strlen()'' will no longer return the length of a string in bytes, instead it will return the length in code points according to the currently selected internal encoding.	+
-		+
-	This implies that code using mbstring.func_overload is incompatible with practically all other code, which is written under the assumption that basic string operations work normally. Some libraries outright forbid func_overload (e.g. Symfony), others will break in more subtle ways. Code that wants to support func_overload needs to conditionally switch between ordinary string functions and mbstring functions with 8bit encoding (however only cryptography libraries normally bother to do this).	+
-		+
-	In a previous [[http://markmail.org/message/vckycqqppwxhp2gk\|discussion on this topic]] the consensus was to deprecate this functionality. The original author of the extension also recommended this action.	+
-		+
-	Proposed action: Throw a deprecation notice if ''mbstring.func_overload'' is set to a non-zero value.	+
-		+
-	Tracking bug: [[https://bugs.php.net/bug.php?id=65785\|#65785]]	+
-		+
-	==== (unset) cast ====	+
-		+
-	The [[http://php.net/manual/en/language.types.null.php#language.types.null.casting\|(unset) cast]] casts a value to null. This means that ''(unset) expr'' is simply an expression that always returns null and has no other side effects. Apart from being useless, this behavior is also confusing, as many people reasonably assume that ''(unset) $a'' will behave similarly to ''unset($a)'', while in truth it does no such thing.	+
-		+
-	Proposed action: Throw a deprecation notice if an ''(unset)'' cast is encountered by the compiler. No deprecation notice is thrown from the lexer or parser themselves (so that ''token_get_all'' continues working as is).	+
-		+
-	==== parse_str() without second argument ====	+
-		+
-	The [[http://php.net/parse_str\|parse_str()]] function is used to parse a query string either into an array if the second argument is used, or into the local symbol table if it is not used.	+
-		+
-	The second behavior is a remnant from the dark age of register_globals. It suffers from many of the same problems and presents a major security hazard if used on user-provided data.	+
-		+
-	Proposed action: Throw a deprecation notice if the second argument of ''parse_str()'' is not used.	+
-		+
-	==== gmp_random() ====	+
-		+
-	The [[http://php.net/gmp_random\|gmp_random()]] function returns a random GMP number between ''0'' and ''%%2*($nBITS_PER_LIMB)-1%%'', where ''$n'' is the function argument and ''BITS_PER_LIMB'' is a platform-specific parameter of the GMP/MPIR implementation that is not exposed to userland. As such, use of this function requires guessing the limb size and will likely have a platform dependence.	+
-		+
-	To remedy this PHP 5.6 introduced the [[http://php.net/manual/en/function.gmp-random-bits.php\|gmp_random_bits()]] and [[http://php.net/manual/en/function.gmp-random-range.php\|gmp_random_range()]] functions, which allow precise control of the used random number range. These functions should always be preferred over ''gmp_random()''.	+
-		+
-	Proposed action: Mark the function as deprecated, thus issuing a deprecation notice on every call.	+
-		+
-	==== (binary) cast and b"" literals ====	+
-		+
-	The binary cast and binary string literals were originally introduced as forward-compatibility features for PHP 6. Currently they behave identically to ordinary (string) casts and ordinary string literals. Given that PHP 6 has been dead for years and it is unlikely that it will be resurrected in the same form, it is time to remove these forward-compatibility tokens.	+
-		+
-	Proposed action: Throw a compile-time deprecation whenever binary casts or binary string literals are used.	+
-		+
-	==== each() ====	+
-		+
-	The ''each()'' function can be used to iterate over an array, similarly to using ''foreach''. On each call, it returns an array with the current key and value and advances the internal array pointer to the next position. The typical usage, as presented in the manual, is as follows:	+
-		+
-	<code php>	+
-	reset($array);	+
-	while (list($key, $val) = each($array)) {	+
-	echo "$key => $val\n";	+
-	}	+
-	</code>	+
-		+
-	The ''each()'' function is inferior to ''foreach'' in pretty much every imaginable way, including being more than 10 times slower. The continued existence of this function poses a problem for certain language changes. For example the [[https://wiki.php.net/rfc/notice-for-non-valid-array-container]] RFC had to exclude ''list()'', because the typical usage of ''each'' relies on the fact that you can access array offsets on ''false'' without a warning.	+
-		+
-	Proposed action: As ''each'' is typically called within loops, throwing a deprecation warning for every call is likely not advisable. Instead, throw a deprecation warning on the first call for any given request.	+
-		+
-	==== assert() with string argument ====	+
-		+
-	The ''assert()'' function has two modes of operation: If it is passed something other than a string, it will assert that the value is truthy. If a string is passed, it will be run through ''eval()'' and assert will check that the result of the ''eval()'' is truthy.	+
-		+
-	The reason for this behavior is that prior to PHP 7 this was the only way to prevent the assertion expression from evaluating. As of PHP 7, the ''zend.assertions'' ini option can be used to avoid evaluation of assertion expressions. As such, there is no longer a need for supporting implicitly evaluated string arguments.	+
-		+
-	This behavior of ''assert()'' makes it easy to introduce subtle remote code execution vulnerabilities. Using ''assert($value)'' to check if a value is truthy opens an RCE vulnerability if there is any chance for ''$value'' to be a string.	+
-		+
-	Proposed action: Throw a deprecation notice if ''assert()'' is used with a string argument.	+
-		+
-	==== $errcontext argument of error handler ====	+
-		+
-	Error handlers set with ''set_error_handler()'' are passed an ''$errcontext'' as the last argument. This argument is an array containing all local variables at the point the error was generated.	+
-		+
-	This functionality is problematic for optimization, because the ''$errcontext'' can be used to modify all references and objects in the current scope. As far as I am aware, this functionality is barely used and the trade-off here is not worthwhile. If people wish to inspect the variable-state at the point of an error, they should use a proper debugger.	+
-		+
-	Proposed action: Throw deprecation notice if error handler has five or more arguments. Otherwise, do not pass the ''$errcontext''. This prevents circumvention with ''func_get_args()''.	+
-		+
-	===== Backward Incompatible Changes =====	+
-		+
-	For PHP 7.1 additional deprecation notices will appear. For PHP 8.0 the previously deprecated functionality will no longer be available.	+
-		+
-	===== Proposed Voting Choices =====	+
-		+
-	Each of the bullet points above will get a separate vote. All votes will require a 2/3 supermajority, independently of whether they are language changes or not.	+
-		+
-	===== Patches and Tests =====	+
-		+
-	The patches for these deprecations are for the most part trivial, as such they will be provided once the RFC is accepted (or portions of it).	+
-		+
-	===== Suggested deprecations =====	+
-		+
-	The following list contains various suggested deprecations that may or may not be included in this RFC (TODO section).	+
-		+
-	* The ''%%"${varName}"%%'', ''%%"${varName['offset']}"%%'' and ''%%"${expr}"%%'' alternative string interpolation syntaxes. These can be replaced by the more obvious and consistent ''%%"{$varName}"%%'', ''%%"{$varName['offset']}"%%'' and ''%%"{${expr}}"%%''. (Maybe leave the latter? That one is a bit awkward.)	+
-	* The alternative parameter order for ''implode()''. Standard order is string, array, but array, string is also allowed for historic reasons.	+
-	* ''fputcsv'' etc. have been suggested, because they don't conform to the CSV standard. I think it's better to improve the implementation instead.	+
-	* ''convert_cyr_string'', as the same can be done with ''mb_convert_encoding'' or ''iconv''.	+
-	* ''get_magic_quotes_gpc'', as it's pretty useless by now.	+
-	* ''allow_url_include'' ini option.	+
-	* ''hebrevc'' as it's just ''hebrev'' + ''nl2br''.	+
-	* ''sizeof'', which is an alias of ''count''.	+
-	* Second argument to ''spl_autoload''.	+
-	* The ticks mechanism, which is obsoleted by async signal handling.	+
-		+
-	===== Rejected deprecations =====	+
-		+
-	The following section lists features that have been suggested for deprecation, but have not been included in this RFC for the outlined reasons.	+
-		+
-	==== $http_response_header ====	+
-		+
-	The [[http://php.net/manual/en/reserved.variables.httpresponseheader.php\|$http_response_header]] variable is created in the local scope if an HTTP request is performed, for example through ''file_get_contents()''. It contains an array of HTTP response headers.	+
-		+
-	The motivations for removing this functionality are similar to those of ''$php_errormsg'', so it would seem reasonable to deprecate them at the same time. However, unlike ''$php_errormsg'' there exist no //simple// alternatives to ''$http_response_header''. The [[http://php.net/get_headers\|get_headers]] function returns only the headers, but not the response body. Getting both requires, to my knowledge, a combination of ''fopen()'', ''stream_get_contents()'' and reading the ''wrapper_data'' from ''stream_get_meta_data()''.	+
-		+
-	===== Changelog =====	+
-		+
-	* 2016-02-19: Added (unset) cast	+
-	* 2016-02-19: Added mbstring.func_overload	+
-	* 2016-02-18: Added getrandmax()	+

deprecations_php_7_2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/06/12 18:18		current
Line 2:		Line 2:
	* Date: 2015-12-28		* Date: 2015-12-28
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* Discussion: http://markmail.org/message/gto22ob4scfbk7ql		* Discussion: http://markmail.org/message/gto22ob4scfbk7ql
	* Originally published under: https://wiki.php.net/rfc/deprecations_php_7_1		* Originally published under: https://wiki.php.net/rfc/deprecations_php_7_1
Line 162:		Line 162:

	Proposed action: Throw deprecation notice if error handler has five or more arguments. Otherwise, do not pass the ''$errcontext''. This prevents circumvention with ''func_get_args()''.		Proposed action: Throw deprecation notice if error handler has five or more arguments. Otherwise, do not pass the ''$errcontext''. This prevents circumvention with ''func_get_args()''.
		+
		+	Update: Due to technical issues, this does not throw a deprecation warning. It is a documentation-only deprecation.

	<doodle title="Deprecate and subsequently remove $errcontext argument of error handler" auth="nikic" voteType="single" closed="true">		<doodle title="Deprecate and subsequently remove $errcontext argument of error handler" auth="nikic" voteType="single" closed="true">

deprecations_php_7_3

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/07/16 16:59		current
Line 2:		Line 2:
	* Date: 2017-08-02		* Date: 2017-08-02
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.3)
	* Implementation: https://github.com/php/php-src/pull/3366 (unless other patch linked below)		* Implementation: https://github.com/php/php-src/pull/3366 (unless other patch linked below)
	* Discussion: https://externals.io/message/102394		* Discussion: https://externals.io/message/102394

deprecations_php_7_4

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/08/10 23:19		current
Line 2:		Line 2:
	* Date: 26th June, 2018		* Date: 26th June, 2018
	* Authors: Kalle Sommer Nielsen <kalle@php.net>, Nikita Popov <nikic@php.net>		* Authors: Kalle Sommer Nielsen <kalle@php.net>, Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Targets: PHP 7.4		* Targets: PHP 7.4

deprecations_php_8_0

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/01/15 05:22		current
Line 1:		Line 1:
-	====== PHP RFC: Deprecations for PHP 8.1 ======	+	====== PHP RFC: Deprecations for PHP 8.0 ======
	* Date: 2019-07-23		* Date: 2019-07-23
	* Author: Nikita Popov <nikic@php.net>, George Peter Banyard <girgias@php.net>, Máté Kocsis <kocsismate@php.net>		* Author: Nikita Popov <nikic@php.net>, George Peter Banyard <girgias@php.net>, Máté Kocsis <kocsismate@php.net>
	* Status: Under Discussion		* Status: Under Discussion

-	===== Introduction =====	+	**This RFC was postponed to PHP 8.1, see [[rfc:deprecations_php_8_1\|Deprecations for PHP 8.1]].**
-		+
-	The RFC proposes to deprecate the listed functionality in PHP 8.1 and remove it in PHP 9.	+
-		+
-	The following list provides a short overview of the functionality targeted for deprecation, while more detailed explanation is provided in the Proposal section:	+
-		+
-	* ''date_sunrise()'' and ''date_sunset()''	+
-	* ''key()'', ''current()'', ''next()'', ''prev()'', and ''reset()'' on objects	+
-	* ''mb_check_encoding()'' without argument	+
-	* ''get_class()'', ''get_parent_class()'' and ''get_called_class()'' without argument	+
-	* ''FILE_BINARY'' and ''FILE_TEXT'' constants	+
-	* ''t'' fopen mode	+
-	* Passing bool for ''$amountOrUpOrDown'' argument of ''IntlCalendar::roll()''	+
-	* Accessing static members on traits	+
-	* ''strftime()'' and ''gmtstrftime()''	+
-	* Passing a method name as the first parameter to ''ReflectionMethod'''s constructor	+
-	* ''mhash*()'' function family	+
-	* %%''DatePeriod::__construct()''%%	+
-	* ''ctype_*()'' function family accepts ''int'' parameters	+
-	* Return by reference with void type	+
-	* NIL constant defined by the IMAP extension	+
-	* ''unserialize_callback_func'' INI setting	+
-		+
-	===== Proposal =====	+
-		+
-	Each feature proposed for deprecation is voted separately and requires a 2/3 majority. All votes refer to deprecation in PHP 8.1 and removal in PHP 9.0.	+
-		+
-	==== date_sunrise() and date_sunset() ====	+
-		+
-	These two functions have the signature:	+
-		+
-	<PHP>	+
-	function date_sunset(	+
-	int $timestamp,	+
-	int $format = SUNFUNCS_RET_STRING,	+
-	float $latitude = ini_get("date.default_latitude"),	+
-	float $longitude = ini_get("date.default_longitude"),	+
-	float $zenith = ini_get("date.sunset_zenith"),	+
-	float $gmt_offset = 0	+
-	): mixed;	+
-	</PHP>	+
-		+
-	This function depends on ini settings that specify the "default" latitude and longitude, a concept that makes very little sense. Additionally it requires familiarity with appropriate zenith values to use for different purposes.	+
-		+
-	''date_sunset()'' and ''date_sunrise()'' have since been superseded by ''date_sun_info()'':	+
-		+
-	<PHP>	+
-	function date_sun_info(int $time, float $latitude, float $longitude): array;	+
-	</PHP>	+
-		+
-	This function does not use "default" latitude and longitude, and returns an associative array of multiple different definitions of the sunrise/sunset concept.	+
-		+
-	The proposal is to deprecate ''date_sunset()'' and ''date_sunrise()'' in favor of ''date_sun_info()''. The ini settings ''date.default_latitude'', ''date.default_longitude'' and ''date.sunset_zenith'' are marked as deprecated in the documentation. In the next major version, both the functions and the ini settings will be removed.	+
-	This was initially discussed in: https://github.com/php/php-src/pull/4423.	+
-		+
-	==== key(), current(), next(), prev(), reset() on objects ====	+
-		+
-	The ''key()'' family of functions, which are used to manipulate the internal array pointer, also accept objects. In this case they work on the mangled property table. That is, using ''key()'' and friends on an object is essentially the same as using them on ''get_mangled_object_vars($object)''.	+
-		+
-	This catches many people off guard, because they expect ''key()'' etc. to integrate with the iterator interface. That is, if the passed object implements ''Iterator'' then ''key($object)'' should perform an ''$object->key()'' call. The water here have been further muddied by ''ArrayObject'', which prior to PHP 7.4 was the only object where ''key()'' etc. //did// effectively integrate with the iterator interface.	+
-		+
-	There are principally two ways to resolve this: The first is to deprecate the use of ''key()'' etc on objects, and instead require people to perform an explicit ''(array)'' cast or ''get_mangled_object_vars()'' call beforehand. The other is to actually make these functions integrate with iterators. The issue I see with the latter is that we would only be able to support the ''Iterator'' interface proper, but not general ''Traversable''s: For these ''IteratorAggregate::getIterator()'', or the internal ''get_iterator()'' handler need to be called once at the start, which is not possible through the array iteration interface, as it consists of multiple independent functions. Additionally, the ''prev()'' function cannot be implemented for iterators.	+
-		+
-	As such, the proposal is to deprecate key(), current(), next(), prev() and reset() on objects. The suggested replacement is to cast the object to array first, or call ''get_mangled_object_vars()'', depending on what the intention is.	+
-		+
-	==== mb_check_encoding() without argument ====	+
-		+
-	The ''mb_check_encoding()'' usually accepts a string and an encoding, but can also be called without arguments. The documentation says:	+
-		+
-	> If it is omitted, this function checks all the input from the beginning of the request.	+
-		+
-	The implementation says:	+
-		+
-	<code>	+
-	*/ FIXME: Actually check all inputs, except $_FILES file content. /*	+
-	if (MBSTRG(illegalchars) == 0) {	+
-	RETURN_TRUE;	+
-	}	+
-	RETURN_FALSE;	+
-	</code>	+
-		+
-	This %%FIXME%% does not induce a sense of confidence in this function...	+
-		+
-	Further research shows that the documentation is correct, in that //any// encoding checking or conversion functionality invoked during a request will increment ''MBSTRG(illegalchars)''. As such, ''mb_check_encoding()'' tells you whether any illegal encoding has been encountered at any point. My best guess is that this was intended to be used in conjunction with the ''encoding_translation'' feature, which "treats" incoming SAPI data.	+
-		+
-	Overall this functionality is confusing, and the implementation is unfinished or broken. There are no calls to ''mb_check_encoding()'' without argument in popular composer packages.	+
-		+
-	The proposal is to deprecate calling ''mb_check_encoding()'' without arguments.	+
-		+
-	==== get_class(), get_parent_class() and get_called_class() without argument ====	+
-		+
-	In PHP 7.2, [[rfc:get_class_disallow_null_parameter\|passing null to ''get_class()'']] was forbidden, because this behavior was very bug prone. However, the ability to call ''get_class()'' without argument was retained. In that case ''get_class()'' is approximately the same as ''self::class''. ''get_parent_class()'' exhibits the same behavior.	+
-		+
-	The proposal is to deprecate argument-less ''get_class()'', ''get_parent_class()'' and ''get_called_class()'' in favor of the dedicated ''self::class'', ''parent::class'' and ''static::class'' syntax, which was introduced in PHP 5.5. (''get_called_class()'' only has an argument-less form, so it would be deprecated entirely.)	+
-		+
-	As a caveat, if ''get_parent_class()'' is used to check whether the class has a parent, it is necessary to use ''get_parent_class(self::class)'' instead, because ''parent::class'' will generate an error if used inside a class without parent.	+
-		+
-	==== FILE_BINARY and FILE_TEXT constants ====	+
-		+
-	These were introduced in PHP 5.2.7 for forward compatibility with PHP 6, but don't have any effect. These constants are especially confusing because ''fopen()'' supports ''b'' (binary) and ''t'' (text) modes, which //do// have an effect, but a completely unrelated one.	+
-		+
-	The proposal is to deprecate the ''FILE_BINARY'' and ''FILE_TEXT'' constants.	+
-		+
-	This was pointed out in: https://github.com/php/php-src/pull/5556	+
-		+
-	==== "t" fopen mode ====	+
-		+
-	Next to the standard modes, fopen also accepts ''t'' and ''b'' modes, which are only meaningful on Windows. When ''b'' is used (which is the default), the file is treated as usual. If ''t'' is specified, automatic conversion between LF and CRLF line endings is performed. The documentation says:	+
-		+
-	> Again, for portability, it is also strongly recommended that you re-write code that uses or relies upon the 't' mode so that it uses the correct line endings and 'b' mode instead.	+
-		+
-	The proposal is to deprecate the use of ''t'' mode in fopen(). Explicitly specifying the ''b'' mode remains supported.	+
-		+
-	There is a complication here: While ''fopen()'' itself defaults to binary mode, some other functions like ''proc_open()'' on pipe descriptors still default to text mode. The default for these functions should be swapped for PHP 8, independently of this deprecation proposal.	+
-		+
-	==== Passing bool for $amountOrUpOrDown argument of IntlCalendar::roll() ====	+
-		+
-	<php>IntlCalendar::roll()</php> accepts an integer which specifies how much to add to a given field. The integer can be negative to subtract.	+
-		+
-	However, it also accepts a boolean argument, in which case ''true'' is interpreted as ''1'' and ''false'' is interpreted as ''-1''. This does not appear to be actually useful for anything, makes for a confusing function signature, and violates PHP's usual type coercion rules.	+
-		+
-	The proposal is to deprecate passing a boolean to this method argument.	+
-		+
-	==== Accessing static members on traits ====	+
-		+
-	Currently, it is possible to directly access static trait members, rather than accessing them on the class using the trait:	+
-		+
-	<PHP>	+
-	trait T {	+
-	public static $foo;	+
-	}	+
-	class C {	+
-	use T;	+
-	}	+
-	var_dump(T::$foo); // Allowed.	+
-	</PHP>	+
-		+
-	This is conceptually wrong, and causes various complications. For example, the meaning of ''self'' is ill-defined (which normally refers to the using class, not the trait), the behavior of static variables in methods may change depending on whether a trait method has been called prior to being used, and opcache preloading requires constant initializers in traits to be fully resolved (as they may be used directly).	+
-		+
-	There is a somewhat dated analysis of projects using this "feature" at https://github.com/php/php-src/pull/4829#issuecomment-542224541.	+
-		+
-	The proposal is to deprecate the ability to access static properties and static methods directly on traits.	+
-		+
-	==== strftime() and gmstrftime() ====	+
-		+
-	==== strptime() ====	+
-		+
-	==== Passing a method name as the first parameter to ReflectionMethod::__construct() ====	+
-		+
-	A ''ReflectionMethod::fromMethodName()'' method should be added as a replacement.	+
-		+
-	==== mhash*() function family ====	+
-		+
-	''mhash*()'' functions were integrated into ext/hash in PHP 5.3 as a compatibility layer for ext/mhash (which has been removed in PHP 7.0), but they are hardly ever used, and very ill-behaved (primarily ''mhash()'').	+
-		+
-	==== DatePeriod::__construct() ====	+
-		+
-	This is a heavily overloaded function (it has 3 signatures) which should be deprecated in favour of 3 factory methods.	+
-		+
-	*==== ctype_() function family accepts int parameters ====**	+
-		+
-	*Although the documentation currently lists ''string'' as a valid parameter type for ''ctype_'' functions, it's not the case. They also accept an integer which is only mentioned in a note:**	+
-		+
-	<blockquote>	+
-	If an integer between -128 and 255 inclusive is provided, it is interpreted as the ASCII value of a single character (negative values have 256 added in order to allow characters in the Extended ASCII range). Any other integer is interpreted as a string containing the decimal digits of the integer.	+
-	</blockquote>	+
-		+
-	*Moreover, if any other type than int or string is passed, ''ctype_()'' functions silently return ''false''.**	+
-		+
-	Since the current behaviour is highly surprising, passing integer values to ''ctype_*()'' functions should be deprecated first, and ZPP should be modified to only accept strings in the next major version.	+
-		+
-	==== Predefined variable $http_response_header ====	+
-	W.I.P.	+
-	See https://www.php.net/manual/en/reserved.variables.httpresponseheader.php	+
-	We already deprecated/removed $php_errormsg and $HTTP_RAW_POST_DATA	+
-		+
-	==== Return by reference with void type ====	+
-		+
-	''function &test(): void {}'' currently allows, probably shouldn't be?	+
-		+
-		+
-	==== NIL constant defined by the IMAP extension ====	+
-	The ''NIL'' constant corresponds to the value ''0'', and can be confused with ''null''.	+
-		+
-	==== unserialize_callback_func INI setting ====	+
-	W.I.P. (but from my understanding this was used with __autoload() only - girgias)	+
-		+
-	===== Backward Incompatible Changes =====	+
-		+
-	For PHP 8.1 additional deprecation notices will appear. For PHP 9.0 the previously deprecated functionality will no longer be available.	+
-		+
-	===== Removed from this proposal =====	+
-		+
-	The following entries were originally added to this proposal and then dropped.	+
-		+
-	==== DateTimeInterface::ISO8601 ====	+
-		+
-	The documentation says:	+
-		+
-	> Note: This format is not compatible with ISO-8601, but is left this way for backward compatibility reasons. Use DateTime::ATOM or DATE_ATOM for compatibility with ISO-8601 instead.	+
-		+
-	There's a number of bug reports related to this. From what I understand, the core problem here is not that the ISO8601 format is //wrong//, it's just one of multiple legal ISO-8601 formats. As DateTime formats always refer to a specific format, not a set of multiple possible ones, there doesn't seem to be anything actionable here.	+
-		+
-	==== get_browser() function ====	+
-		+
-	This was originally included on the rationale that ''get_browser()'' is much slower than userland browscap implementations. However, this is no longer the case since a PHP 7.0 patch release, see https://github.com/php/php-src/pull/2242.	+

deprecations_php_8_1

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/07/10 02:06		current
Line 2:		Line 2:
	* Date: 2021-02-23		* Date: 2021-02-23
	* Author: Nikita Popov <nikic@php.net>, George Peter Banyard <girgias@php.net>, Máté Kocsis <kocsismate@php.net>, Rowan Tommins <imsop@php.net>		* Author: Nikita Popov <nikic@php.net>, George Peter Banyard <girgias@php.net>, Máté Kocsis <kocsismate@php.net>, Rowan Tommins <imsop@php.net>
-	* Status: Voting	+	* Status: Implemented

	===== Introduction =====		===== Introduction =====
Line 68:		Line 68:
	This was initially discussed in: https://github.com/php/php-src/pull/4423.		This was initially discussed in: https://github.com/php/php-src/pull/4423.

-	<doodle title="Deprecate date_sunrise() and date_sunset()?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate date_sunrise() and date_sunset()?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 83:		Line 83:
	As such, the proposal is to deprecate key(), current(), next(), prev() and reset() on objects. The suggested replacement is to cast the object to array first, or call ''get_mangled_object_vars()'', depending on what the intention is.		As such, the proposal is to deprecate key(), current(), next(), prev() and reset() on objects. The suggested replacement is to cast the object to array first, or call ''get_mangled_object_vars()'', depending on what the intention is.

-	<doodle title="Deprecate key(), current(), next(), prev(), reset() on objects?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate key(), current(), next(), prev(), reset() on objects?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 112:		Line 112:
	The proposal is to deprecate calling ''mb_check_encoding()'' without arguments.		The proposal is to deprecate calling ''mb_check_encoding()'' without arguments.

-	<doodle title="Deprecate mb_check_encoding() without argument?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate mb_check_encoding() without argument?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 125:		Line 125:
	As a caveat, if ''get_parent_class()'' is used to check whether the class has a parent, it is necessary to use ''get_parent_class(self::class)'' instead, because ''parent::class'' will generate an error if used inside a class without parent.		As a caveat, if ''get_parent_class()'' is used to check whether the class has a parent, it is necessary to use ''get_parent_class(self::class)'' instead, because ''parent::class'' will generate an error if used inside a class without parent.

-	<doodle title="Deprecate get_class(), get_parent_class() and get_called_class() without argument?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate get_class(), get_parent_class() and get_called_class() without argument?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 138:		Line 138:
	This was pointed out in: https://github.com/php/php-src/pull/5556		This was pointed out in: https://github.com/php/php-src/pull/5556

-	<doodle title="Deprecate FILE_BINARY and FILE_TEXT constants?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate FILE_BINARY and FILE_TEXT constants?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 153:		Line 153:
	While ''fopen()'' defaults to binary mode, some other functions like ''proc_open()'' on pipe descriptors still default to text mode. Cases that use ''t'' as the default mode are excluded from this deprecation for the time being. We may include them in the future, which would require explicitly specifying ''b'' mode for them during a transitionary period.		While ''fopen()'' defaults to binary mode, some other functions like ''proc_open()'' on pipe descriptors still default to text mode. Cases that use ''t'' as the default mode are excluded from this deprecation for the time being. We may include them in the future, which would require explicitly specifying ''b'' mode for them during a transitionary period.

-	<doodle title="Deprecate t fopen mode?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate t fopen mode?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 166:		Line 166:
	The proposal is to deprecate passing a boolean to this method argument.		The proposal is to deprecate passing a boolean to this method argument.

-	<doodle title="Deprecate passing bool for $value argument of IntlCalendar::roll()?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate passing bool for $value argument of IntlCalendar::roll()?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 191:		Line 191:
	The proposal is to deprecate the ability to access static properties and static methods directly on traits.		The proposal is to deprecate the ability to access static properties and static methods directly on traits.

-	<doodle title="Deprecate accessing static members on traits?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate accessing static members on traits?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 208:		Line 208:
	The proposal is to deprecate the ''strptime()'' function in favor of portable alternatives.		The proposal is to deprecate the ''strptime()'' function in favor of portable alternatives.

-	<doodle title="Deprecate strptime()?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate strptime()?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 221:		Line 221:
	The proposal is to deprecate ''strftime()'' and ''gmstrftime()'' in favor of these alternatives.		The proposal is to deprecate ''strftime()'' and ''gmstrftime()'' in favor of these alternatives.

-	<doodle title="Deprecate strftime() and gmstrftime()?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate strftime() and gmstrftime()?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 232:		Line 232:
	The proposal is to deprecate ''mhash()'', ''mhash_keygen_s2k()'', ''mhash_count()'', ''mhash_get_block_size()'' and ''mhash_get_hash_name()'' in favor of the standard ext/hash functionality.		The proposal is to deprecate ''mhash()'', ''mhash_keygen_s2k()'', ''mhash_count()'', ''mhash_get_block_size()'' and ''mhash_get_hash_name()'' in favor of the standard ext/hash functionality.

-	<doodle title="Deprecate mhash() family of functions?" auth="nikic" voteType="single" closed="false*">	+	<doodle title="Deprecate mhash() family of functions?" auth="nikic" voteType="single" closed="true*">
	* Yes		* Yes
	* No		* No
Line 251:		Line 251:
	The proposal is to deprecate passing of non-strings to ''ctype_()'' functions. In the next major versions, ''ctype_()'' will be changed to accept a string parameter under standard semantics.		The proposal is to deprecate passing of non-strings to ''ctype_()'' functions. In the next major versions, ''ctype_()'' will be changed to accept a string parameter under standard semantics.

-	<doodle title="Deprecate int parameters to ctype_() functions?" auth="nikic" voteType="single" closed="false*">	+	<doodle title="Deprecate int parameters to ctype_() functions?" auth="nikic" voteType="single" closed="true*">
	* Yes		* Yes
	* No		* No
Line 268:		Line 268:
	The proposal is to throw a compile-time deprecation for function signatures using by-reference returns in conjunction with void.		The proposal is to throw a compile-time deprecation for function signatures using by-reference returns in conjunction with void.

-	<doodle title="Deprecate return by reference with void type?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate return by reference with void type?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 279:		Line 279:
	The proposal is to deprecate this constant.		The proposal is to deprecate this constant.

-	<doodle title="Deprecate NIL constant defined by the IMAP extension?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate NIL constant defined by the IMAP extension?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 305:		Line 305:
	The proposal is to deprecate any use of the "default connection" in ext/pgsql. A deprecation notice will be thrown if a pgsql function is called without explicitly specifying the connection.		The proposal is to deprecate any use of the "default connection" in ext/pgsql. A deprecation notice will be thrown if a pgsql function is called without explicitly specifying the connection.

-	<doodle title="Deprecate calling overloaded pgsql functions without the connection argument?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate calling overloaded pgsql functions without the connection argument?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 330:		Line 330:
	</PHP>		</PHP>

-	<doodle title="Deprecate $num_points parameter of image(open\|filled)polygon?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate $num_points parameter of image(open\|filled)polygon?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 355:		Line 355:
	</PHP>		</PHP>

-	<doodle title="Deprecate mysqli::init()?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate mysqli::init()?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 372:		Line 372:
	The proposal is to emit a deprecation warning if ''filter.default'' is set to a value other than ''unsafe_raw'' (the default). No separate deprecation warning is emitted for ''filter.default_options'', but both ini settings will be removed together in the next major version.		The proposal is to emit a deprecation warning if ''filter.default'' is set to a value other than ''unsafe_raw'' (the default). No separate deprecation warning is emitted for ''filter.default_options'', but both ini settings will be removed together in the next major version.

-	<doodle title="Deprecate filter.default ini setting?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate filter.default ini setting?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 383:		Line 383:
	The proposal is to emit a deprecation warning if ''auto_detect_line_endings'' is enabled.		The proposal is to emit a deprecation warning if ''auto_detect_line_endings'' is enabled.

-	<doodle title="Deprecate auto_detect_line_endings ini setting?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate auto_detect_line_endings ini setting?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 400:		Line 400:
	The proposal is to deprecate passing an ''ssl_method'' option to the constructor, and recommend the use of ''context'' option instead.		The proposal is to deprecate passing an ''ssl_method'' option to the constructor, and recommend the use of ''context'' option instead.

-	<doodle title="Deprecate ssl_method option to SoapClient constructor?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate ssl_method option to SoapClient constructor?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 415:		Line 415:
	The proposal is to deprecate the ''FILTER_SANITIZE_STRING'' constant, its alias ''FILTER_SANITIZE_STRIPPED'', as well as use of this filter.		The proposal is to deprecate the ''FILTER_SANITIZE_STRING'' constant, its alias ''FILTER_SANITIZE_STRIPPED'', as well as use of this filter.

-	<doodle title="Deprecate FILTER_SANITIZE_STRING?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate FILTER_SANITIZE_STRING?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 426:		Line 426:
	The proposal is to throw a deprecation warning if ''oci8.old_oci_close_semantics'' is enabled.		The proposal is to throw a deprecation warning if ''oci8.old_oci_close_semantics'' is enabled.

-	<doodle title="Deprecate oci8.old_oci_close_semantics INI setting?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate oci8.old_oci_close_semantics INI setting?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 437:		Line 437:
	The proposal is to deprecate the ''odbc_result_all()'' function.		The proposal is to deprecate the ''odbc_result_all()'' function.

-	<doodle title="Deprecate odbc_result_all()?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Deprecate odbc_result_all()?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

deprecations_php_8_2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/07/20 11:43		current
Line 10:		Line 10:
	The following list provides a short overview of the functionality targeted for deprecation, while more detailed explanation is provided in the Proposal section:		The following list provides a short overview of the functionality targeted for deprecation, while more detailed explanation is provided in the Proposal section:

-	* Call scope dependent return values of internal methods	+	* Call scope dependent behavior of internal methods

	===== Proposal =====		===== Proposal =====
Line 16:		Line 16:
	Each feature proposed for deprecation is voted separately and requires a 2/3 majority. All votes refer to deprecation in PHP 8.2 and removal in PHP 9.0.		Each feature proposed for deprecation is voted separately and requires a 2/3 majority. All votes refer to deprecation in PHP 8.2 and removal in PHP 9.0.

-	==== Call scope dependent return values of internal methods ====	+	==== Call scope dependent behavior of internal methods ====

	A few internal methods return different values based on the scope they were called from:		A few internal methods return different values based on the scope they were called from:
Line 28:		Line 28:
	* DOMDocument::loadXML()		* DOMDocument::loadXML()

-	These methods should be allowed to be called either statically, or from the object scope.	+	These methods should be allowed to be called either statically, or from the object scope, and their behavior shouldn't depend on the scope.

deprecations_php_8_3

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/07/11 15:36		current
Line 2:		Line 2:
	* Date: 2022-08-01		* Date: 2022-08-01
	* Authors: Christoph M. Becker <cmb@php.net>, George Peter Banyard <girgias@php.net>, Máté Kocsis <kocsismate@php.net>		* Authors: Christoph M. Becker <cmb@php.net>, George Peter Banyard <girgias@php.net>, Máté Kocsis <kocsismate@php.net>
-	* Status: Accepted	+	* Status: Implemented
-	* Implementation: https://github.com/php/php-src/commit/61251093ab5b1ebbe112362893ff8b9edba215e0 (MT_RAND_PHP), https://github.com/php/php-src/commit/69a8b63ecf4fec1b35ef4da1ac9579321c45f97f (ldap_connect)	+	* Implementation:
		+	* MT_RAND_PHP: https://github.com/php/php-src/commit/61251093ab5b1ebbe112362893ff8b9edba215e0
		+	* <php>ldap_connect()</php>: https://github.com/php/php-src/commit/69a8b63ecf4fec1b35ef4da1ac9579321c45f97f
		+	* <php>mb_strimwidth()</php>: https://github.com/php/php-src/commit/af3c220abbff2415ccd79aeac1888edfc106ffa6
		+	* NumberFormater::TYPE_CURRENCY: https://github.com/php/php-src/commit/d65251e6e863684f8fc7ddc9c0fba7cf53483f7f

	===== Introduction =====		===== Introduction =====

deprecations_php_8_4

Anonymous (anonymous@undisclosed.example.com) — 2025-11-14T04:54:54+00:00

2025/07/10 04:24		current
Line 9:		Line 9:
	* Jorg Sowa <jorg.sowa@gmail.com>		* Jorg Sowa <jorg.sowa@gmail.com>
	* Status: Implemented		* Status: Implemented
-	* Implementation: 8.5 (for user output handlers returning non-strings or producing output), 8.4 (everything else)	+	* Implementation: pending (for user output handlers returning non-strings), 8.5 (for user output handlers producing output), 8.4 (everything else)
	* [[https://github.com/php/php-src/commit/587110c5bf44362fa81606c492c9a668b2160d9a\|Formally deprecate Soft-deprecated DOMDocument and DOMEntity properties]]		* [[https://github.com/php/php-src/commit/587110c5bf44362fa81606c492c9a668b2160d9a\|Formally deprecate Soft-deprecated DOMDocument and DOMEntity properties]]
	* [[https://github.com/php/php-src/commit/d9eb3783bdd6947a635f132f8c240de8f40e8704\|Remove DOMImplementation::getFeature($feature, $version)]]		* [[https://github.com/php/php-src/commit/d9eb3783bdd6947a635f132f8c240de8f40e8704\|Remove DOMImplementation::getFeature($feature, $version)]]
Line 22:		Line 22:
	* [[https://github.com/php/php-src/commit/c818d944cf998b3151e4b312d655c51223612c4e\|Deprecate proprietary CSV escaping mechanism]]		* [[https://github.com/php/php-src/commit/c818d944cf998b3151e4b312d655c51223612c4e\|Deprecate proprietary CSV escaping mechanism]]
	* [[https://github.com/php/php-src/commit/d313ad6098430f4e61f0121a9e7ab392d195e4e4\|Deprecate E_STRICT Constant]]		* [[https://github.com/php/php-src/commit/d313ad6098430f4e61f0121a9e7ab392d195e4e4\|Deprecate E_STRICT Constant]]
-	* [[https://github.com/php/php-src/commit/d8577d9bfbb89bc2924b0bcb60a8e7fb5fd5267a\|Deprecate returning non-string values from a user output handler]]	+	* Deprecate returning non-string values from a user output handler
	* [[https://github.com/php/php-src/commit/07f1cfd9b01ff0f3720c1a5580b9e263eec5fce1\|Deprecate producing output in a user output handler]]		* [[https://github.com/php/php-src/commit/07f1cfd9b01ff0f3720c1a5580b9e263eec5fce1\|Deprecate producing output in a user output handler]]
	* [[https://github.com/php/php-src/commit/cbcad9fdaf816e4512cecfb6c1d50fcc0ea7294d\|Deprecate mysqli_ping() and mysqli::ping()]]		* [[https://github.com/php/php-src/commit/cbcad9fdaf816e4512cecfb6c1d50fcc0ea7294d\|Deprecate mysqli_ping() and mysqli::ping()]]

deprecations_php_8_5

Anonymous (anonymous@undisclosed.example.com) — 2025-09-19T20:30:13+00:00

deprecations_php_8_6

Anonymous (anonymous@undisclosed.example.com) — 2026-04-08T17:06:26+00:00

2026/04/08 17:02		current
Line 20:		Line 20:
	* Deprecate <php>strcoll()</php>		* Deprecate <php>strcoll()</php>
	* Deprecate <php>SORT_LOCALE_STRING</php> flag for <php>sort()</php> functions		* Deprecate <php>SORT_LOCALE_STRING</php> flag for <php>sort()</php> functions
-	* Providing invalid values to <php>log()</php> second argument
	* Deprecate <php>mail.add_x_header</php> INI setting		* Deprecate <php>mail.add_x_header</php> INI setting
	* Deprecate <php>mysqli::stmt_init()</php>		* Deprecate <php>mysqli::stmt_init()</php>
Line 87:		Line 86:
	* Relies on global state from <php>setlocale()</php>		* Relies on global state from <php>setlocale()</php>
	* Alternative: <php>Collator::sort()</php>, <php>Collator::asort()</php>, <php>Collator::sort()</php>, <php>Collator::sortWithSortKeys()</php>		* Alternative: <php>Collator::sort()</php>, <php>Collator::asort()</php>, <php>Collator::sort()</php>, <php>Collator::sortWithSortKeys()</php>
-
-	==== Providing invalid values to log() second argument ====
-
-	* Author: Alexandre Daubois <alexandredaubois@php.net>
-
-	Providing 1 or any number less or equal to 0 results on a NaN result. This is error-prone. Deprecating then throwing a <php>ValueError</php> in PHP 9.0 would help early error detection and avoid propagating a NaN value.

	==== Deprecate mail.add_x_header INI setting ====		==== Deprecate mail.add_x_header INI setting ====

deque_straw_poll

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/01/26 13:48		current
Line 3:		Line 3:
	* Date: 2022-01-05		* Date: 2022-01-05
	* Author: Tyson Andre, tandre@php.net		* Author: Tyson Andre, tandre@php.net
-	* Status: Voting	+	* Status: Closed
	* First Published at: http://wiki.php.net/rfc/deque_straw_poll		* First Published at: http://wiki.php.net/rfc/deque_straw_poll

deque

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/11/12 00:59		current
Line 1534:		Line 1534:
	* 0.9.0: Add benchmark for repeated unshift then repeated shift. Add discussion section for request to ''return $this''. Remove duplicate quotes. Clarify notes on performance.		* 0.9.0: Add benchmark for repeated unshift then repeated shift. Add discussion section for request to ''return $this''. Remove duplicate quotes. Clarify notes on performance.
	* 1.0.0: Support removing element with offsetUnset. Add ''insert(int $offset, mixed ...$values): void {}'' Improve iterator behavior and make it consistent with other iterators. Update benchmarks for php 8.3. Add benchmark of impact of memory locality on read performance vs SplDoublyLinkedList. Update proposed php version to 8.3.		* 1.0.0: Support removing element with offsetUnset. Add ''insert(int $offset, mixed ...$values): void {}'' Improve iterator behavior and make it consistent with other iterators. Update benchmarks for php 8.3. Add benchmark of impact of memory locality on read performance vs SplDoublyLinkedList. Update proposed php version to 8.3.
		+	* 1.1.0: Rename shift/unshift methods to popFront/pushFront

destructuring_coalesce

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/11/26 01:10		current
Line 3:		Line 3:
	* Date: 2022-10-14		* Date: 2022-10-14
	* Author: Bob Weinand <bwoebi@php.net>		* Author: Bob Weinand <bwoebi@php.net>
-	* Status: In voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/destructuring_coalesce		* First Published at: http://wiki.php.net/rfc/destructuring_coalesce

direct-execution-opcode

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/04/05 02:05		current
Line 3:		Line 3:
	* Date: 2020-11-13		* Date: 2020-11-13
	* Author: chopins xiao(chopins.xiao@gmail.com)		* Author: chopins xiao(chopins.xiao@gmail.com)
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/direct-execution-opcode		* First Published at: http://wiki.php.net/rfc/direct-execution-opcode

Line 106:		Line 106:
	Voting opens 2021-04-05 and 2021-04-20 at 00:00:00 UTC. 2/3 required to accept.		Voting opens 2021-04-05 and 2021-04-20 at 00:00:00 UTC. 2/3 required to accept.

-	<doodle title="Add OPCache direct execution opcode without source file" auth="chopins" voteType="single" closed="false">	+	<doodle title="Add OPCache direct execution opcode without source file" auth="chopins" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

directory-opaque-object

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/10/19 22:35		current
Line 4:		Line 4:
	* Date: 2024-09-14		* Date: 2024-09-14
	* Author: Gina Peter Banyard <girgias@php.net>		* Author: Gina Peter Banyard <girgias@php.net>
-	* Status: Pending Implementation	+	* Status: Implemented
	* Target Version: PHP 8.5		* Target Version: PHP 8.5
	* Implementation: https://github.com/php/php-src/pull/15886		* Implementation: https://github.com/php/php-src/pull/15886

disallow-multiple-constructor-calls

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2017-01-17		* Date: 2017-01-17
	* Author: Richard Fussenegger <php@fleshgrinder.com>, Tim Behashvyly <tim.bezhashvyly@gmail.com>		* Author: Richard Fussenegger <php@fleshgrinder.com>, Tim Behashvyly <tim.bezhashvyly@gmail.com>
-	* Status: Draft	+	* Status: Inactive
	* First Published at: https://wiki.php.net/rfc/disallow-multiple-constructor-calls		* First Published at: https://wiki.php.net/rfc/disallow-multiple-constructor-calls

display_error_function_args

Anonymous (anonymous@undisclosed.example.com) — 2026-04-15T21:58:06+00:00

2026/04/10 07:20		current
Line 1:		Line 1:
	====== PHP RFC: Display Function Arguments in Errors ======		====== PHP RFC: Display Function Arguments in Errors ======
-	* Version: 1.6	+	* Version: 1.7
	* Date: 2026-03-09		* Date: 2026-03-09
	* Author: Calvin Buckley, calvinb@php.net		* Author: Calvin Buckley, calvinb@php.net
Line 8:		Line 8:
	===== Introduction =====		===== Introduction =====

-	PHP errors (and warnings, notices, etc.) show the function that raised them. However, the display of parameters in these errors is inconsistent. In practice, only basic stream functions provide parameters, and those displayed parameters aren't derived from the argument list that the function was called with.	+	PHP errors (and warnings, notices, etc.) for built-in native functions show the function that raised them. However, the display of parameters in these errors is inconsistent. In practice, only basic stream functions provide parameters, and those displayed parameters aren't derived from the argument list that the function was called with.

	For example, take this very simple script:		For example, take this very simple script:
Line 55:		Line 55:
	Warning: odbc_connect('BO...', 'us...', Object(SensitiveParameterValue)): SQL error: [unixODBC][Driver Manager]Data source name not found and no default driver specified, SQL state IM002 in SQLConnect in /Users/calvin/src/chmod.php on line 7		Warning: odbc_connect('BO...', 'us...', Object(SensitiveParameterValue)): SQL error: [unixODBC][Driver Manager]Data source name not found and no default driver specified, SQL state IM002 in SQLConnect in /Users/calvin/src/chmod.php on line 7
	</code>		</code>
		+
		+	This is only done for native built-in functions, as they include the function name. User errors triggered via i.e. ''trigger_error'' do not. PHP's built-in functions are properly marked for sensitive parameters, so possible leakage of sensitive information should be minimal. If one is not properly marked, this should be treated as a bug in PHP anyways.

	Even if we do set this to 1 by default, we may not want to do so for tests. Because of the wide impact to the formatting of tests, this would involve touching a large majority of PHP tests (there are currently over 21000 today). While my implementation PR does attempt to update ''bless.php'' for common cases where strings can now be visible and need to be adjusted for (e.g. paths including usernames), bless can still munge the expect sections in a way that requires manual adjustment. There is precedent for not using this; the "[[error_backtraces_v2\|Error Backtraces v2]]" RFC chose to not do so.		Even if we do set this to 1 by default, we may not want to do so for tests. Because of the wide impact to the formatting of tests, this would involve touching a large majority of PHP tests (there are currently over 21000 today). While my implementation PR does attempt to update ''bless.php'' for common cases where strings can now be visible and need to be adjusted for (e.g. paths including usernames), bless can still munge the expect sections in a way that requires manual adjustment. There is precedent for not using this; the "[[error_backtraces_v2\|Error Backtraces v2]]" RFC chose to not do so.
Line 110:		Line 112:
	==== To Existing Extensions ====		==== To Existing Extensions ====

-	None.	+	* Places where ''php_error_docref'' are called will include the parameters when the INI option is enabled. Extensions should mark sensitive parameters with the appropriate attribute.

	==== To SAPIs ====		==== To SAPIs ====
Line 167:		Line 169:
	===== Changelog =====		===== Changelog =====

		+	* 1.7: Clarifications around impact
	* 1.6: Add performance impact/benchmarks from ML post		* 1.6: Add performance impact/benchmarks from ML post
	* 1.5: Rename to "error_include_args" to avoid a confusing INI name.		* 1.5: Rename to "error_include_args" to avoid a confusing INI name.

distrust-sha1-certificates

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/05/29 10:56		current
Line 30:		Line 30:
	===== RFC Impact =====		===== RFC Impact =====

-	Browsers start on 2017-01-01 with no longer accepting SHA-1 certificates, too. Impact is expected to be rather low. People in need of SHA-1 certificates, e.g. for private CAs, can set the mentioned context option to ''80'' to get the previous behavior (except for MD5 not being accepted), but are strongly discouraged to do so. It is explicitly not possible to set this value lower than 80. There's no option to enable MD5.	+	Browsers started on 2017-01-01 with no longer accepting SHA-1 certificates. The impact is expected to be rather low. People in need of SHA-1 certificates, e.g. for private CAs, can set the mentioned context option to ''80'' to get the previous behavior (except for MD5 not being accepted), but are strongly discouraged to do so. It is explicitly not possible to set this value lower than 80. There's no option to enable MD5.

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

dnf_types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/07/03 02:17		current
Line 83:		Line 83:
	// Acceptable. A&B is more restrictive.		// Acceptable. A&B is more restrictive.
	class TestOne implements ITest {		class TestOne implements ITest {
-	public function stuff(): (A&B) {}	+	public function stuff(): A&B {}
	}		}

docblockparser

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2008-03-06		* Date: 2008-03-06
	* Author: Chad Fulton <ChadFulton@gmail.com>		* Author: Chad Fulton <ChadFulton@gmail.com>
-	* Status: Ready for Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/docblockparser		* First Published at: http://wiki.php.net/rfc/docblockparser

dom_additions_84

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/06/24 19:08		current
Line 3:		Line 3:
	* Date: 2024-04-12		* Date: 2024-04-12
	* Author: Niels Dossche, <nielsdos@php.net>		* Author: Niels Dossche, <nielsdos@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/dom_additions_84		* First Published at: http://wiki.php.net/rfc/dom_additions_84

Line 560:		Line 560:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged into	+	Merged into PHP 8.4.
-	- a link to the git commit(s)	+	Commits:
-	- a link to the PHP manual entry for the feature	+	- https://github.com/php/php-src/commit/cf914f418480e5b5efbae37c683c6850cb84381b
-	- a link to the language specification section (if any)	+	- https://github.com/php/php-src/commit/fc09f4b2bc36b40a79f3ee0c2c557693ba57f836
		+	- https://github.com/php/php-src/commit/768900b180c8e07552b5a579a4b4d7a7a0d02c22
		+	- https://github.com/php/php-src/commit/88da91491069e7c16de4bbdd832546400c57bd20
		+	- https://github.com/php/php-src/commit/48c9f1e2c39fde5d231dc6035a5f76e1121e184c
		+	- https://github.com/php/php-src/commit/78401ba867cfd9645f95ec1c837bb51f591323ab
		+	- https://github.com/php/php-src/commit/04af9603970e5858d1830fbaf13b69818756e734
		+	- https://github.com/php/php-src/commit/a12db3b6564e8fb4ca0629450670e1e3cfc31117
		+	- https://github.com/php/php-src/commit/287cf91724670b1a6925893af53630ce6776bd32
		+	- https://github.com/php/php-src/commit/a1485df55ae314f1a0a5cd0d1e63583510fda1fd
		+	- https://github.com/php/php-src/commit/e4250cec79c830558c8fa2d002fad5e7446e3be4
		+	- https://github.com/php/php-src/commit/a068a9a5bb190abce59b1f6ab53b38cd7221544a

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

dom_living_standard_api

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/11/27 22:10		current
Line 4:		Line 4:
	* Date: 2019-09-15		* Date: 2019-09-15
	* Author: Benjamin Eberlei (beberlei@php.net), Thomas Weinert		* Author: Benjamin Eberlei (beberlei@php.net), Thomas Weinert
-	* Status: In Voting	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/dom_living_standard_api		* First Published at: http://wiki.php.net/rfc/dom_living_standard_api

domdocument_html5_parser

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/08/05 20:18		current
Line 8:		Line 8:

	===== Introduction =====		===== Introduction =====
		+
		+	Important: parts of this RFC were further enhanced by https://wiki.php.net/rfc/opt_in_dom_spec_compliance

	PHP's DOM extension supports loading HTML documents using the methods <php>\DOMDocument::loadHTML</php> and <php>\DOMDocument::loadHTMLFile</php>.		PHP's DOM extension supports loading HTML documents using the methods <php>\DOMDocument::loadHTML</php> and <php>\DOMDocument::loadHTMLFile</php>.

dont_trim_nul

Anonymous (anonymous@undisclosed.example.com) — 2026-03-30T09:49:36+00:00

2026/03/15 08:06		current
Line 3:		Line 3:
	* Date: 2026-03-15		* Date: 2026-03-15
	* Author: Weilin Du, lamentxu@163.com		* Author: Weilin Du, lamentxu@163.com
-	* Status: Under Discussion	+	* Status: Withdrawn

	===== Introduction =====		===== Introduction =====

doxygen

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/07/01 17:36		current
Line 3:		Line 3:
	* Date: 2017-05-30		* Date: 2017-05-30
	* Author: Richard Fussenegger, php@fleshgrinder.com		* Author: Richard Fussenegger, php@fleshgrinder.com
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/doxygen		* First Published at: http://wiki.php.net/rfc/doxygen

driver-specific-pdo-param-types

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/10/18 22:01		current
Line 22:		Line 22:
	===== New Constants =====		===== New Constants =====
	The example code introduces the following constants:		The example code introduces the following constants:
-	* PDO::DBLIB_ATTR_UNICODE_STRINGS	+	* PDO::DBLIB_ATTR_UNICODE_STRINGS
-	* PDO::DBLIB_PARAM_BINARY	+	* PDO::DBLIB_PARAM_BINARY
-	* PDO::DBLIB_PARAM_STR_UNICODE	+	* PDO::DBLIB_PARAM_STR_UNICODE
-	* PDO::DBLIB_PARAM_STR_ASCII	+	* PDO::DBLIB_PARAM_STR_ASCII

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

drop_32bit_support

Anonymous (anonymous@undisclosed.example.com) — 2025-06-19T14:19:02+00:00

2025/06/19 14:05		current
Line 3:		Line 3:
	* Date: 2025-06-18		* Date: 2025-06-18
	* Author: Marc Bennewitz, marc@mabe.berlin		* Author: Marc Bennewitz, marc@mabe.berlin
-	* Status: Draft	+	* Status: Under Discussion
	* First Published at: https://wiki.php.net/rfc/drop_32bit_support		* First Published at: https://wiki.php.net/rfc/drop_32bit_support

Line 131:		Line 131:
	===== References =====		===== References =====

-	ML Year 2028 issue : https://externals.io/message/127671	+	ML Year 2028 issue : https://discourse.thephp.foundation/t/php-dev-year-2038-issue/1904

-	ML Discussion : TBD	+	ML Discussion : https://discourse.thephp.foundation/t/php-dev-rfc-drop-support-for-32bit-builds/1919

	ML Vote : TBD		ML Vote : TBD

drop_sql.safe_mode

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2010-03-26		* Date: 2010-03-26
	* Author: Johannes Schlüter <johannes@php.net>		* Author: Johannes Schlüter <johannes@php.net>
-	* Status: Draft	+	* Status: Draft (Inactive)
	* First Published at: http://wiki.php.net/rfc/drop_sql.safe_mode		* First Published at: http://wiki.php.net/rfc/drop_sql.safe_mode

drop-datetimeinterface

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/07/21 13:41		current
Line 24:		Line 24:
	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====

-	Applications relying on \DateTimeInterface would need to explicitly switch back to checking against \DateTime and \DateTimeInterface.	+	Applications relying on \DateTimeInterface would need to explicitly switch back to checking against \DateTime and \DateTimeImmutable.

	Software compatible with PHP 5.5.0~5.5.7 and implementing \DateTimeInterface would break anyway.		Software compatible with PHP 5.5.0~5.5.7 and implementing \DateTimeInterface would break anyway.
-	Software checking against \DateTimeInterface via instanceof	+	Software checking against \DateTimeInterface via instanceof.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====

dtrace

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/07/20 13:05		current
Line 3:		Line 3:
	* Date: 2009-07-14		* Date: 2009-07-14
	* Author: David Soria Parra <david.soriaparra@sun.com>		* Author: David Soria Parra <david.soriaparra@sun.com>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/dtrace		* First Published at: http://wiki.php.net/rfc/dtrace
	* Patch: http://patches.experimentalworks.net/dtrace.patch		* Patch: http://patches.experimentalworks.net/dtrace.patch

dvcs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/09/05 09:39		current
Line 3:		Line 3:
	* Date: 2011-07-30		* Date: 2011-07-30
	* Author: David Soria Parra <dsp at php dot net>		* Author: David Soria Parra <dsp at php dot net>
-	* Status: [[rfc:dvcs:vote\|Voting]] (Voting ends Sep 7, 2011 12:00 UTC)	+	* Status: Accepted with Option Git [[rfc:dvcs:vote\|Voting Results]] (Voting ended Sep 7, 2011 12:00 UTC)
	* First Published at: http://wiki.php.net/rfc/dvcs		* First Published at: http://wiki.php.net/rfc/dvcs

dvcsmigration

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== Request for Comments: Migrating to a Distributed Version Control System for PHP ======
	+	* Version: 1.0
	+	* Date: 2010-11-30
	+	* Author: Herman Radtke <hradtke@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/dvcsmigration
	+
	+	===== Introduction =====
	+	A distributed version control system (DVCS) provides considerable more flexibility than SVN. Key features include a developers ability to interact with the repository without the need for a network connection and the low cost of branching.
	+
	+	The initial discussion for moving to a DVCS began during the SVN conversion process. It was not given much credibility because the SVN conversion was mostly finished. There is also the issue of a learning curve. The workflow for SVN is not that different from CVS. The biggest change in converting to SVN was the syntax change. Converting to a DVCS will introduce both a workflow change and a syntax change. The conversion to a DVCS will have a higher intial cost, but the medium and long term benefits far outweigh this cost.
	+
	+	===== DVCS Options =====
	+
	+	Options are listed in alpha order:
	+	* [[http://bazaar.canonical.com/en/\|Bazaar]]
	+	* [[http://www.git-scm.com/\|git]]
	+	* [[http://mercurial.selenic.com/\|Mercurial]]
	+
	+	===== Migration Path =====
	+	The migration to a DVCS should be a gradual one. Converting a repository of PHP's size is a huge task with lots of moving parts. The SVN conversion was a major disruption to the developer community. The initial steps of migration to a DVCS should focus on the conversion of one section of the existing SVN repository to a DVCS.
	+
	+	This does not mean that the migration plan should be made up as we go along. A solid migration plan for all parts of the existing SVN repository should be in place before the initial migration begins. This includes topics such as karma, authentication and scripts. The community will be encouraged to give feedback as the migration process is underway.
	+
	+	===== Use Cases =====
	+
	+	===== References =====
	+	* http://www.python.org/dev/peps/pep-0374/
	+	* http://book.git-scm.com/index.html
	+
	+

dynamic_class_constant_fetch

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/01/05 22:03		current
Line 3:		Line 3:
	* Date: 2022-11-04		* Date: 2022-11-04
	* Author: Ilija Tovilo, tovilo.ilija@gmail.com		* Author: Ilija Tovilo, tovilo.ilija@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.3		* Target Version: PHP 8.3
	* Implementation: https://github.com/php/php-src/pull/9793		* Implementation: https://github.com/php/php-src/pull/9793

e-user-deprecated-warning

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2008-07-18		* Date: 2008-07-18
	* Author: Lars Strojny <lstrojny@php.net>		* Author: Lars Strojny <lstrojny@php.net>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.3
	* First Published at: http://wiki.php.net/rfc/e-user-deprecated-warning		* First Published at: http://wiki.php.net/rfc/e-user-deprecated-warning

easy_userland_csprng

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/04/09 16:55		current
Line 3:		Line 3:
	* Date: 2015-02-20		* Date: 2015-02-20
	* Author: Sammy Kaye Powers <me@sammyk.me> & Leigh <leigh@php.net>		* Author: Sammy Kaye Powers <me@sammyk.me> & Leigh <leigh@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/easy_userland_csprng		* First Published at: http://wiki.php.net/rfc/easy_userland_csprng

empty_function

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/10/31 11:49		current
Line 168:		Line 168:
	According to the official policies documented at https://wiki.php.net/rfc/releaseprocess, backwards compatibility can only be broken		According to the official policies documented at https://wiki.php.net/rfc/releaseprocess, backwards compatibility can only be broken
	in a major version, hence the new function <php>is_empty()</php> would appear not before than version 9.0		in a major version, hence the new function <php>is_empty()</php> would appear not before than version 9.0
		+
		+	The option of keeping <php>empty()</php> function together with ''is_empty()'' is fine too, so deprecation is not required: backward compatibility would be saved, though I would recommend the usage of ''is_empty()'' however.

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

empty_isset_exprs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/05/21 20:36		current
Line 2:		Line 2:
	* Date: 2012-04-12		* Date: 2012-04-12
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: In voting phase	+	* Status: Implemented
	* Original discussion: http://markmail.org/thread/gnci76ugtwda2t42 (Apr 10, 2012 3:53 pm)		* Original discussion: http://markmail.org/thread/gnci76ugtwda2t42 (Apr 10, 2012 3:53 pm)
	* RFC announcement: http://markmail.org/thread/ju2jyrenxkeddrnt (Apr 12, 2012 2:42 pm)		* RFC announcement: http://markmail.org/thread/ju2jyrenxkeddrnt (Apr 12, 2012 2:42 pm)
Line 66:		Line 66:
	* no		* no
	</doodle>		</doodle>
		+
		+	==== Result ====
		+
		+	The RFC was accepted with the option "Only empty()". The relevant commit it https://github.com/php/php-src/commit/ec061a93c53c8cde10237741e98e992c1a05d148.

encapsulation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Encapsulation ======
	+	* Version: 0.1
	+	* Date: 2015-02-19
	+	* Author: Leigh, leigh@php.net (Draft RFC) & Guilherme Blanco, guilhermeblanco@php.net (Implementation)
	+	* Status: Draft
	+	* First Published at: https://wiki.php.net/rfc/encapsulation

	+	===== Introduction =====
	+	This RFC proposes the introduction of encapsulation to classes, interfaces and traits within a namespace.
	+
	+	===== Proposal =====
	+	Since PHP 5.3 namespaces have been used as a tool to organise related pieces of functionality into named units. However it is often the case that not all of the functionality contained within a namespace is required to be exposed and accessible to other parts of the program, even if a well documented and complete API is presented a developer may still access the inner-most parts of the module.
	+
	+	With the application of encapsulation a developer trying to directly access functionality that was intended to only be used within the scope of the module (a helper class or utility function) will be denied this access, and it will serve as an indication that they are attempting to do something outside of the intended design.
	+
	+	This proposal is limited to the private visibility of classes, interfaces and traits, reusing the existing ''private'' keyword. There is plenty of room for future scope if the community decides that this type of functionality is desirable on the whole.
	+
	+	==== New Behaviour ====
	+	* Private classes can only be instantiated and extended within their defining namespace.
	+	* Private interfaces can only be implemented and extended within their defining namespace.
	+	* Private traits can only be extended and used in classes that are also defined within the same namespace.
	+	* Attempting to access a private class, interface or trait out of scope results in a fatal error.
	+
	+	==== Unchanged Behaviour ====
	+	Outside of the new behaviour introduced using the ''private'' keyword, other behaviour remains untouched. For example, once a private class has been instantiated the object can be returned to a caller in any namespace, and the methods and properties of an are accessible just as they would be for a public class. Private classes and interfaces can still be used for parameter hinting in any namespace, and checks such as ''implements'' can be used with them.
	+
	+	==== Reflection ====
	+	The following reflection methods have been implemented in the patch
	+	* ReflectionClass::isPublic()
	+	* ReflectionClass::isPrivate()
	+	* ReflectionClass::setAccessible()
	+
	+	==== Auto-loading ====
	+	Private visibility is respected when auto-loading is triggered from an invalid namespace.
	+
	+	==== Examples ====
	+	Instantiating a private class from an invalid scope
	+
	+	<code php>
	+	namespace Foo {
	+	private class Bar {}
	+
	+	function giveMeBar()
	+	{
	+	return new Bar;
	+	}
	+	}
	+
	+	$foobar = \Foo\giveMeBar(); // This is fine
	+	$foobar = new \Foo\Bar; // This is a fatal error
	+	</code>
	+
	+	Extending a private class from an invalid scope
	+
	+	<code php>
	+	namespace Foo {
	+	private class Bar {}
	+	}
	+
	+	namespace Baz {
	+	class Qux extends \Foo\Bar {} // This is a fatal error
	+	}
	+	</code>
	+
	+	Implementing a private interface from an invalid scope
	+
	+	<code php>
	+	namespace Foo {
	+	private interface Bar {}
	+	}
	+
	+	namespace Baz {
	+	class Qux implements \Foo\Bar {} // This is a fatal error
	+	}
	+	</code>
	+
	+	===== Backward Incompatible Changes =====
	+	There are no backward incompatible changes. No new keywords are introduced and the default visibility of classes remains ''public''.
	+
	+	===== Proposed PHP Version(s) =====
	+	7.0
	+
	+	===== RFC Impact =====
	+	==== To SAPIs ====
	+	All SAPIs are affected equally. They gain the new behaviour and do not suffer any breaks.
	+
	+	==== To Existing Extensions ====
	+	No existing extensions are affected, as this behaviour is not available to them yet.
	+
	+	==== To Opcache ====
	+	There are no new opcodes, and checks are performed at compile time as well as runtime.
	+
	+	===== Open Issues =====
	+	* I didn't see any special handling for ''clone'' in the patch, and have raised this with Guilherme
	+
	+	===== Future Scope =====
	+	There is future scope for similar behaviour to be applied to functions within a namespace, as well as the potential to use the ''protected'' keyword. However as these enhancements are likely to lead to extended debate, they should be covered in a separate RFC.
	+
	+	===== Proposed Voting Choices =====
	+	As a change to the functionality of the core language, this RFC requires at least 2/3 of the votes to be in favour of the proposal to pass.
	+
	+	===== Patches and Tests =====
	+	A complete implementation is available: https://github.com/php/php-src/pull/947
	+
	+	This is considered to be a near-final patch, unless significant changes are required or bugs identified during the RFC process.
	+
	+	===== References =====
	+	* [[http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29\|The Wikipedia article on Encapsulation]]
	+	* [[https://msdn.microsoft.com/en-us/library/dd460654.aspx#AccessModifiers\|Access Modifiers in C#]]
	+	* [[http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html\|Package Visibility in Java]]

engine_exceptions_for_php7

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/08 18:17		current
Line 2:		Line 2:
	* Date: 2014-09-30		* Date: 2014-09-30
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted (for PHP 7.0)	+	* Status: Implemented (in PHP 7.0)

	===== Introduction =====		===== Introduction =====

engine_exceptions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/12/10 13:52		current
Line 2:		Line 2:
	* Date: 2013-10-23		* Date: 2013-10-23
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: In Voting	+	* Status: Declined for 5.6
	* Proposed for: PHP 5.6		* Proposed for: PHP 5.6
	* Patch: https://github.com/nikic/php-src/compare/engineExceptions		* Patch: https://github.com/nikic/php-src/compare/engineExceptions
Line 349:		Line 349:
	If you are in favor of this proposal in general, but not for PHP 5.6, use the "No" voting option.		If you are in favor of this proposal in general, but not for PHP 5.6, use the "No" voting option.

-	<doodle title="Implement in PHP 5.6?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Implement in PHP 5.6?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* Yes, without E_RECOVERABLE_ERROR changes		* Yes, without E_RECOVERABLE_ERROR changes
Line 355:		Line 355:
	</doodle>		</doodle>

-	Vote started on 2013-12-07 and ends on 2013-12-14.	+	Vote started on 2013-12-07 and ended on 2013-12-14.

engine_warnings

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/09/26 07:31		current
Line 2:		Line 2:
	* Date: 2019-08-27		* Date: 2019-08-27
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Target Version: PHP 8.0		* Target Version: PHP 8.0

enhanced_error_handling

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/08/03 18:23		current
Line 3:		Line 3:
	* Date: 2010-01-10		* Date: 2010-01-10
	* Author: Hans-Peter Oeri <hp@oeri.ch>		* Author: Hans-Peter Oeri <hp@oeri.ch>
-	* Status: Drafting	+	* Status: Draft (Inactive)
	* First Published at: http://wiki.php.net/rfc/enhanced_error_handling		* First Published at: http://wiki.php.net/rfc/enhanced_error_handling

enum_allow_static_properties

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/15 13:49		current
Line 3:		Line 3:
	* Date: 2021-05-17		* Date: 2021-05-17
	* Author: Tyson Andre, <tandre@php.net>		* Author: Tyson Andre, <tandre@php.net>
-	* Status: Voting	+	* Status: Declined
	* Implementation: https://github.com/php/php-src/pull/6997		* Implementation: https://github.com/php/php-src/pull/6997
	* First Published at: http://wiki.php.net/rfc/enum_allow_static_properties		* First Published at: http://wiki.php.net/rfc/enum_allow_static_properties

enum_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/16 18:07		current
Line 3:		Line 3:
	* Date: 2020-05-14		* Date: 2020-05-14
	* Author: Max Semenik, maxsem.wiki@gmail.com		* Author: Max Semenik, maxsem.wiki@gmail.com
-	* Status: Draft	+	* Status: Obsolete
	* First Published at: http://wiki.php.net/rfc/enum_v2		* First Published at: http://wiki.php.net/rfc/enum_v2

enum

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 4:		Line 4:
	* Date: 2015-04-09		* Date: 2015-04-09
	* Authors: Bob Weinand <bwoebi@php.net>, Levi Morrison <levim@php.net>		* Authors: Bob Weinand <bwoebi@php.net>, Levi Morrison <levim@php.net>
-	* Status: In Draft	+	* Status: Obsolete
	* First Published at: http://wiki.php.net/rfc/enum		* First Published at: http://wiki.php.net/rfc/enum

enumerations_and_adts

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/11/13 23:33		current
Line 6:		Line 6:
	* Target Version: PHP 8.1		* Target Version: PHP 8.1
	* Implementation: TBD		* Implementation: TBD
		+
		+	This RFC has been supplanted by [[rfc:adts\|PHP RFC: Algebraic Data Types]].
		+
		+	Please ignore this page.
		+

	===== Introduction =====		===== Introduction =====

enumerations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/03/17 18:19		current
Line 151:		Line 151:
	return match($this) {		return match($this) {
	Suit::Hearts, Suit::Diamonds => 'Red',		Suit::Hearts, Suit::Diamonds => 'Red',
-	Suit::Clubs, Suit::Spaces => 'Black',	+	Suit::Clubs, Suit::Spades => 'Black',
	};		};
	}		}
Line 195:		Line 195:
	return match($this) {		return match($this) {
	Suit::Hearts, Suit::Diamonds => 'Red',		Suit::Hearts, Suit::Diamonds => 'Red',
-	Suit::Clubs, Suit::Spaces => 'Black',	+	Suit::Clubs, Suit::Spades => 'Black',
	};		};
	}		}
Line 277:		Line 277:
	return match($this) {		return match($this) {
	Suit::Hearts, Suit::Diamonds => 'Red',		Suit::Hearts, Suit::Diamonds => 'Red',
-	Suit::Clubs, Suit::Spaces => 'Black',	+	Suit::Clubs, Suit::Spades => 'Black',
	};		};
	}		}

enumset

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/03/14 08:16		current
Line 30:		Line 30:
	* It also is parent class to all ''UnitEnum''.		* It also is parent class to all ''UnitEnum''.
	* Its constructor creates an ''EnumSet<E>'' with all passed enum values.		* Its constructor creates an ''EnumSet<E>'' with all passed enum values.
-	* Doing an ''(array)'' cast on the ''EnumSet<E>'' instance returns all contained values.	+	* Doing an (explicit) ''(array)'' cast on the ''EnumSet<E>'' instance returns all contained values.
-	* Doing an (implicit) ''(bool)'' cast on the ''EnumSet<E>'' instance returns ''true'', unless it is empty. Then it returns ''false''.	+	* Doing an (explicit) ''(bool)'' cast on the ''EnumSet<E>'' instance returns ''true'', unless it is empty. Then it returns ''false''.
	* The ''cases'' static method is promoted to ''EnumSet<E>''. It also returns an ''EnumSet<E>'' containing all enum values instead of an array.		* The ''cases'' static method is promoted to ''EnumSet<E>''. It also returns an ''EnumSet<E>'' containing all enum values instead of an array.
	* Two ''EnumSet'' instances are only weakly equal (''=='') if the contents are the same. The order is ignored for equivalence checking.		* Two ''EnumSet'' instances are only weakly equal (''=='') if the contents are the same. The order is ignored for equivalence checking.
Line 123:		Line 123:
	The keys of this iterator are continuous and starting at zero.		The keys of this iterator are continuous and starting at zero.

-	''EnumSet'' instances can be cast to array like any other object. This is equivalent to applying ''iterator_to_array()'' here.	+	''EnumSet'' instances can be cast to array like any other object. This is equivalent to applying ''iterator_to_array()'' here. This is not special or different to ''(array)'' casts of other objects.

	Conversely, ''EnumSet'' being so close to arrays in behavior, the weak comparison (''=='') semantics of ''EnumSet'' are also identical to those of arrays: Two ''EnumSet'' instances are weakly equal if the contents are the same, regardless of the ordering.		Conversely, ''EnumSet'' being so close to arrays in behavior, the weak comparison (''=='') semantics of ''EnumSet'' are also identical to those of arrays: Two ''EnumSet'' instances are weakly equal if the contents are the same, regardless of the ordering.

eol-oniguruma

Anonymous (anonymous@undisclosed.example.com) — 2026-04-15T02:44:20+00:00

2026/04/10 00:39		current
Line 8:		Line 8:
	===== Introduction =====		===== Introduction =====

-	[[https://github.com/kkos/oniguruma\|Oniguruma]] maintenance ended on 2025-04-24. PHP uses mbregex (mb_ereg...) functions. So we decide future of mbregex. This proposal is ends of support mbregex PHP 9.0 and Deprecate 8.6.	+	[[https://github.com/kkos/oniguruma\|Oniguruma]] maintenance ended on 2025-04-24. PHP uses mbregex (mb_ereg...) functions. So we decide future of mbregex. This proposal is to end support for mbregex in PHP 9.0 and deprecate in 8.6.

	===== Proposal =====		===== Proposal =====
-	Deprecate mbregex functions in PHP 8.6, Delete 9.0.	+	Deprecate mbregex functions in PHP 8.6, remove in 9.0.
	<code>		<code>
	Deprecated: Function mb_ereg_replace() is deprecated since 8.6, Oniguruma functions support ends PHP 9.0 in %s on line %d		Deprecated: Function mb_ereg_replace() is deprecated since 8.6, Oniguruma functions support ends PHP 9.0 in %s on line %d
Line 23:		Line 23:
	* Drop support: 9.0		* Drop support: 9.0

-	Maintenance versions can use mbregex functions. However, FreeBSD will drop support on 2026-12-01 (ref: https://github.com/php/php-src/issues/18467#issuecomment-3044192511). We should decide what we will do after EOL in FreeBSD. (This is effect CI in php-src repository)	+	Maintenance versions can use mbregex functions. However, FreeBSD will drop support on 2026-12-01 (ref: https://github.com/php/php-src/issues/18467#issuecomment-3044192511). We should decide what we will do after EOL in FreeBSD. (This affects CI in the php-src repository)

-	I suggest to below:	+	I suggest:

-	* External packaging for example [[https://github.com/youkidearitai/mb_onig/]] (create by me)	+	* External packaging, for example [[https://github.com/youkidearitai/mb_onig/]] (created by me)
-	* Disable mbregex in configure option(--disable-mbregex)	+	* Disable mbregex in configure option (--disable-mbregex)


Line 63:		Line 63:
	In Ruby, There is a [[https://github.com/k-takata/Onigmo\|Onigmo]] forked from Oniguruma.		In Ruby, There is a [[https://github.com/k-takata/Onigmo\|Onigmo]] forked from Oniguruma.

-	However, Onigmo is different in Oniguruma.	+	However, Onigmo is different than Oniguruma.

-	* Performance(faster than Oniguruma)	+	* Performance (faster than Oniguruma)
	* Unicode version		* Unicode version
	* Some expressions: `\K`, `\R`, `(?(cond)yes\|no)`		* Some expressions: `\K`, `\R`, `(?(cond)yes\|no)`
	* Source: https://github.com/k-takata/Onigmo/blob/master/README		* Source: https://github.com/k-takata/Onigmo/blob/master/README

-	===== Libraries that depend on estimated Oniguruma =====	+	===== Libraries that depend on Oniguruma (estimated) =====

	I quoted from https://news-web.php.net/php.internals/130429		I quoted from https://news-web.php.net/php.internals/130429

-	Uses code from Juliette https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214	+	Uses code from Juliette: https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214

	<code>		<code>
Line 103:		Line 103:
	Thanks, Juliette.		Thanks, Juliette.

-	However, Probably proprietary software are uses mbregex functions. Impact is larger than that result.	+	However, proprietary software probably uses mbregex functions, so impact is larger than that result.

	===== External packaging for mb_onig =====		===== External packaging for mb_onig =====

-	This RFC is big impact from multibyte(not UTF-8) users.	+	This RFC has a big impact on multibyte (not UTF-8) users.

-	Therefore, I created bailout extension mb_onig [[https://packagist.org/packages/mb_onig/mb_onig]] that we can still use mbregex functions.	+	Therefore, I created bailout extension mb_onig [[https://packagist.org/packages/mb_onig/mb_onig]] so PHP 8.x can still use mbregex functions and we can still maintain mbregex for PHP 9.x.
-	So PHP 8.x can still use mbregex functions and we can still maintain mbregex for PHP 9.x.	+

-	=== Why name is `mb_onig`? ===	+	=== Why the name is `mb_onig`? ===

-	Debian/Ubuntu users calls Oniguruma to `onig`. I quoted this.	+	Debian/Ubuntu users call Oniguruma `onig`. I quoted this.

	<code>		<code>

error_backtraces_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2025/01/10 00:18		current
Line 3:		Line 3:
	* Date: 2024-12-05		* Date: 2024-12-05
	* Author: Eric Norris, erictnorris@gmail.com		* Author: Eric Norris, erictnorris@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/error_backtraces		* First Published at: https://wiki.php.net/rfc/error_backtraces
		+	* Implementation: https://github.com/php/php-src/commit/0a14ab18d2b3bcf1358aa9f25efc1ad72c18d000

	===== Introduction =====		===== Introduction =====

error_backtraces

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/04/17 18:30		current
Line 3:		Line 3:
	* Date: 2020-05-25		* Date: 2020-05-25
	* Author: Max Semenik, maxsem.wiki@gmail.com		* Author: Max Semenik, maxsem.wiki@gmail.com
-	* Status: Inactive	+	* Status: Obsolete
	* First Published at: https://wiki.php.net/rfc/error_backtraces		* First Published at: https://wiki.php.net/rfc/error_backtraces
		+
		+	> This proposal has been superseded by [[rfc:error_backtraces_v2\|Error Backtraces v2]], which has been implemented in PHP 8.5.

	===== Introduction =====		===== Introduction =====

error_handler_callback_parameters_passed_by_reference

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/02/27 23:16		current
Line 1:		Line 1:
	====== PHP RFC: Allow error_handler callback parameters to be passed by reference ======		====== PHP RFC: Allow error_handler callback parameters to be passed by reference ======
	* Version: 0.2		* Version: 0.2
-	* Date: 2015-02-13 (voting)	+	* Date: 2015-02-28
	* Authors: Reeze Xia <reeze@php.net>, Thomas Bley <mails@thomasbley.de>		* Authors: Reeze Xia <reeze@php.net>, Thomas Bley <mails@thomasbley.de>
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference		* First Published at: http://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference

error_reporting_e_notice

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== Request for Comments: Default error_reporting to include E_NOTICE ======
	+	* Version: 1.0
	+	* Date: 2012-02-27
	+	* Author: Richard Lynch <lynch@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/error_reporting_e_notice
	+	* PHP Version: 6.x and above only (Backwards Incompatible)
	+
	+	===== Abstract =====
	+
	+	This proposal suggests that PHP 6 change the php.ini.* default settings to include E_NOTICE.
	+
	+	This proposal specifically does not address E_STRICT nor E_DEPRECATED.
	+
	+	Others may wish to create RFCs for that, or merge them. I would prefer to consider them independently, as the reasoning for each is different.
	+
	+	===== Why? =====
	+
	+	I believe most experienced users will agree that E_NOTICE is a good tool for catching uninitialized variables and array elements that can sometimes point out logical errors in code.
	+
	+	While some do not use it, and others turn it off in PRODUCTION for performance purposes, as a development tool for beginners to PHP, it has a great deal of value.
	+
	+	Experts can trivially change the setting in any/all of the available locations for settings.
	+
	+	Certainly, far too many beginners create mailing list traffic with questions that boil down to misspelled variables or similar errors, because webhosts generally stick to default settings.
	+
	+	Including E_NOTICE will reduce the number of such questions and improve the skill-set of new users to PHP, by forcing them to write (arguably) better code, until they can make an informed decision to select their own preferred error_reporting levels.
	+
	+	One can argue that since PHP automatically initializes all variables, initialization is not strictly needed. While this is true:
	+	* Other languages require initialization, and for educational purpose for beginners, the concept is sound, even while not strictly required
	+	* Some bugs are introduced by misnaming / misspelling variables that were supposed to be the initialized value. E_NOTICE catches those.
	+	* In formal Computer Science, it's simply considered best practice to initialize variables, regardless of the "need" to do so.
	+
	+	===== History =====
	+
	+	This has been discussed on the mailing list several times.
	+
	+	Generally it devolves into whether we should also include E_STRICT and/or E_DEPRECATED and goes nowhere, as I recall.
	+
	+	Hence my preference for proposing E_NOTICE and only E_NOTICE, independently of the others.
	+
	+	I do apologize if this has been formally proposed and voted down before. I searched the RFCs for it, and did not find it.
	+
	+	===== Proposal and Patch =====
	+
	+	The php.ini.* files would be altered to: error_reporting = E_ALL
	+
	+	Even I could probably write a patch for that, though such a trivial patch is probably more quickly implemented by somebody with write karma.
	+
	+	===== Changelog =====
	+
	+	2012-02-27 Initial proposal.

error-formatting-for-developers

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/08/10 16:24		current
Line 4:		Line 4:
	* Date: 2011-07-26		* Date: 2011-07-26
	* Author: Derick Rethans <derick@php.net>		* Author: Derick Rethans <derick@php.net>
-	* Status: Voting	+	* Status: Implemented in PHP 5.4
	* Related RFCs: https://wiki.php.net/rfc/newinis		* Related RFCs: https://wiki.php.net/rfc/newinis

error-optimizations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2010-08-21		* Date: 2010-08-21
	* Author: Kalle Sommer Nielsen <kalle@php.net>		* Author: Kalle Sommer Nielsen <kalle@php.net>
-	* Status: In the works	+	* Status: Draft (Inactive)
	* First Published at: http://wiki.php.net/rfc/error-optimizations		* First Published at: http://wiki.php.net/rfc/error-optimizations

errors_as_exceptions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2009-07-24		* Date: 2009-07-24
	* Author: Ben Scholzen <mail@dasprids.de>		* Author: Ben Scholzen <mail@dasprids.de>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/errors_as_exceptions		* First Published at: http://wiki.php.net/rfc/errors_as_exceptions

escaper

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2012-09-18		* Date: 2012-09-18
	* Author: Pádraic Brady <padraic.brady.at.gmail.com>, Yasuo Ohgaki <yohgaki@php.net>		* Author: Pádraic Brady <padraic.brady.at.gmail.com>, Yasuo Ohgaki <yohgaki@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/escaper		* First Published at: http://wiki.php.net/rfc/escaper

escaping_operator

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/08/07 14:00		current
Line 334:		Line 334:

	Will this short tag / operator be useful for many people with the functionality described above?		Will this short tag / operator be useful for many people with the functionality described above?
-	<doodle title="Add new operator (short tag) for context-dependent escaping to next PHP 7.x?" auth="michael-vostrikov" voteType="single" closed="false">	+	<doodle title="Add new operator (short tag) for context-dependent escaping to next PHP 7.x?" auth="michael-vostrikov" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 342:		Line 342:
	Additional questions. Voting is not required if you have voted 'No' in the first vote.		Additional questions. Voting is not required if you have voted 'No' in the first vote.
	\\		\\
-	<doodle title="Is default handler required, with a possibility to fully unregister it?" auth="michael-vostrikov" voteType="single" closed="false">	+	<doodle title="Is default handler required, with a possibility to fully unregister it?" auth="michael-vostrikov" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 348:		Line 348:
	\\		\\

-	<doodle title="Is it needed to wrap the functions into static class?" auth="michael-vostrikov" voteType="single" closed="false">	+	<doodle title="Is it needed to wrap the functions into static class?" auth="michael-vostrikov" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 354:		Line 354:
	\\		\\

-	<doodle title="Is the comma suitable as a separation sign?" auth="michael-vostrikov" voteType="single" closed="false">	+	<doodle title="Is the comma suitable as a separation sign?" auth="michael-vostrikov" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

exception_bt_provide_object

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 11/04 - 2016		* Date: 11/04 - 2016
	* Author: Kalle Sommer Nielsen <kalle@php.net>		* Author: Kalle Sommer Nielsen <kalle@php.net>
-	* Status: Draft	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/exception_bt_provide_object		* First Published at: http://wiki.php.net/rfc/exception_bt_provide_object

exception_ignore_args_default_value

Anonymous (anonymous@undisclosed.example.com) — 2025-04-11T03:19:01+00:00

2025/04/09 01:52		current
Line 105:		Line 105:
	This RFC proposes changing:		This RFC proposes changing:

-	* the default INI value for ''zend.execution_ignore_args'' to ''On''	+	* the default INI value for ''zend.exception_ignore_args'' to ''On''
-	* the ''php.ini-development'' value of ''zend.execution_ignore_args'' to ''On''	+	* the ''php.ini-development'' value of ''zend.exception_ignore_args'' to ''On''
-	* the ''php.ini-production'' value of ''zend.execution_ignore_args'' to ''On''	+	* the ''php.ini-production'' value of ''zend.exception_ignore_args'' to ''On''

	==== To SAPIs ====		==== To SAPIs ====

exit-as-function

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/08/13 11:33		current
Line 4:		Line 4:
	* Date: 2024-05-05		* Date: 2024-05-05
	* Author: Gina Peter Banyard <girgias@php.net>		* Author: Gina Peter Banyard <girgias@php.net>
-	* Status: Pending	+	* Status: Implemented
	* Target Version: PHP 8.4		* Target Version: PHP 8.4
	* Implementation: <https://github.com/php/php-src/pull/13483>		* Implementation: <https://github.com/php/php-src/pull/13483>

expectations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/08 18:19		current
Line 249:		Line 249:

	* zend.assertions		* zend.assertions
-	* assert.exceptions	+	* assert.exception

	Two new settings are required to control the new assertion API; The reason for this is that to retain compatibility with the old assert API we need to have an error reporting mode that does not use exceptions.		Two new settings are required to control the new assertion API; The reason for this is that to retain compatibility with the old assert API we need to have an error reporting mode that does not use exceptions.
Line 257:		Line 257:
	Assertions should be enabled (zend.assertions=1) on development machines, and disabled (zend.assertions=0) in production.		Assertions should be enabled (zend.assertions=1) on development machines, and disabled (zend.assertions=0) in production.

-	Exceptions should be enabled (assert.exceptions=1) on development machines.	+	Exceptions should be enabled (assert.exception=1) on development machines.

	These defaults can be set in the development and production ini files we distribute.		These defaults can be set in the development and production ini files we distribute.
Line 264:		Line 264:

	* zend.assertions=1		* zend.assertions=1
-	* assert.exceptions=0	+	* assert.exception=0

	zend.assertions is an INI_SYSTEM setting, allowing for the safe removal of assertion opcodes.		zend.assertions is an INI_SYSTEM setting, allowing for the safe removal of assertion opcodes.

-	assert.exceptions is an INI_ALL setting, allowing for exceptions to be disabled at runtime.	+	assert.exception is an INI_ALL setting, allowing for exceptions to be disabled at runtime.

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

experimental

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/10/28 19:04		current
Line 27:		Line 27:
	cannot be marked as experimental.		cannot be marked as experimental.

-	New code, with no user base, can be considered experimental for a maximum of 2 years.	+	New code, with no user base, can be considered experimental for a
		+	maximum of 2 years.

	This allows the definition to apply to SAPI and extension code, and further clarifies what we can consider experimental, and for how long.		This allows the definition to apply to SAPI and extension code, and further clarifies what we can consider experimental, and for how long.

explicit_octal_notation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/11/25 12:21		current
Line 3:		Line 3:
	* Date: 2020-10-20		* Date: 2020-10-20
	* Author: George Peter Banyard, <girgias@php.net>		* Author: George Peter Banyard, <girgias@php.net>
-	* Status: Accepted	+	* Status: Implemented (https://git.php.net/?p=php-src.git;a=commit;h=589bdf30b2bea10172a49bcad26d44b18f192556)
	* First Published at: https://wiki.php.net/rfc/explicit_octal_notation		* First Published at: https://wiki.php.net/rfc/explicit_octal_notation

Line 81:		Line 81:
	===== Implementation =====		===== Implementation =====

-	After the project is implemented, this section should contain	+	Merged into PHP 8.1
-	- the version(s) it was merged into	+	- Commit: https://git.php.net/?p=php-src.git;a=commit;h=589bdf30b2bea10172a49bcad26d44b18f192556
-	- a link to the git commit(s)	+
	- a link to the PHP manual entry for the feature		- a link to the PHP manual entry for the feature
	- a link to the language specification section (if any)		- a link to the language specification section (if any)

explicit_send_by_ref

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/02/21 11:42		current
Line 4:		Line 4:
	* Proposed for: PHP 8.0		* Proposed for: PHP 8.0
	* Implementation: https://github.com/php/php-src/pull/2958		* Implementation: https://github.com/php/php-src/pull/2958
-	* Status: Under Discussion	+	* Status: Inactive

	===== Introduction =====		===== Introduction =====

explicit_this_parameter

Anonymous (anonymous@undisclosed.example.com) — 2026-04-07T15:29:25+00:00

2026/04/05 19:06		current
Line 43:		Line 43:
	We propose allowing a named argument <php>this:</php> to be combined with the “scope resolution operator” syntax of referring to a method to be used as an alternative way of calling an instance method. The value passed to the <php>this:</php> argument will effectively be used as the left side of the <php>-></php> operator.		We propose allowing a named argument <php>this:</php> to be combined with the “scope resolution operator” syntax of referring to a method to be used as an alternative way of calling an instance method. The value passed to the <php>this:</php> argument will effectively be used as the left side of the <php>-></php> operator.

-	Since the <php>this:</php> argument does not refer to a parameter in the underlying argument list and thus there is no ambiguity with regard to positional arguments it may be placed at any position of the argument list. In particular it may appear at the first position, before all positional arguments, mirroring the left-most position for a regular method call.	+	Since the <php>this:</php> argument does not refer to a parameter in the underlying parameter list and thus there is no ambiguity with regard to positional arguments it may be placed at any position of the argument list. In particular it may appear at the first position, before all positional arguments, mirroring the left-most position for a regular method call.

	<PHP>		<PHP>

extdep

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/02/18 22:30		current
Line 12:		Line 12:
	Describe how we could implement an extension dependency system to prevent system errors (symbol not found) and to avoid complex changes for the developers and users. The goal is to keep a single line in the config.* files, using the ADD_EXTENSION_DEP macro.		Describe how we could implement an extension dependency system to prevent system errors (symbol not found) and to avoid complex changes for the developers and users. The goal is to keep a single line in the config.* files, using the ADD_EXTENSION_DEP macro.

-	==== Why do we need RFCs? ====	+

	===== Common Misconceptions =====		===== Common Misconceptions =====

extended-string-types-for-pdo

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/03/17 13:37		current
Line 46:		Line 46:
	* No		* No
	</doodle>		</doodle>
		+
		+	===== Implementation =====
		+	This feature was implemented in PHP 7.2 ([[https://github.com/php/php-src/commit/4afce8ec8c6660ebd9f9eb174d2614361d1c6129\|4afce8ec8c6660ebd9f9eb174d2614361d1c6129]]).

extension_exceptions

Anonymous (anonymous@undisclosed.example.com) — 2025-05-28T09:05:43+00:00

2025/05/13 12:00		current
Line 3:		Line 3:
	* Date: 2025-04-27		* Date: 2025-04-27
	* Author: Tim Düsterhus timwolla@php.net, Gina Peter Banyard girgias@php.net		* Author: Tim Düsterhus timwolla@php.net, Gina Peter Banyard girgias@php.net
-	* Status: Voting	+	* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/extension_exceptions		* First Published at: https://wiki.php.net/rfc/extension_exceptions

Line 24:		Line 24:
	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

-	<doodle title="Accept php/policies PR #17 (Add Throwable policy) at commit cf4cfb3ea95e3a59a56a395e1fae00ff9722e0cd?" auth="timwolla" voteType="single" closed="false" closeon="2025-05-27T12:30:00Z">	+	<doodle title="Accept php/policies PR #17 (Add Throwable policy) at commit cf4cfb3ea95e3a59a56a395e1fae00ff9722e0cd?" auth="timwolla" voteType="single" closed="true" closeon="2025-05-27T12:30:00Z">
	* Yes		* Yes
	* No		* No

extension_prepend_files

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/01/04 12:55		current
Line 1:		Line 1:
	====== PHP RFC: Add PHP files to auto_prepend from extensions ======		====== PHP RFC: Add PHP files to auto_prepend from extensions ======
-	* Version: 0.1	+	* Version: 0.1.1
	* Date: 2015-01-04		* Date: 2015-01-04
	* Author: Benjamin Eberlei <kontakt@beberlei.de>		* Author: Benjamin Eberlei <kontakt@beberlei.de>

extensions_load_order

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/03/02 04:09		current
Line 1:		Line 1:
-	* * Unordered List Item * * Unordered List Item
	====== PHP RFC: Extension load priority ======		====== PHP RFC: Extension load priority ======
	* Version: 1.0		* Version: 1.0
Line 24:		Line 23:
	* Both zend_extension=s and extension=s will have this feature, meaning the above applies to both extension structs.		* Both zend_extension=s and extension=s will have this feature, meaning the above applies to both extension structs.
	* There will be a varity of verbose constants (that masks to an integer) available:		* There will be a varity of verbose constants (that masks to an integer) available:
-	* * ZEND_EXTPRIO_FIRST(1) - First priority, attempt to load first	+	* ZEND_EXTPRIO_FIRST(1) - First priority, attempt to load first
	* ZEND_EXTPRIO_SECOND(3) - Secondary priority, early load extension too, may depend on an extension with 'first' priority		* ZEND_EXTPRIO_SECOND(3) - Secondary priority, early load extension too, may depend on an extension with 'first' priority
	* ZEND_EXTPRIO_DEFAULT(5) - Default value, will be used in the STANDARD_MODULE_PROPERTIES[_EX] macro (like mbstring)		* ZEND_EXTPRIO_DEFAULT(5) - Default value, will be used in the STANDARD_MODULE_PROPERTIES[_EX] macro (like mbstring)
Line 33:		Line 32:

	Note, the value of ZEND_EXTPRIO_SECOND that defaults to 3 is intended.		Note, the value of ZEND_EXTPRIO_SECOND that defaults to 3 is intended.
		+
	Note, values below 1 is not allowed and values above 9 can be used but since we don't really need a bigger namespace range, 9 will do for last loading for now. Other values between 1 and 9 thats not masked to a constant can be used manually for tweaks, should that be needed.		Note, values below 1 is not allowed and values above 9 can be used but since we don't really need a bigger namespace range, 9 will do for last loading for now. Other values between 1 and 9 thats not masked to a constant can be used manually for tweaks, should that be needed.

extensionsiberia

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/04/14 18:40		current
Line 1:		Line 1:
-	Siberia, the graveyard for PHP Extensions	+	Siberia, the cemetery for PHP Extensions

	TBW		TBW

fallback-to-root-scope-deprecation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/02/03 16:20		current
Line 36:		Line 36:
	// Fallback to global scope shim		// Fallback to global scope shim
	// This code simply aliases \strlen to \Current\NS\strlen		// This code simply aliases \strlen to \Current\NS\strlen
-	// Note: this is just a PoC	+	// Note: this is just a non-binding PoC
	autoload_register(AUTOLOAD_FUNCTION \| AUTOLOAD_CONST, function(string $namespaced, int $type){		autoload_register(AUTOLOAD_FUNCTION \| AUTOLOAD_CONST, function(string $namespaced, int $type){
	// Assumes $namespaced is NOT prepended with \		// Assumes $namespaced is NOT prepended with \

fast_zpp

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/01/27 21:18		current
Line 3:		Line 3:
	* Date: 2014-05-23		* Date: 2014-05-23
	* Author: Dmitry Stogov <dmitry@zend.com>, Bob Weinand <bobwei9@hotmail.com>		* Author: Dmitry Stogov <dmitry@zend.com>, Bob Weinand <bobwei9@hotmail.com>
-	* Status: Voting	+	* Status: Implemented (PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/fast_zpp		* First Published at: http://wiki.php.net/rfc/fast_zpp

Line 99:		Line 99:
	</doodle>		</doodle>

-	The vote concludes on January 27th.	+	The vote concluded on January 27th.

	===== Patches and Tests =====		===== Patches and Tests =====

fcallfcall

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/02/10 17:40		current
Line 22:		Line 22:
	==== Other related things proposed =====		==== Other related things proposed =====

-	Expression syntax: (foo->bar())()	+	* Expression syntax: (foo->bar())()
-	Expression syntax for method calls: (new Foo)->bar()	+	* Expression syntax for method calls: (new Foo)->bar()
-	Array-fcall chaining: foo()[2]	+	* Array-fcall chaining: foo()[2]

fcc_in_const_expr

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2025/02/20 16:05		current
Line 3:		Line 3:
	* Date: 2025-01-07		* Date: 2025-01-07
	* Author: Tim Düsterhus (tim@tideways-gmbh.com), Volker Dusch (volker@tideways-gmbh.com)		* Author: Tim Düsterhus (tim@tideways-gmbh.com), Volker Dusch (volker@tideways-gmbh.com)
-	* Status: Accepted	+	* Status: Implemented
		+	* Target Version: PHP 8.5
		+	* Implementation: https://github.com/php/php-src/commit/2042fd34e09c949730570da3c52c20b0b19b7887
	* First Published at: http://wiki.php.net/rfc/fcc_in_const_expr		* First Published at: http://wiki.php.net/rfc/fcc_in_const_expr

Line 120:		Line 122:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged into	+	https://github.com/php/php-src/commit/2042fd34e09c949730570da3c52c20b0b19b7887
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+
-	- a link to the language specification section (if any)	+

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

fetch_property_in_const_expressions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/07/15 18:14		current
Line 2:		Line 2:
	* Date: 2022-05-27		* Date: 2022-05-27
	* Author: Ilija Tovilo <ilutov@php.net>		* Author: Ilija Tovilo <ilutov@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Proposed Version: PHP 8.2		* Proposed Version: PHP 8.2
	* Implementation: https://github.com/php/php-src/pull/8625		* Implementation: https://github.com/php/php-src/pull/8625

ffi-non-static-deprecated

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/06/21 08:49		current
Line 3:		Line 3:
	* Date: 2024-06-21		* Date: 2024-06-21
	* Author: Chopins, chopins.xiao@gmail.com		* Author: Chopins, chopins.xiao@gmail.com
		+	* Target version: PHP 8.4
	* Status: Draft		* Status: Draft
	* First Published at: https://wiki.php.net/rfc/ffi-non-static-deprecated		* First Published at: https://wiki.php.net/rfc/ffi-non-static-deprecated
Line 49:		Line 50:
	Since non-static calls are marked as stale, they will result in a stale prompt being received for versions less than PHP 8.3. If PHP 9.0 removes non-static calls to FFICDef::new(), FFICDef::cast(), FFICDef::type(), it will result in an error in the unadapted program.		Since non-static calls are marked as stale, they will result in a stale prompt being received for versions less than PHP 8.3. If PHP 9.0 removes non-static calls to FFICDef::new(), FFICDef::cast(), FFICDef::type(), it will result in an error in the unadapted program.
	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
-	PHP 8.3	+	PHP 8.4
	===== Impact on extensions =====		===== Impact on extensions =====
	FFI		FFI

ffi

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/05/06 08:33		current
Line 3:		Line 3:
	* Date: 2018-12-04		* Date: 2018-12-04
	* Author: Dmitry Stogov, dmitry@zend.com		* Author: Dmitry Stogov, dmitry@zend.com
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.4)
	* First Published at: https://wiki.php.net/rfc/ffi		* First Published at: https://wiki.php.net/rfc/ffi

fiber

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/06/10 13:54		current
Line 3:		Line 3:
	* Date: 2017-09-13		* Date: 2017-09-13
	* Author: Haitao Lv<i@lvht.net>, Dmitry Stogov<dmitry@zend.com>, Martin Schröder<m.schroeder2007@googlemail.com>		* Author: Haitao Lv<i@lvht.net>, Dmitry Stogov<dmitry@zend.com>, Martin Schröder<m.schroeder2007@googlemail.com>
-	* Status: Voting	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/fiber		* First Published at: http://wiki.php.net/rfc/fiber

Line 135:		Line 135:

	Syntax like async/await can be implemented in the future, but it's out of the scope of this RFC.		Syntax like async/await can be implemented in the future, but it's out of the scope of this RFC.
-
-	===== Proposed Voting Choices =====
-	2/3+1 voting majority
-	<doodle title="RFC name here" auth="your_username_here" voteType="single" closed="false">
-	* Yes
-	* No
-	</doodle>

	===== Patches and Tests =====		===== Patches and Tests =====

fibers

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/04/26 20:43		current
Line 49:		Line 49:

	A Fiber would be represented as class which would be defined in core PHP with the following signature:		A Fiber would be represented as class which would be defined in core PHP with the following signature:
		+
		+	<blockquote>Fiber::this() has been renamed to Fiber::getCurrent() during the PHP 8.1 alpha release phase.</blockquote>

	<code php>		<code php>

file-descriptor-function

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Add file_descriptor() function ======

	+	* Version: 0.1
	+	* Date: 2023-01-16
	+	* Author: George Peter Banyard, <girgias@php.net>
	+	* Status: Under Discussion
	+	* Target Version: PHP 8.3
	+	* Implementation: [[https://github.com/php/php-src/pull/10342]]
	+	* First Published at: [[http://wiki.php.net/rfc/file-descriptor-function]]
	+
	+	===== Introduction =====
	+
	+	When dealing with I/O in PHP, one deals with streams as an abstraction over the file system. This abstraction is convenient in giving a uniform interface without needing to deal with the underlying system. However, sometimes one needs to deal with the file system directly via the file descriptor, for example when interacting with a USB device.
	+
	+	PHP supports retrieving the file descriptor of a stream within the engine, but does not expose this capability to userland. However, with the [[https://github.com/ppelisset/php-fileno\|magic of FFI]] it is possible to expose the underlying file descriptor of a stream if it exists, by stubbing out the Zend engine.
	+
	+	This RFC address this issue by proposing the addition of a native <php>file_descriptor()</php> function.
	+
	+
	+	===== Proposal =====
	+
	+	The proposal is to add the following function to PHP:
	+	<PHP>
	+	/** @param resource $stream */
	+	function file_descriptor($stream): int {}
	+	</PHP>
	+
	+	Which returns the underlying file descriptor of a stream if it exists, or throws a ''TypeError'' if the resource is not a stream or does not have an underlying file descriptor.
	+
	+
	+	===== Backward Incompatible Changes =====
	+
	+	This RFC does not contain any backwards incompatible changes.
	+
	+	===== Proposed PHP Version =====
	+
	+	Next minor version, i.e. PHP 8.3.
	+
	+	===== Proposed Voting Choices =====
	+
	+	As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.
	+
	+	Voting started on 2023-XX-XX and will end on 2023-XX-XX.
	+	<doodle title="Accept Add file_descriptor function RFC?" auth="girgias" voteType="single" closed="true">
	+	* Yes
	+	* No
	+	</doodle>
	+
	+	===== Implementation =====
	+
	+	GitHub pull request: https://github.com/php/php-src/pull/10342
	+
	+	After the project is implemented, this section should contain
	+
	+	* the version(s) it was merged into
	+	* a link to the git commit(s)
	+	* a link to the PHP manual entry for the feature
	+
	+	===== References =====
	+
	+	FFI implementation: [[https://github.com/ppelisset/php-fileno]]\\
	+	AFUP Forum PHP Talk (in French) describing the use case: [[https://www.youtube.com/watch?v=oUtJrx0ElUc\|FFI : De nouveaux horizons pour PHP - Pierre PELISSET - Forum PHP 2022]]

filter_throw_on_failure

Anonymous (anonymous@undisclosed.example.com) — 2025-08-26T11:10:33+00:00

2025/08/08 01:09		current
Line 3:		Line 3:
	* Date: 2025-06-21		* Date: 2025-06-21
	* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com		* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com
-	* Status: Pending implementation / landing	+	* Status: Implemented
	* Implementation: https://github.com/php/php-src/pull/18896		* Implementation: https://github.com/php/php-src/pull/18896

filter_validate_strlen

Anonymous (anonymous@undisclosed.example.com) — 2026-03-19T02:11:22+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== Add FILTER_VALIDATE_STRLEN for UTF-8 code point length validation ======

	+	* Date: 2026-03-19
	+	* Author: Masaki Kagaya masakielastic@gmail.com
	+	* Status: Draft
	+	* Implementation: https://github.com/php/php-src/pull/21429
	+
	+
	+
	+	===== Introduction =====
	+	This RFC treats code-point length validation as part of PHP’s built-in validation baseline rather than as a specialized text-processing feature.
	+
	+	===== Proposal =====
	+	This RFC proposes adding a new validation filter, ''FILTER_VALIDATE_STRLEN''.
	+
	+	The filter validates the length of a string measured in Unicode code points derived from UTF-8 input.
	+
	+	Example:
	+
	+	<PHP>
	+	<?php
	+	filter_var("hello😀", FILTER_VALIDATE_STRLEN, [
	+	"options" => [
	+	"min_len" => 6,
	+	"max_len" => 6,
	+	],
	+	]);
	+	</PHP>
	+
	+	In this example, validation succeeds because the input length is exactly 6 Unicode code points, so the original string is returned.
	+
	+	''FILTER_VALIDATE_STRLEN'' accepts min_len and max_len as length bounds. At least one of these options must be specified. If both are specified, min_len must be less than or equal to max_len.
	+
	+	On success, the filter returns the original string. On failure, it returns false, or null if ''FILTER_NULL_ON_FAILURE'' is used.
	+
	+	This filter performs length validation only. It does not validate whether the input is well-formed UTF-8.
	+
	+	===== Backward Incompatible Changes =====
	+	None. This RFC adds a new validation filter and does not change the behavior of existing filters.
	+
	+	===== Proposed PHP Version(s) =====
	+	Next PHP 8.x (PHP 8.6).
	+
	+	===== FAQ =====
	+	==== Why add a length validator to filter? ====
	+
	+	Validation baseline consistency.
	+
	+	Length validation is a common rule, but it is currently expressed through fragmented extension-specific or userland approaches. Placing it in the filter API provides a shared validation baseline for this class of check.
	+
	+	==== Why does this validator require UTF-8 input? ====
	+
	+	UTF-8 keeps the feature narrowly scoped and semantically clear.
	+
	+	A code-point-based validator needs a defined encoding context. Multi-encoding support would raise additional questions about API shape and behavior, which are outside the scope of this RFC.
	+
	+	==== Why measure length in Unicode code points instead of grapheme clusters? ====
	+
	+	Predictable validation semantics.
	+
	+	Code-point length provides a stable and deterministic measure suitable for validation. Grapheme-cluster-based validation raises additional boundary and API design questions, so this RFC keeps the scope limited to code-point length.
	+
	+	==== Why not reuse min_range and max_range? ====
	+
	+	''min_len'' and ''max_len'' make the option semantics specific to string length.
	+
	+	''min_range'' and ''max_range'' are associated with numeric validation in filter. Using length-specific names keeps the constraint explicit and avoids reusing numeric range terminology for a different validation model.
	+
	+	==== Why is max_len = 0 allowed? ====
	+
	+	Allowing ''max_len = 0'' keeps the boundary rules complete and consistent.
	+
	+	A zero upper bound has a clear meaning: only the empty string can satisfy it. Disallowing it would add a special case without improving the model.
	+
	+	==== Why not validate UTF-8? ====
	+
	+	Ambiguous failure semantics.
	+
	+	The filter API returns a single validation result, which cannot distinguish between length failure and encoding failure. Keeping this filter limited to length validation avoids combining two different validation concerns into one result.
	+
	+	==== Is a UTF-8 encoding validator needed? ====
	+
	+	Separate design question.
	+
	+	This RFC does not address UTF-8 validity. Whether encoding validation should be introduced, and how it should be exposed, remains a separate design question.

final_anonymous_classes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/12/05 18:24		current
Line 2:		Line 2:
	* Date: 2023-11-15		* Date: 2023-11-15
	* Author: Daniil Gentili <daniil@daniil.it>		* Author: Daniil Gentili <daniil@daniil.it>
-	* Status: Voting	+	* Status: Declined

	===== Introduction =====		===== Introduction =====
Line 49:		Line 49:
	2/3 required to accept. Voting started on 2023-12-03 and will end on 2023-12-18 00:00 GMT.		2/3 required to accept. Voting started on 2023-12-03 and will end on 2023-12-18 00:00 GMT.

-	<doodle title="Add support for final anonymous classes?" auth="danog" voteType="single" closed="false" closeon="2023-12-18T00:00:00Z">	+	<doodle title="Add support for final anonymous classes?" auth="danog" voteType="single" closed="true" closeon="2023-12-18T00:00:00Z">
	* Yes		* Yes
	* No		* No

final_by_default_anonymous_classes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/01/15 14:36		current
Line 2:		Line 2:
	* Date: 2023-12-23		* Date: 2023-12-23
	* Author: Daniil Gentili <daniil@daniil.it>		* Author: Daniil Gentili <daniil@daniil.it>
-	* Status: Voting	+	* Status: Declined

	===== Introduction =====		===== Introduction =====
Line 74:		Line 74:
	2/3 required to accept.		2/3 required to accept.

-	<doodle title="Make final anonymous classes final by default?" auth="danog" voteType="single" closed="false" closeon="2024-01-30T00:00:00Z">	+	<doodle title="Make final anonymous classes final by default?" auth="danog" voteType="single" closed="true" closeon="2024-01-30T00:00:00Z">
	* Yes		* Yes
	* No		* No
Line 82:		Line 82:
	2/3 required to accept.		2/3 required to accept.

-	<doodle title="Add an optional open keyword for anonymous classes?" auth="danog" voteType="single" closed="false" closeon="2024-01-30T00:00:00Z">	+	<doodle title="Add an optional open keyword for anonymous classes?" auth="danog" voteType="single" closed="true" closeon="2024-01-30T00:00:00Z">
	* Yes		* Yes
	* No		* No

final_class_const

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/06/14 07:48		current
Line 2:		Line 2:
	* Date: 2021-04-23		* Date: 2021-04-23
	* Author: Máté Kocsis <kocsismate@php.net>		* Author: Máté Kocsis <kocsismate@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* Implementation: https://github.com/php/php-src/pull/6878		* Implementation: https://github.com/php/php-src/pull/6878
	* Target Version: PHP 8.1		* Target Version: PHP 8.1

final_promotion

Anonymous (anonymous@undisclosed.example.com) — 2025-06-22T19:45:22+00:00

2025/06/11 17:19		current
Line 3:		Line 3:
	* Date: 2025-03-24		* Date: 2025-03-24
	* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com		* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com
-	* Status: Pending Implementation	+	* Status: Implemented (PHP 8.5)
	* First Published at: https://wiki.php.net/rfc/final_promotion		* First Published at: https://wiki.php.net/rfc/final_promotion
	* Implementation: https://github.com/php/php-src/pull/17861		* Implementation: https://github.com/php/php-src/pull/17861

final_properties

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/02/18 22:30		current
Line 11:		Line 11:

	===== Proposal =====		===== Proposal =====
-	"Write-once" properties in PHP (the actual keyword is to be decided) could be initialized either by an explicit default value, or by assigning a value to them. Unlike to ''final'' properties in Java, this RFC proposes to allow the initialization of object properties after object construction. The main purpose of this behaviour is to make lazy loading possible - which is an important aspect for many PHP applications. In addition to object properties, class properties can also use the modifier in question with the same rules.	+	"Write-once" properties in PHP (the actual keyword is to be decided) could be initialized either by an explicit default value, or by assigning a value to them. Unlike to ''final'' properties in Java, this RFC proposes to allow the initialization of object properties after object construction. The main purpose of this approach is to make lazy loading possible - which is an important aspect for many PHP applications. In addition to object properties, class properties can also use the modifier in question with the same rules.

-	As soon as initialization is done, any other attempt to assign a value to "write-once" properties results in an exception. Besides assignment, the increment, decrement, and unset operations are also forbidden. As arrays are an immutable data structure in PHP, any attempt to mutate a property of array type (adding/removing/changing items) is forbidden. However, since objects or resources are treated by-reference, they can be	+	As soon as initialization is done, any other attempt to assign a value to "write-once" properties results in an exception. Besides assignment, the increment, decrement, and unset operations are also forbidden. As arrays are an immutable data structure in PHP, any attempt to mutate a property of array type (adding/removing/changing items) is forbidden. However, properties of object or resource types still remain mutable internally. In order to avoid problems with references, references on "write-once" properties are disabled as well.

	<code php>		<code php>
Line 43:		Line 43:
	</code>		</code>

-	As untyped properties have an implicit default value (''null'') in the absense of an explicit one, their usefulness would be very limited. In order to avoid the introduction or unintiutive workarounds, this RFC proposes to disable the property modifier in question for them. Contrarily to untyped properties, typed properties are in uninitialized state by default, so they play well with the write-once semantics. In order to be safe from problems with references, references on "write-once" properties are disabled as well.	+	As untyped properties have an implicit default value (''null'') in the absense of an explicit one, their usefulness would be very limited. In order to avoid the introduction or unintiutive workarounds, this RFC proposes to disable the property modifier in question for them. Contrarily to untyped properties, typed properties are in uninitialized state by default, so they play well with the write-once semantics.

-	===== Open questions =====	+	===== Discussion =====
		+
		+	==== Approach ====
		+
		+	==== Name choice ====
	As there is no consensus about the name of the modifier, I'd like to put it to vote. You can find below the ideas that came up during discussion along with some pros/cons:		As there is no consensus about the name of the modifier, I'd like to put it to vote. You can find below the ideas that came up during discussion along with some pros/cons:

Line 55:		Line 59:
	* ''sealed'': It has the same properties as ''locked'', and this keyword is also used in C# (similarly to ''final'' in PHP)		* ''sealed'': It has the same properties as ''locked'', and this keyword is also used in C# (similarly to ''final'' in PHP)

-	Considering the above, I'd like to propose "locked", "sealed", and "writeonce" as voting choices of the decision about the keyword.	+	Considering the above, "locked", "sealed", and "writeonce" is going to be proposed as voting choices of the decision about the keyword.

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

finally

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/08/14 16:54		current
Line 3:		Line 3:
	* Date: 2012/07/24		* Date: 2012/07/24
	* Author: Xinchen Hui <laruence@php.net>		* Author: Xinchen Hui <laruence@php.net>
-	* Status: Under Discussion	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/finally		* First Published at: http://wiki.php.net/rfc/finally
	* Alternative Reading: <Finally Getting finally In PHP?> http://sheriframadan.com/2012/08/finally-keyword-in-php/ by GoogleGuy		* Alternative Reading: <Finally Getting finally In PHP?> http://sheriframadan.com/2012/08/finally-keyword-in-php/ by GoogleGuy

first_class_callable_syntax

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/07/02 10:42		current
Line 2:		Line 2:
	* Date: 2021-05-20		* Date: 2021-05-20
	* Author: Nikita Popov <nikic@php.net>, Joe Watkins <krakjoe@php.net>		* Author: Nikita Popov <nikic@php.net>, Joe Watkins <krakjoe@php.net>
-	* Status: Voting	+	* Status: Implemented
	* Target Version: PHP 8.1		* Target Version: PHP 8.1
	* Implementation: https://github.com/php/php-src/pull/7019		* Implementation: https://github.com/php/php-src/pull/7019
Line 219:		Line 219:
	Voting started on 2021-07-02 and closes on 2021-07-16.		Voting started on 2021-07-02 and closes on 2021-07-16.

-	<doodle title="Introduce first-class callable syntax as proposed?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Introduce first-class callable syntax as proposed?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

fix_list_behavior_inconsistency

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/10/05 20:15		current
Line 61:		Line 61:
	</doodle>		</doodle>

-	===== Patches and Tests =====	+	===== Implementation =====
-	The implementation is not really a problem.	+
		+	Support for strings has been removed for all cases. Support for ''ArrayAccess'' has been added for all cases (previously it was not supported for temporary variables).
		+
		+	https://github.com/php/php-src/commit/7c7b9184b1fdf7add1715079f22241bc1185fcb0

fix_up_bcmath_number_class

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/07/30 00:01		current
Line 3:		Line 3:
	* Date: 2024-06-30		* Date: 2024-06-30
	* Author: Saki Takamachi (saki@php.net)		* Author: Saki Takamachi (saki@php.net)
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/fix_up_bcmath_number_class		* First Published at: https://wiki.php.net/rfc/fix_up_bcmath_number_class

Line 154:		Line 154:

	===== Implementation =====		===== Implementation =====
-	None.	+	https://github.com/php/php-src/pull/13741
		+	https://github.com/php/php-src/pull/15151

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

flexible_heredoc_nowdoc_indentation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/15 22:21		current
Line 5:		Line 5:
	* Status: Draft		* Status: Draft
	* First Published at: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_indentation		* First Published at: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_indentation
		+
		+	This RFC has been superseded by [[rfc:flexible_heredoc_nowdoc_syntaxes\|PHP RFC: Flexible Heredoc and Nowdoc Syntaxes]]

	===== Introduction =====		===== Introduction =====

flexible_heredoc_nowdoc_syntaxes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/11/24 08:18		current
Line 3:		Line 3:
	* Date: 2017-09-16		* Date: 2017-09-16
	* Author: Thomas Punt, tpunt@php.net		* Author: Thomas Punt, tpunt@php.net
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.3)
	* First Published at: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes		* First Published at: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes

forbid_dynamic_scope_introspection

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/05/24 16:39		current
Line 3:		Line 3:
	* Date: 2016-05-01		* Date: 2016-05-01
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted (for PHP 7.1)	+	* Status: Implemented (in PHP 7.1)
-	* Target version: PHP 7.1	+

	===== Introduction =====		===== Introduction =====
Line 19:		Line 18:
	* parse_str() with one arg		* parse_str() with one arg
	* mb_parse_str() with one arg		* mb_parse_str() with one arg
		+	* assert() with string argument (eval)
	* func_get_args()		* func_get_args()
	* func_get_arg()		* func_get_arg()
Line 125:		Line 125:
	===== Vote =====		===== Vote =====

-	The vote requires a 2/3 majority. Voting closes on 2016-05-24.	+	The vote requires a 2/3 majority. Voting closed on 2016-05-24.

	<doodle title="Forbid dynamic calls to scope introspection functions?" auth="nikic" voteType="single" closed="true">		<doodle title="Forbid dynamic calls to scope introspection functions?" auth="nikic" voteType="single" closed="true">

forbid_null_this_in_methods

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/04/29 19:23		current
Line 3:		Line 3:
	* Date: 2016-04-29		* Date: 2016-04-29
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Draft	+	* Status: Withdrawn
	* Target version: PHP 7.1		* Target version: PHP 7.1
	* Patch: https://github.com/php/php-src/pull/1894		* Patch: https://github.com/php/php-src/pull/1894

foreach_unwrap_ref

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/08/26 14:23		current
Line 2:		Line 2:
	* Date: 2021-08-13		* Date: 2021-08-13
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Target Version: PHP 8.2		* Target Version: PHP 8.2
	* Implementation: https://github.com/php/php-src/pull/7364		* Implementation: https://github.com/php/php-src/pull/7364

foreach_void

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-01-09		* Date: 2016-01-09
	* Author: John Bafford, john@bafford.com		* Author: John Bafford, john@bafford.com
-	* Status: Draft (or Under Discussion or Accepted or Declined)	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/foreach_void		* First Published at: http://wiki.php.net/rfc/foreach_void

foreach-non-scalar-keys

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/03/12 16:47		current
Line 59:		Line 59:
	int (get_current_key)(zend_object_iterator iter, char *str_key, uint str_key_len, ulong *int_key TSRMLS_DC);		int (get_current_key)(zend_object_iterator iter, char *str_key, uint str_key_len, ulong *int_key TSRMLS_DC);
	// Is replaced with this entry:		// Is replaced with this entry:
-	zval (get_current_key)(zend_object_iterator *iter TSRMLS_DC);	+	void (get_current_key)(zend_object_iterator iter, zval *key TSRMLS_DC);
	</code>		</code>

-	The handler will return a ''zval'' with already increased refcount. The ''zval'' may not be ''NULL'', unless an exception was thrown.**	+	The handler has to write into the passed ''zval'' using one* of the ''ZVAL_'' macros*.
-		+
-	*The signature can use ''zval'' instead of ''zval'' because by-ref modification of keys is not possible. The refcount is increased in the handler (instead of the VM) as that turned out to be the more convenient method for this use case.	+

	===== iterator_to_array() =====		===== iterator_to_array() =====
Line 90:		Line 88:
	===== Patch =====		===== Patch =====

-	A preliminary patch implementing the above proposal can be found here: https://github.com/php/php-src/pull/278	+	The patch for this change can be found here: https://github.com/php/php-src/commit/fcc6611de9054327441786e52444b5f8eecdd525

	The change itself is rather small, but there are quite a few extensions that require minor adjustments to use the new API.		The change itself is rather small, but there are quite a few extensions that require minor adjustments to use the new API.

foreachlist

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/10/19 18:59		current
Line 14:		Line 14:
	$users = array(		$users = array(
	array('Foo', 'Bar'),		array('Foo', 'Bar'),
-	array('Baz', 'Qux');	+	array('Baz', 'Qux'),
	);		);

fpm_change_hat

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/09/06 09:55		current
Line 4:		Line 4:
	* Date: 2013-06-09		* Date: 2013-06-09
	* Author: Gernot Vormayr, gvormayr@gmail.com		* Author: Gernot Vormayr, gvormayr@gmail.com
-	* Status: Accepted	+	* Status: Implemented (PHP 5.6) https://github.com/php/php-src/pull/373
	* First Published at: http://wiki.php.net/rfc/fpm_change_hat		* First Published at: http://wiki.php.net/rfc/fpm_change_hat

fpm

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2010-03-22		* Date: 2010-03-22
	* Author: Antony Dovgal <tony.at.daylessday.dot.org>		* Author: Antony Dovgal <tony.at.daylessday.dot.org>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.3
	* First Published at: http://wiki.php.net/rfc/fpm		* First Published at: http://wiki.php.net/rfc/fpm

free-json-parser

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/08/28 09:16		current
Line 1:		Line 1:

	====== PHP RFC: Switch from json extension to jsonc ======		====== PHP RFC: Switch from json extension to jsonc ======
-	* Version: 0.1	+	* Version: 1.0
	* Date: 2013-08-25		* Date: 2013-08-25
	* Author: Remi Collet <remi@php.net>		* Author: Remi Collet <remi@php.net>
-	* Status: Draft (or Under Discussion or Accepted or Declined)	+	* Status: Under Discussion (or Accepted or Declined)
	* First Published at: https://wiki.php.net/rfc/free-json-parser		* First Published at: https://wiki.php.net/rfc/free-json-parser

friend-classes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/07/07 18:14		current
Line 3:		Line 3:
	* Date: 2017-09-21		* Date: 2017-09-21
	* Author: Dustin Wheeler, mdwheele@ncsu.edu		* Author: Dustin Wheeler, mdwheele@ncsu.edu
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/friend-classes		* First Published at: http://wiki.php.net/rfc/friend-classes

Line 319:		Line 319:
	Voting starts on 2018-07-06 21:00 UTC and closes on 2018-07-13 21:00 UTC.		Voting starts on 2018-07-06 21:00 UTC and closes on 2018-07-13 21:00 UTC.

-	<doodle title="Support Class Friendship?" auth="mdwheele" voteType="single" closed="false">	+	<doodle title="Support Class Friendship?" auth="mdwheele" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

fsync_function

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/04/03 16:52		current
Line 3:		Line 3:
	* Date: 2021-01-30		* Date: 2021-01-30
	* Author: David Gebler, me@davegebler.com		* Author: David Gebler, me@davegebler.com
-	* Status: Accepted	+	* Status: Implemented (in PHP 8.1)
	* First Published at: http://wiki.php.net/rfc/fsync_function		* First Published at: http://wiki.php.net/rfc/fsync_function

func_get_args_by_name

Anonymous (anonymous@undisclosed.example.com) — 2025-12-17T09:08:35+00:00

2025/12/02 13:00		current
Line 2:		Line 2:

	* Version: 1.0		* Version: 1.0
-	* Date: 2025-12-02	+	* Date: 2025-12-17
	* Author: Alexandre Daubois <alexandredaubois@php.net>		* Author: Alexandre Daubois <alexandredaubois@php.net>
	* Status: Under Discussion		* Status: Under Discussion
Line 97:		Line 97:
	?>		?>
	</PHP>		</PHP>
		+
		+	==== Considered alternative ====
		+
		+	Another approach would be to add a new argument to <php>func_get_args()</php>, like <php>bool $assoc = false</php>. However:
		+
		+	* Adding a boolean flag is usually considered being against single responsibility principle
		+	* Setting the flag to true would change the function core behavior (because of the support of variadic arguments), which would also be against the principle of least astonishment
		+
		+	For these reasons, this alternative was rejected.

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

function_alias

Anonymous (anonymous@undisclosed.example.com) — 2025-07-24T07:09:40+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Function Alias for class methods declaration ======
	+	* Version: 1
	+	* Date: 2025-07-24
	+	* Author: Dmitrii Derepko, xepozzd@gmail.com
	+	* Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")
	+	* Implementation: https://github.com/...

	+	===== Introduction =====
	+
	+	Modern languages use short constructions to boost developer experience. PHP as a modern language should follow in steps as well and re-use best practices of the others. I would like to make the <php>fn</php> keyword available to declare class methods.
	+
	+	Modern languages, such as Kotlin, Rust, Python use short function declaration keywords such as <php>fn</php>, <php>fun</php>, <php>def</php>.
	+
	+	PHP uses <php>function</php> which is 4x longer that <php>fn</php>, which is already in use in other parts of the language, such as closures.
	+
	+
	+	===== Proposal =====
	+
	+	Make <php>fn</php> keyword fully aliased for class methods:
	+
	+
	+	<PHP>
	+	<?php
	+
	+	class A {
	+	fn main() { // "fn" instead "function"
	+	echo "main function";
	+	}
	+
	+	fn __construct() { // constructor's function can be changed as well
	+	echo "__construct function";
	+	}
	+
	+	function __destruct() { // classic "function" is still available
	+	echo "__destruct function";
	+	}
	+	}
	+
	+	?>
	+	</PHP>
	+
	+	This is fully equivalent to
	+
	+	<PHP>
	+	<?php
	+
	+	class A {
	+	function __construct() {
	+	echo "__construct function";
	+	}
	+
	+	function main() {
	+	echo "main function";
	+	}
	+
	+	function __destruct() {
	+	echo "__destruct function";
	+	}
	+	}
	+
	+	?>
	+	</PHP>
	+
	+	==== Examples ====
	+	Remember that the RFC contents should be easily reusable in the PHP Documentation. This means, if at all possible, they should be runnable as standalone, self-contained code with the proof-of-concept implementation.
	+
	+	Simple example:
	+	<PHP>
	+	<?php
	+
	+	class A {
	+	fn main() { // all methods are public by default
	+	echo "main function";
	+	}
	+
	+	public fn main() {
	+	echo "main function";
	+	}
	+
	+	protected fn main() {
	+	echo "main function";
	+	}
	+
	+	private fn main() {
	+	echo "main function";
	+	}
	+
	+	abstract fn main();
	+	}
	+	?>
	+	</PHP>
	+
	+	Example showing an edge case:
	+	<PHP>
	+	<?php
	+
	+	echo "Edge case";
	+
	+	?>
	+	</PHP>
	+
	+	===== Backward Incompatible Changes =====
	+
	+	- Breaks backward compatibility because of new syntax construction.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	PHP 9.0
	+
	+	===== RFC Impact =====
	+	==== To the Ecosystem ====
	+	What effect will the RFC have on IDEs, Language Servers (LSPs), Static Analyzers, Auto-Formatters, Linters and commonly used userland PHP libraries?
	+
	+	==== To Existing Extensions ====
	+	Will existing extensions be affected?
	+
	+	==== To SAPIs ====
	+	Describe the impact to CLI, Development web server, embedded PHP etc.
	+
	+	===== Open Issues =====
	+	Make sure there are no open issues when the vote starts!
	+
	+	===== Future Scope =====
	+
	+	- [RFC] Function Alias for function declaration
	+
	+	Modern languages provide developers simple ways to define most popular constructions, such as short constructors, short functions, omitting mindless keywords and etc.
	+
	+	This RFC make PHP a step closer to a modern PHP look:
	+
	+
	+	<PHP>
	+	<?php
	+
	+	class MyService(private AnotherService $service): AbstractService(prefix: 'my') {
	+	fn getApiVersion() => 1;
	+
	+	fn doProxy() {
	+	return $this->service->main();
	+	}
	+	}
	+
	+	?>
	+	</PHP>
	+
	+	Instead, classic syntax is still available and much verbose:
	+
	+	<PHP>
	+	<?php
	+
	+	class MyService extends AbstractService {
	+	function __construct(private AnotherService $service) {
	+	parent::__construct(prefix: 'my');
	+	}
	+
	+	function getApiVersion() {
	+	return 1;
	+	}
	+
	+	function doProxy() {
	+	return $this->service->main();
	+	}
	+	}
	+
	+	?>
	+	</PHP>
	+
	+	This examples uses short constructor RFC syntax, single expression function syntax and have function -> fn alias
	+
	+
	+	===== Question / Answer =====
	+
	+	==== Should be "function" deprecated? ====
	+
	+	Yes, it should, but with no deprecation warning. Modern codebase will use short syntax (on demand), old projects/libraries won't be re-writed, so classic "functions" should live longer.
	+
	+	==== Will single function declaration be affected as well? ====
	+
	+	Yes, in another RFC.
	+
	+
	+	==== Can I use both <php>fn</php> and <php>function</php> keywords in the same class? ====
	+
	+	Yes, as you wish:
	+
	+	<PHP>
	+	<?php
	+
	+	class A {
	+	fn get() {...}
	+	function set($value) {...}
	+	}
	+	</PHP>
	+
	+	As it's fully-alised it can be replaced vise-versa. The reason to use it so is up to you.
	+
	+
	+	===== Voting Choices =====
	+	Pick a title that reflects the concrete choice people will vote on.
	+
	+	Please consult [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting\|the php/policies repository]] for the current voting guidelines.
	+
	+	<doodle title="Implement $feature as outlined in the RFC?" voteType="single" closed="true" closeon="2025-01-01T15:30:00Z">
	+	* Yes
	+	* No
	+	</doodle>
	+
	+	===== Patches and Tests =====
	+	Links to proof of concept PR.
	+
	+	If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
	+
	+	===== Implementation =====
	+	After the RFC is implemented, this section should contain:
	+	- the version(s) it was merged into
	+	- a link to the git commit(s)
	+	- a link to the PHP manual entry for the feature
	+
	+	===== References =====
	+	Links to external references, discussions, or RFCs.
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.
	+
	+	===== Changelog =====
	+	If there are major changes to the initial proposal, please include a short summary with a date or a link to the mailing list announcement here, as not everyone has access to the wikis' version history.

function_autoloading_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/19 03:56	current
Line 1:	Line 1:
	+	====== PHP RFC: Function Autoloading ======
	+
	+	* Version: 1.0
	+	* Date: 2020-07-01
	+	* Author: Danack, based on work Anthony Ferrara
	+	* Status: Draft
	+	* First Published at: https://wiki.php.net/rfc/function_autoloading_v2
	+
	+	===== Introduction =====
	+
	+	This RFC proposes a new unified autoloading mechanism to allow autoloading of class types (which includes classes, interfaces and traits) and functions. Currently only class type autoloading is possible in PHP.
	+
	+	===== Example =====
	+
	+	This example shows a separate autoloader being registered for classes,
	+
	+	<code php>
	+	<?php
	+
	+	function classTypeAutoloader($name, $type)
	+	{
	+	if ($type !== AUTOLOAD_CLASS) {
	+	return;
	+	}
	+	if ($name !== 'foo') {
	+	return;
	+	}
	+
	+	// Being able to define classes inside a function
	+	// already exists in PHP and is convenient for an example
	+	class foo
	+	{
	+	public function __construct()
	+	{
	+	echo "class was created";
	+	}
	+	}
	+	}
	+
	+	function functionAutoloader($name, $type)
	+	{
	+	if ($type !== AUTOLOAD_FUNCTION) {
	+	return;
	+	}
	+	if ($name !== 'foo') {
	+	return;
	+	}
	+	function foo() {
	+	echo "foo was called";
	+	}
	+	}
	+
	+
	+	autoload_register('classTypeAutoloader', AUTOLOAD_CLASS);
	+
	+	autoload_register('functionAutoloader', AUTOLOAD_FUNCTION);
	+
	+	// As is currently possible, trigger class autoload
	+	new Foo();
	+	//output: class was created
	+
	+	// The triggers the capability to autoload a function
	+	foo();
	+	// output: function was autoloaded and called
	+
	+	</code>
	+
	+	===== Implementation details =====
	+
	+	==== Constants ====
	+
	+	This proposal registers the following constants:
	+
	+	* AUTOLOAD_CLASS => 1
	+	* AUTOLOAD_FUNCTION => 2
	+
	+
	+	The `AUTOLOAD_CLASS` is used for registering autoloaders for all the different types, which will be classes, interfaces and traits.
	+
	+	The `AUTOLOAD_FUNCTION` is used for registering autoloading for functions.
	+
	+
	+	==== Userland Functions ====
	+
	+	This proposal adds the following functions:
	+
	+	=== bool autoload_register(callable $callback, int $type, bool $prepend) ===
	+
	+
	+	=== bool autoload_unregister(callable $callback, int $type) ===
	+
	+	This function behaves similar to the current //spl_autoload_unregister// function, and unregisters a callback that was previously registered. Note that if you registered the same callback for multiple types, this will unregister all of them unless the //$type// argument is specified.
	+
	+	=== array autoload_list(int $type) ===
	+
	+	This function will return a list of all registered autoloaders for a specific type.
	+
	+	=== function_exists() ===
	+
	+	A new optional boolean argument is added to `function_exists()` to match the behavior of `class_exists()` when it comes to autoloading functions.
	+
	+	==== Behavior ====
	+
	+	Registering autoloaders with the new API will allow callbacks to be fired on class and function missing errors.
	+
	+	==== Single Type Behavior ====
	+
	+	By passing a single constant to the register function, the callback will only be called for types that match (the `$type` parameter is still set, but will never vary).
	+
	+	<file php single_type.php>
	+	<?php
	+	autoload_register(function($name, $type) {
	+	var_dump($name, $type);
	+	eval("function $name(){}");
	+	// We don't need a switch, since we only register for functions.
	+	}, AUTOLOAD_FUNCTION);
	+	foo(); // string(3) "foo" int(2)
	+	new foo(); // FATAL_ERROR as no autoloader is registered
	+	?>
	+	</file>
	+
	+	==== Multiple Type Behavior ====
	+
	+	By passing a bitwise-or'd constant to the register function, the callback will only be called for types that match).
	+
	+	<file php multiple_type.php>
	+	<?php
	+	autoload_register(function($name, $type) {
	+	var_dump($name, $type);
	+	switch ($type) {
	+	case AUTOLOAD_FUNCTION:
	+	eval("function $name(){}");
	+	break;
	+	case AUTOLOAD_CLASS:
	+	$code = <<< CODE
	+	class $name
	+	{
	+	public function __construct()
	+	{
	+	echo "class $name was created";
	+	}
	+	}
	+	CODE;
	+	eval($code);
	+	break;
	+	}
	+	}, AUTOLOAD_FUNCTION \| AUTOLOAD_CLASS);
	+	foo(); // string(3) "foo" int(2)
	+	new foo();
	+	?>
	+	</file>
	+
	+
	+	==== Userland Backwards Compatibility ====
	+
	+	=== SPL ===
	+
	+	This RFC proposes to strip the current //spl_autoload_register// functionality, and make //spl_autoload_*// simple proxies for registering core autoloaders. They will function exactly as they do now, but under the hood they will be using the new interface.
	+
	+	This means that calls to //spl_autoload_functions()// will include any autoloader (which indicates support for //AUTOLOAD_CLASS //) registered through //autoload_register()//. However, all autoloaders registered via //spl_autoload_register// will set the //pass_type// flag to //0//, meaning that only a single argument will be passed to the callback. This is for compatiblity.
	+
	+
	+	==== C API Backwards Compatibility ====
	+
	+	=== SPL ===
	+
	+	The autoload related SPL globals have been removed, due to the implementation being centralized.
	+
	+	==== Backward Incompatible Changes ====
	+
	+	=== Userland ===
	+
	+	There should be no user-land BC changes.
	+
	+	==== PECL ====
	+
	+	=== EG(autoload_func) ===
	+
	+	PECL extensions which rely on the //EG(autoload_func)// global variable will break (due to refactor).
	+
	+	A quick scan of LXR shows that only the [optimizer](http://lxr.php.net/xref/PECL/optimizer/optimize.c#4660) extension would change.
	+
	+	=== autoload_func_info ===
	+
	+	PECL extensions which reply on the SPL type //autoload_func_info// will break (due to refactor).
	+
	+	A quick scan of LXR shows that no extensions use this.
	+
	+	=== SPL_G(autoload_functions) ===
	+
	+	PECL extensions which rely on the SPL globals will break (due to refactor).
	+
	+	A quick scan of LXR shows that no extensions use this.
	+
	+	==== Proposed PHP Version(s) ====
	+
	+	PHP 8.0
	+
	+	==== SAPIs Impacted ====
	+
	+	None.
	+
	+	==== Impact to Existing Extensions ====
	+
	+	See Backward Incompatible Changes
	+
	+	==== php.ini Defaults ====
	+
	+	None.
	+
	+	==== Open Issues ====
	+
	+	None yet.
	+
	+
	+	==== Future Scope ====
	+
	+	A previous version of this RFC included support for autoloading constants and streams. These have been excluded from this RFC for the following reasons.
	+
	+	=== Constant autoloading ===
	+
	+	Although it would be possible to add constant autoloading, the position of this RFC is that being unable to directly reference [[https://github.com/Danack/RfcCodex/blob/master/referencing_functions.md\|functions by name]] is a more important problem to address.
	+
	+
	+	If we added constant autoloading now, that would have a very high chance of limiting the choices surrounding being able to reference functions. Because of that, this RFC does not include constant autoloading.
	+
	+	=== Stream autoloading ===
	+
	+	Stream autoloading is excluded from this RFC to reduce the size of the RFC. It would be possible to add it in a later version.
	+
	+
	+	=== Other types ===
	+
	+	At some point PHP may support types other than classes as parameter, return or property types. For example perhaps enums:
	+
	+	<code php>
	+	enum Compass {
	+	North, South, East, West
	+	}
	+
	+	function foo(Compass $direction) { ... }
	+
	+	foo(Compass::East);
	+
	+	</code>
	+
	+	Or typed callables:
	+	<code php>
	+	type logger = callable(string $message): void;
	+
	+	// Use that type
	+	function uses_logger(logger $fn) {...}
	+
	+	</code>
	+
	+	It should be possible to add to autoloading.
	+
	+	As PHP cannot determine what type a parameter, return or property type will be before it is loaded, the loading of those types will need to go through the same mechanism that is used for class autoloading.
	+
	+	At that point it would make sense to either rename `AUTOLOAD_CLASS` to be `AUTOLOAD_TYPE` or more likely, add a new constant with the same value, leaving `AUTOLOAD_CLASS` as legacy.
	+
	+
	+	<code php>
	+	autoload_register('callableTypeAutoloader', AUTOLOAD_TYPE);
	+
	+	function callableTypeAutoloader($name, $type)
	+	{
	+	if ($type !== AUTOLOAD_CLASS) {
	+	return;
	+	}
	+	if ($name !== 'logger') {
	+	return;
	+	}
	+
	+	type logger = callable(string $message): void;
	+	}
	+
	+	</code>
	+
	+
	+	==== Patches and Tests ====
	+
	+	A patch will be created before voting.
	+
	+	==== Vote ====
	+
	+	Accept the RFC yes/no.
	+
	+	==== References ====
	+
	+	* Importing namespaces: http://php.net/manual/en/language.namespaces.importing.php
	+	* SPL Autoloading: http://php.net/manual/en/language.oop5.autoload.php
	+	* Previous RFC for function autoloading: https://wiki.php.net/rfc/function_autoloading
	+	* Previous pull-request: https://github.com/ircmaxell/php-src/tree/function-autoloading-7

function_autoloading

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/09/03 05:06		current
Line 32:		Line 32:
	=== bool php\autoload_register(callable $callback, int $type, bool $prepend = false) ===		=== bool php\autoload_register(callable $callback, int $type, bool $prepend = false) ===

-	This function behaves similar to the current //spl_autoload_register// function. You must call this function individually for the specific autoloader that you want to hook into.	+	This function behaves similar to the current //spl_autoload_register// function. You can pass in a bitmask of types to register for this autoloader.

	=== bool php\autoload_unregister(callable $callback, int $type = 0) ===		=== bool php\autoload_unregister(callable $callback, int $type = 0) ===

function_autoloading2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/12/11 23:36		current
Line 6:		Line 6:
	* Author: Igor Wiedler <igor@wiedler.ch>		* Author: Igor Wiedler <igor@wiedler.ch>
	* Status: In Draft		* Status: In Draft
-	* First Published at: http://wiki.php.net/rfc/function_autoloading2 (forked from [[rfc:use_function\|RFC: Use Function]])	+	* First Published at: http://wiki.php.net/rfc/function_autoloading2 (forked from [[rfc:function_autoloading\|RFC: Function Autoloading]])

	===== Introduction =====		===== Introduction =====
Line 366:		Line 366:
	===== Patches and Tests =====		===== Patches and Tests =====

-	There is a proof-of-concept patch against PHP-5.6 (currently master) [[https://github.com/igorw/php-src/compare/function-autoloading\|Github Branch]]. Note that this includes the accepted but not merged implementation of [[rfc:use_function2\|RFC: Use Function]].	+	There is a proof-of-concept patch against PHP-5.6 [[https://github.com/igorw/php-src/compare/function-autoloading\|Github Branch]].

	This patch is not production ready, but serves as a demonstration of the functionality.		This patch is not production ready, but serves as a demonstration of the functionality.

function_autoloading4

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/09/04 19:07		current
Line 4:		Line 4:
	* Date: 2024-08-15		* Date: 2024-08-15
	* Author: Robert Landers, <landers.robert@gmail.com>		* Author: Robert Landers, <landers.robert@gmail.com>
-	* Status: Under Discussion (or Accepted or Declined)	+	* Status: Discarded (or Accepted or Declined)
	* First Published at: http://wiki.php.net/rfc/function_autoloading4		* First Published at: http://wiki.php.net/rfc/function_autoloading4

function_referencing

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/08/18 16:43		current
Line 1:		Line 1:
	====== PHP RFC: Function Referencing as Closures ======		====== PHP RFC: Function Referencing as Closures ======
	* Version: 0.1		* Version: 0.1
-	* Date: 2014-08-03, latest 2014-08-18	+	* Date: 2014-08-03, latest 2014-08-18, withdrawn 2014-11-03
	* Author: Andrea Faulds, ajf@ajf.me		* Author: Andrea Faulds, ajf@ajf.me
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/function_referencing		* First Published at: http://wiki.php.net/rfc/function_referencing

function-composition

Anonymous (anonymous@undisclosed.example.com) — 2025-10-25T16:08:48+00:00

2025/10/25 16:00		current
Line 73:		Line 73:
	$new->callables[] = $left;		$new->callables[] = $left;
	$new->callables[] = $right;		$new->callables[] = $right;
-	retur $new;	+	return $new;
	}		}

functional-elements

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/03/17 09:38		current
Line 57:		Line 57:
	=== UC-2: Iterating over an aggregation of objects and keeping the results ===		=== UC-2: Iterating over an aggregation of objects and keeping the results ===
	<code php>		<code php>
-	$result = new CallIterator($list, 'method'));	+	$result = iterate(new CallIterator($list, 'method'), true);
	</code>		</code>

functional-interfaces

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/06/02 05:33		current
Line 346:		Line 346:
	===== Vote =====		===== Vote =====

-	Voting started on May 15th, ends May 29th 2016.	+	Voting started on May 15th, ended May 29th 2016.

-	<doodle title="Accept functional interfaces? (2/3+1 majority required)" auth="krakjoe" voteType="single" closed="false">	+	<doodle title="Accept functional interfaces? (2/3+1 majority required)" auth="krakjoe" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

functionarraydereferencing

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 5:		Line 5:
	* Date: June 07, 2010 (re-opened)		* Date: June 07, 2010 (re-opened)
	* Author: Philip Olson <philip@php.net>, Felipe Pena <felipe@php.net>		* Author: Philip Olson <philip@php.net>, Felipe Pena <felipe@php.net>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.4
	===== Introduction =====		===== Introduction =====

functiongetentropy

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2008-11-29		* Date: 2008-11-29
	* Author: Paul Reinheimer <preinheimer@php.net>		* Author: Paul Reinheimer <preinheimer@php.net>
-	* Status: in the works	+	* Status: Declined


Line 25:		Line 25:
	</code>		</code>

		+	===== Changelog =====
		+	Declined, as having http://php.net/openssl_random_pseudo_bytes makes this RFC obsolete.

gc_fn_pointer

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/04/03 09:03		current
Line 4:		Line 4:
	* Date: 2015-01-07		* Date: 2015-01-07
	* Author: Benjamin Eberlei (kontakt@beberlei.de), Adam Harvey (aharvey@php.net)		* Author: Benjamin Eberlei (kontakt@beberlei.de), Adam Harvey (aharvey@php.net)
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)

	===== Introduction =====		===== Introduction =====

gd_image_export_import_pixels

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/01/23 14:12		current
Line 137:		Line 137:

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====
-	The vote will require 2/3 majority with a vote on a per-function basis.	+	The vote will require 2/3 majority.

	===== Patches and Tests =====		===== Patches and Tests =====

generator-delegation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/30 04:34		current
Line 4:		Line 4:
	* Author: Daniel Lowrey <rdlowrey@php.net>		* Author: Daniel Lowrey <rdlowrey@php.net>
	* Contributors: Bob Weinand <bwoebi@php.net>		* Contributors: Bob Weinand <bwoebi@php.net>
-	* Status: Accepted	+	* Status: Implemented in 7.0
	* First Published at: http://wiki.php.net/rfc/generator-delegation		* First Published at: http://wiki.php.net/rfc/generator-delegation

generator-return-expressions

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/03/17 14:48		current
Line 4:		Line 4:
	* Author: Daniel Lowrey <rdlowrey@php.net>		* Author: Daniel Lowrey <rdlowrey@php.net>
	* Contributors: Nikita Popov <nikic@php.net>		* Contributors: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/generator-return-expressions		* First Published at: http://wiki.php.net/rfc/generator-return-expressions

generators

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/12/23 23:44		current
Line 459:		Line 459:
	==== Cloning a generator ====		==== Cloning a generator ====

-	Generators can be cloned, thus leaving two independent ''Generator'' objects with the same state. This behavior can for example be	+	Generators cannot be cloned.
-	used to create a ''rewindable'' function, which would make the passed generator rewindable:	+

-	<code php>	+	Support for cloning was included in the initial version, but removed in PHP 5.5 Beta 3 due to implementational difficulties, unclear semantics and no particularly convincing use cases.
-	class RewindableGenerator implements Iterator {	+
-	protected $original;	+
-	protected $current;	+
-		+
-	public function __construct(Generator $generator) {	+
-	$this->original = $generator;	+
-	$this->current = null;	+
-	}	+
-		+
-	public function rewind() {	+
-	if ($this->current) { $this->current->close(); }	+
-	$this->current = clone $this->original;	+
-	$this->current->rewind();	+
-	}	+
-		+
-	public function valid() {	+
-	if (!$this->current) { $this->current = clone $this->original; }	+
-	return $this->current->valid();	+
-	}	+
-		+
-	public function current() {	+
-	if (!$this->current) { $this->current = clone $this->original; }	+
-	return $this->current->current();	+
-	}	+
-		+
-	public function key() {	+
-	if (!$this->current) { $this->current = clone $this->original; }	+
-	return $this->current->key();	+
-	}	+
-		+
-	public function next() {	+
-	if (!$this->current) { $this->current = clone $this->original; }	+
-	$this->current->next();	+
-	}	+
-		+
-	public function send($value) {	+
-	if (!$this->current) { $this->current = clone $this->original; }	+
-	return $this->current->send($value);	+
-	}	+
-		+
-	public function close() {	+
-	$this->original->close();	+
-	if ($this->current) {	+
-	$this->current->close();	+
-	}	+
-	}	+
-	}	+
-		+
-	function rewindable(Generator $generator) {	+
-	return new RewindableGenerator($generator);	+
-	}	+
-	</code>	+
-		+
-	It can be then used as follows:	+
-		+
-	<code php>	+
-	function xrange($start, $end, $step = 1) {	+
-	for ($i = $start; $i <= $end; $i += $step) {	+
-	yield $i;	+
-	}	+
-	}	+
-		+
-	$range = rewindable(xrange(0, 5));	+
-	foreach ($range as $i) {	+
-	echo $i, "\n";	+
-	}	+
-	foreach ($range as $i) {	+
-	echo $i, "\n";	+
-	}	+
-	</code>	+
-		+
-	This will correctly output the 0..5 range twice.	+

	==== Closing a generator ====		==== Closing a generator ====

generic-arrays

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/12/17 13:22		current
Line 44:		Line 44:
	Typed arrays are type-checked at run-time, when an array literal is created, and when an element is appended or replaced into a typed array. If a type-check fails, a ''%%TypeError%%'' will be thrown.		Typed arrays are type-checked at run-time, when an array literal is created, and when an element is appended or replaced into a typed array. If a type-check fails, a ''%%TypeError%%'' will be thrown.

-	The feature should use familiar generic syntax like ''%%array<User>%%'' or ''%%array<string,int>%%'' etc. for type-hints, where ''%%array<V>%%'' and ''%%array<K,V>%%'' are separate pseudo-types specifying either the element value type, or the key and value types. (When no key type is specified, the element identity behavior should be identical to that of regular, untyped arrays.)	+	The feature should use familiar generic syntax like ''%%array<User>%%'' or ''%%array<string,int>%%'' etc. for type-hints, where ''%%array<V>%%'' and ''%%array<K,V>%%'' are separate pseudo-types specifying either the element value type, or the key and value types. When no key type is specified, the element identity behavior should be identical to that of regular, untyped arrays.

	Typed array literals will be written as e.g. ''%%$users = array<User>(new User("Alice"), new User("Bob"))%%''. (Note that this should not interfere with function calling syntax, since the ''%%array()%%'' literal is a language construct, and not a function.)		Typed array literals will be written as e.g. ''%%$users = array<User>(new User("Alice"), new User("Bob"))%%''. (Note that this should not interfere with function calling syntax, since the ''%%array()%%'' literal is a language construct, and not a function.)
		+
		+	(Note that the 2014 "Array Of" RFC suggested a simpler syntax for type hints, namely ''%%User[]%%'' - for the sake of consistency, and since this syntax is unable to specify the key type, this RFC proposes consistent use of the ''%%array%%'' keyword for type hints and literal values.)

	==== Behaviors ====		==== Behaviors ====

generics

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 6:		Line 6:
	* Status: Draft		* Status: Draft
	* First Published at: http://wiki.php.net/rfc/generics		* First Published at: http://wiki.php.net/rfc/generics
		+
		+	NOTE: a newer version of this RFC may be under development [[https://github.com/mindplay-dk/php-generics-rfc\|on GitHub]].

	===== Introduction =====		===== Introduction =====

get_class_disallow_null_parameter

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2016-08-12		* Date: 2016-08-12
	* Author: Danack		* Author: Danack
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.2)
	* First Published at: https://wiki.php.net/rfc/get_class_disallow_null_parameter		* First Published at: https://wiki.php.net/rfc/get_class_disallow_null_parameter

get_debug_type

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/04/29 19:42		current
Line 3:		Line 3:
	* Date: 2020-02-15		* Date: 2020-02-15
	* Author: Mark Randall, marandall@php.net		* Author: Mark Randall, marandall@php.net
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/get_debug_type		* First Published at: https://wiki.php.net/rfc/get_debug_type

get_declared_enums

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/08/20 08:02		current
Line 3:		Line 3:
	* Date: 2024-08-19		* Date: 2024-08-19
	* Author: Juliette Reinders Folmer (<php.net_nospam@adviesenzo.nl>), Ayesh Karunaratne (<ayesh@php.watch>)		* Author: Juliette Reinders Folmer (<php.net_nospam@adviesenzo.nl>), Ayesh Karunaratne (<ayesh@php.watch>)
-	* Status: Draft	+	* Status: Under Discussion
	* Implementation: https://github.com/php/php-src/pull/15443		* Implementation: https://github.com/php/php-src/pull/15443
	* First Published at: http://wiki.php.net/rfc/get_declared_enums		* First Published at: http://wiki.php.net/rfc/get_declared_enums

get-error-exception-handler

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2025/03/28 17:41		current
Line 4:		Line 4:
	* Author: Arnaud Le Blanc, arnaud.lb@gmail.com		* Author: Arnaud Le Blanc, arnaud.lb@gmail.com
	* Status: Implemented		* Status: Implemented
		+	* Target Version: PHP 8.5
	* First Published at: http://wiki.php.net/rfc/get-error-exception-handler		* First Published at: http://wiki.php.net/rfc/get-error-exception-handler

get-random

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: April 11, 2010		* Date: April 11, 2010
	* Author: Philip Olson <philip@php.net>		* Author: Philip Olson <philip@php.net>
-	* Status: In Draft	+	* Status: Draft (Inactive)
	* First Published at: http://wiki.php.net/rfc/get-random		* First Published at: http://wiki.php.net/rfc/get-random

github_issues

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/11/20 10:32		current
Line 2:		Line 2:
	* Date: 2021-11-01		* Date: 2021-11-01
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Voting	+	* Status: Accepted

	===== Introduction =====		===== Introduction =====
Line 241:		Line 241:
	Voting started 2021-11-20 and ends on 2021-12-04.		Voting started 2021-11-20 and ends on 2021-12-04.

-	<doodle title="Migrate from bugs.php.net to GitHub issues as proposed?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Migrate from bugs.php.net to GitHub issues as proposed?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

github-pr

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/11/01 18:26		current
Line 3:		Line 3:
	* Date: 2014-10-30		* Date: 2014-10-30
	* Author: John Bafford, john@bafford.com		* Author: John Bafford, john@bafford.com
-	* Status: Draft	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/github-pr		* First Published at: http://wiki.php.net/rfc/github-pr

glob_streamwrapper_support

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/10/02 21:22		current
Line 1:		Line 1:
	====== PHP RFC: StreamWrapper Support for glob() ======		====== PHP RFC: StreamWrapper Support for glob() ======
		+
	* Version: 1.0		* Version: 1.0
	* Date: 2022-08-15		* Date: 2022-08-15
Line 5:		Line 6:
	* Status: Under Discussion		* Status: Under Discussion
	* First Published at: https://wiki.php.net/rfc/glob_streamwrapper_support		* First Published at: https://wiki.php.net/rfc/glob_streamwrapper_support
		+
		+	Status: Aborted
		+
		+	Comment: This RFC has been aborted as no convenient solution or workaround was found for Alpine platform. / Timmy

	===== Introduction =====		===== Introduction =====

global_function_parser_directive

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/08/04 11:30		current
Line 4:		Line 4:
	* Date: 2024-08-04		* Date: 2024-08-04
	* Author: Nick Lockheart, lists@ageofdream.com		* Author: Nick Lockheart, lists@ageofdream.com
-	* Status: Draft	+	* Status: Under Discussion
	* First Published at: https://wiki.php.net/rfc/global_function_parser_directive		* First Published at: https://wiki.php.net/rfc/global_function_parser_directive

global_login

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/06/25 15:54		current
Line 3:		Line 3:
	* Date: 2022-05-23		* Date: 2022-05-23
	* Author: Aaron Junker, [[mailto:aaronjunker@php.net\|aaronjunker@php.net]]		* Author: Aaron Junker, [[mailto:aaronjunker@php.net\|aaronjunker@php.net]]
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/global_login		* First Published at: http://wiki.php.net/rfc/global_login
	* Possible developer: Aaron Junker, [[mailto:aaronjunker@php.net\|aaronjunker@php.net]]		* Possible developer: Aaron Junker, [[mailto:aaronjunker@php.net\|aaronjunker@php.net]]

gmp_number

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/12/30 23:57		current
Line 23:		Line 23:

	==== Add GMP float support to GMP module ====		==== Add GMP float support to GMP module ====
-	Add GMP float support to GMP module.	+	<del>Add GMP float support to GMP module.

	* Add all GMP float API wrapper to module.		* Add all GMP float API wrapper to module.
	* GMP float API wrapper supports PHP int/float and GMP int/float. Conversion is done automatically.		* GMP float API wrapper supports PHP int/float and GMP int/float. Conversion is done automatically.
-	* Default precision: 256 (?)	+	* Default precision: 256 (?)</del>

-	==== Add GMP float support to Zend OP =====	+	Extracted out to a separate RFC: [[rfc:gmp-floating-point\|GMP Floating Point Support]]
-	Add GMP float support to operators.	+
-		+
-	* Arithmetic with GMP float and any number(PHP int/float, GMP int) is promoted to GMP float.	+

	==== Add math function compatibility =====		==== Add math function compatibility =====
Line 128:		Line 125:

	PHP 5.6 or later		PHP 5.6 or later
-
-	===== Impact to Existing Extensions =====
-
-	GMP module will have GMP float support.
-
-	===== php.ini Defaults =====
-
-	If there are any php.ini settings then list:
-
-	* hardcoded default values
-	* gmp_precision=256
-
-	* php.ini-development values
-	* gmp_precision=256
-
-	* php.ini-production values
-	* gmp_precision=256

	===== Open Issues =====		===== Open Issues =====
Line 153:		Line 133:
	* Implement autoboxing like feature		* Implement autoboxing like feature
	* How GMP number should behave (Like PHP or Ruby?)		* How GMP number should behave (Like PHP or Ruby?)
-	* GMP float support API design
-	* gmp_precision default value

	===== Future Scope =====		===== Future Scope =====
Line 183:		Line 161:

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

gmp-final

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/07/27 10:55		current
Line 6:		Line 6:
	* Status: Pending Implementation		* Status: Pending Implementation
	* Target Version: PHP 8.4		* Target Version: PHP 8.4
-	* Implementation: TBD	+	* Implementation: https://github.com/php/php-src/pull/15121
	* First Published at: https://wiki.php.net/rfc/gmp-final		* First Published at: https://wiki.php.net/rfc/gmp-final

gmp-floating-point

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/01/05 22:38		current
Line 67:		Line 67:
	===== History =====		===== History =====

-	Version 1.0: 2014-01-04 Initial Draft	+	* Version 1.0: 2014-01-04 Initial Draft
-	Version 1.1 2014-01-05 Added proposal #2	+	* Version 1.1: 2014-01-05 Added proposal #2

	===== Implementation =====		===== Implementation =====

google_groups

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/01/11 12:25		current
Line 10:		Line 10:

	===== Proposal =====		===== Proposal =====
-		+	Ditch the current mailing list infrastructure including the following pieces on pair1.php.net
-	Ditch the current mailing list infrastructure including the following pieces on pair1.php.net:	+
	* ecelerity		* ecelerity
	* ezmlm		* ezmlm
-	* colubus serving news://news.php.net	+	* colubus serving %%news://news.php.net%%
-	* http://news.php.net website itself	+	* the news.php.net website
		+	* the news subdomain
		+	* the web/news.git repo
		+	* and eventually the pair1.php.net box itself
	and move the current mailing lists including the archives to Google Groups.		and move the current mailing lists including the archives to Google Groups.

-	===== Proposal =====
	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====

grapheme_add_locale_for_case_insensitive

Anonymous (anonymous@undisclosed.example.com) — 2025-09-08T14:08:33+00:00

2025/08/09 01:16		current
Line 3:		Line 3:
	* Date: 2025-06-07		* Date: 2025-06-07
	* Author: Yuya Hamada, youkidearitai@gmail.com		* Author: Yuya Hamada, youkidearitai@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive		* First Published at: https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive

grapheme_levenshtein

Anonymous (anonymous@undisclosed.example.com) — 2025-04-28T10:18:58+00:00

2025/04/16 00:37		current
Line 3:		Line 3:
	* Date: 2024-10-14		* Date: 2024-10-14
	* Author: Yuya Hamada, youkidearitai@gmail.com		* Author: Yuya Hamada, youkidearitai@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/grapheme_levenshtein		* First Published at: http://wiki.php.net/rfc/grapheme_levenshtein

grapheme_limit_codepoints

Anonymous (anonymous@undisclosed.example.com) — 2026-02-28T01:19:13+00:00

2026/02/27 15:48		current
Line 1:		Line 1:
-	====== PHP RFC: Your Title Here ======	+	====== PHP RFC: grapheme_limit_codepoints: Limit codepoint for grapheme cluster function ======
	* Version: 0.9		* Version: 0.9
	* Date: 2026-02-28		* Date: 2026-02-28

grapheme_str_split

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/04/10 19:21		current
Line 4:		Line 4:
	* Author: Yuya Hamada, youkidearitai@gmail.com		* Author: Yuya Hamada, youkidearitai@gmail.com
	* Status: Implemented		* Status: Implemented
		+	* Target Version: PHP 8.4
		+	* Implementation: https://github.com/php/php-src/pull/13580
	* First Published at: http://wiki.php.net/rfc/grapheme_str_split		* First Published at: http://wiki.php.net/rfc/grapheme_str_split

grapheme_strrev

Anonymous (anonymous@undisclosed.example.com) — 2026-03-16T22:54:49+00:00

2026/03/04 00:48		current
Line 3:		Line 3:
	* Date: 2026-01-14		* Date: 2026-01-14
	* Author: Yuya Hamada <youkidearitai@gmail.com>		* Author: Yuya Hamada <youkidearitai@gmail.com>
-	* Status: Implemented	+	* Status: Implemented in PHP 8.6
	* Implementation: https://github.com/php/php-src/pull/20949		* Implementation: https://github.com/php/php-src/pull/20949

grisu3-strtod

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/07/15 16:41		current
Line 3:		Line 3:
	* Date: 2011-07-15		* Date: 2011-07-15
	* Author: David Soria Parra <dsp at php dot net>		* Author: David Soria Parra <dsp at php dot net>
-	* Status: Under Discussion	+	* Status: Inactive
	* Proposed for: PHP 5.4		* Proposed for: PHP 5.4

group_use_declarations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2015/02/25 20:41		current
Line 3:		Line 3:
	* Date: 2015-01-28		* Date: 2015-01-28
	* Author: Márcio Almada, marcio.web2@gmail.com		* Author: Márcio Almada, marcio.web2@gmail.com
-	* Status: Voting (previously Under Discussion)	+	* Status: Implemented (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/group_use_declarations		* First Published at: http://wiki.php.net/rfc/group_use_declarations
	* Patch: https://github.com/php/php-src/pull/1005		* Patch: https://github.com/php/php-src/pull/1005

guard_statement

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/05/16 09:12		current
Line 3:		Line 3:
	* Date: 2020-05-16		* Date: 2020-05-16
	* Author: Pavel Patapau, [[algerd.blr@gmail.com]]		* Author: Pavel Patapau, [[algerd.blr@gmail.com]]
-	* Status: Under Discussion	+	* Status: Withdrawn
	* Target Version: 8.0		* Target Version: 8.0
	* Implementation: https://github.com/php/php-src/pull/5578		* Implementation: https://github.com/php/php-src/pull/5578

hash_pbkdf2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/07/10 14:09		current
Line 3:		Line 3:
	* Date: 2012-06-13		* Date: 2012-06-13
	* Author: Anthony Ferrara <ircmaxell@php.net>		* Author: Anthony Ferrara <ircmaxell@php.net>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/hash_pbkdf2		* First Published at: http://wiki.php.net/rfc/hash_pbkdf2

hash-context.as-resource

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/01/18 16:45		current
Line 3:		Line 3:
	* Date: 2016-12-26		* Date: 2016-12-26
	* Author: Sara Golemon <pollita@php.net>, with initial implementation from Rouven Weßling <me@rouvenwessling.de>		* Author: Sara Golemon <pollita@php.net>, with initial implementation from Rouven Weßling <me@rouvenwessling.de>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/hash-context.as-resource		* First Published at: http://wiki.php.net/rfc/hash-context.as-resource

Line 33:		Line 33:
	This primary vote is to determine, overall, if the "hash context" resource used by hash_init/hash_update/hash_final should be changed to an object.		This primary vote is to determine, overall, if the "hash context" resource used by hash_init/hash_update/hash_final should be changed to an object.

-	<doodle title="Change HashContext to an object" auth="sgolemon" voteType="single" closed="false">	+	<doodle title="Change HashContext to an object" auth="sgolemon" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 43:		Line 43:
	* "Reentrant": Apply both diffs in [[https://github.com/php/php-src/pull/2309\|PR#2309]] which will allow contexts to continue functioning after calling hash_final() by effectively performing: $saved = hash_copy($ctx); $ret = hash_final($ctx); $ctx = $saved;		* "Reentrant": Apply both diffs in [[https://github.com/php/php-src/pull/2309\|PR#2309]] which will allow contexts to continue functioning after calling hash_final() by effectively performing: $saved = hash_copy($ctx); $ret = hash_final($ctx); $ctx = $saved;

-	<doodle title="Merge one or both diffs" auth="sgolemon" voteType="single" closed="false">	+	<doodle title="Merge one or both diffs" auth="sgolemon" voteType="single" closed="true">
	* Frozen		* Frozen
	* Reentrant		* Reentrant

hash-functions-empty-key-warning

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2016/04/21 00:02		current
Line 10:		Line 10:

	===== Proposal =====		===== Proposal =====
-	It's not uncommon to accidentally hash data with a null or empty key. Doing this has security implications that currently happen quietly in the background since [[https://3v4l.org/AF998\|PHP has no issue hashing data with an empty key]]. To bring the security issue to the attention of the user, a warning should be raised if the key is empty.	+	It's not uncommon to accidentally hash data with an empty or [[http://www.cryptofails.com/post/70059595978/myself-using-the-same-key-to-encrypt-everything\|non-string]] key. Doing this [[http://www.hpenterprisesecurity.com/vulncat/en/vulncat/java/key_management_empty_hmac_key.html\|has security implications]] that currently happen quietly in the background since [[https://3v4l.org/AF998\|PHP has no issue hashing data with an empty key]]. To bring the security issue to the attention of the user, a warning should be raised if the key is empty.

	Ideally this would throw a fatal error, but as [[https://twitter.com/ezimuel/status/721006534847832064\|Enrico Zimuel pointed out]], it's not technically an error.		Ideally this would throw a fatal error, but as [[https://twitter.com/ezimuel/status/721006534847832064\|Enrico Zimuel pointed out]], it's not technically an error.

hash.context.oop

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/10/21 19:20		current
Line 20:		Line 20:
	* `update(string $data): this`, mirroring [[https://www.php.net/hash_update\|hash_update()]]		* `update(string $data): this`, mirroring [[https://www.php.net/hash_update\|hash_update()]]
	* `updateFile(string $uri, ?StreamContext $context = null): this`, mirroring [[https://www.php.net/hash_update_file\|hash_update_file()]]		* `updateFile(string $uri, ?StreamContext $context = null): this`, mirroring [[https://www.php.net/hash_update_file\|hash_update_file()]]
-	* `updateStream(\Stream $stream, int $length = -1): this`, mirroring [[https://www.php.net/hash_update_stream\|hash_update_stream()]]	+	* `updateStream(Stream $stream, int $length = -1): this`, mirroring [[https://www.php.net/hash_update_stream\|hash_update_stream()]]
	* `final(bool $raw_output = false): string`, mirroring [[https://www.php.net/hash_final\|hash_final()]]		* `final(bool $raw_output = false): string`, mirroring [[https://www.php.net/hash_final\|hash_final()]]

	Note that the new update methods return the object instance to make using fluent method chaining easier rather that return bool or the number of bytes applied in the update. If they are unable to process the entire requested payload, they will throw an `Error` exception.		Note that the new update methods return the object instance to make using fluent method chaining easier rather that return bool or the number of bytes applied in the update. If they are unable to process the entire requested payload, they will throw an `Error` exception.
		+
		+	The psuedo classnames `Stream` and `StreamContext` here refer to what are currently resources wrapping `php_stream` and `php_stream_context`, respectively.

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

hashkey

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/10/22 17:57		current
Line 1:		Line 1:
-	====== PHP RFC: __toKey magic method ======	+	Merged to rfc/objkey
-	* Version: 0.9	+
-	* Date: 2014-10-22	+
-	* Author: Joe Watkins	+
-	* Status: Draft	+
-	* First Published at: http://wiki.php.net/rfc/hashkey	+
-		+
-	===== Proposal =====	+
-	A new magic toKey method, to resolve the problem of not being able to use Objects as array keys.	+
-		+
-	<code php>	+
-	<?php	+
-	class Foo {	+
-	public function __toKey() {	+
-	return "Foo";	+
-	}	+
-	}	+
-		+
-	$foo = new Foo();	+
-	$test = [	+
-	$foo => true	+
-	];	+
-	</code>	+
-		+
-	Inheritance shall work as any other magic method:	+
-		+
-	<code php>	+
-	<?php	+
-	class Foo {	+
-	public function __toKey() {	+
-	return "Foo";	+
-	}	+
-	}	+
-		+
-	class Bar extends Foo {	+
-	*/ shall use Foo::__toKey unless Bar::__toKey is implemented /*	+
-	}	+
-		+
-	$bar = new Bar();	+
-	$test = [	+
-	$bar => true	+
-	];	+
-	</code>	+
-		+
-	Returning a non-scalar shall fail as it did before:	+
-		+
-	<code php>	+
-	<?php	+
-	class Foo {	+
-	public function __toKey() {	+
-	return [];	+
-	}	+
-	}	+
-		+
-	$foo = new Foo();	+
-	$test = [	+
-	$foo => true	+
-	];	+
-	</code>	+
-		+
-	Shall yield:	+
-		+
-	<code php>	+
-	Warning: Illegal offset type in %s on line %d	+
-	</code>	+
-		+
-	The current behaviour of __toString is unchanged.	+
-		+
-	===== Proposed PHP Version(s) =====	+
-	7	+
-		+
-	===== Open Issues =====	+
-	Make sure there are no open issues when the vote starts!	+
-		+
-	===== Proposed Voting Choices =====	+
-	The language is changed, so requires a 2/3 majority to pass.	+
-		+
-	A straight yes/no vote should be conducted.	+
-		+
-	===== Patches and Tests =====	+
-	http://github.com/krakjoe/php-src/compare/hashkey	+
-		+
-	===== References =====	+
-	Links to external references, discussions or RFCs	+
-		+
-	===== Rejected Features =====	+
-	Keep this updated with features that were discussed on the mail lists.	+

heredoc-scanner-loosening

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 3:		Line 3:
	* Date: 2014-08-29		* Date: 2014-08-29
	* Author: Tjerk Meesters, datibbaw@php.net		* Author: Tjerk Meesters, datibbaw@php.net
-	* Status: Under Discussion	+	* Status: Obsolete
	* First Published at: http://wiki.php.net/rfc/heredoc-scanner-loosening		* First Published at: http://wiki.php.net/rfc/heredoc-scanner-loosening

heredoc-with-double-quotes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 4:		Line 4:
	* Date: 2008-03-22		* Date: 2008-03-22
	* Author: Lars Strojny		* Author: Lars Strojny
-	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Accepted]] (Implemented in PHP 5.3)	+	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Implemented in PHP 5.3]]
	* Votes: (+6/-4)		* Votes: (+6/-4)
	* Pro: [[http://marc.info/?l=php-internals&m=120679140717702&w=2\|Pierre A. Joye]], [[http://marc.info/?l=php-internals&m=120674698503890&w=2\|Felipe Pena]] , [[http://marc.info/?l=php-internals&m=120636366616273&w=2\|Marcus Boerger]], [[http://marc.info/?l=php-internals&m=120671376003536&w=2\|Gwynne Raskind]], Christopher Jones, Lars Strojny		* Pro: [[http://marc.info/?l=php-internals&m=120679140717702&w=2\|Pierre A. Joye]], [[http://marc.info/?l=php-internals&m=120674698503890&w=2\|Felipe Pena]] , [[http://marc.info/?l=php-internals&m=120636366616273&w=2\|Marcus Boerger]], [[http://marc.info/?l=php-internals&m=120671376003536&w=2\|Gwynne Raskind]], Christopher Jones, Lars Strojny

hook_improvements

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/07/31 01:07		current
Line 3:		Line 3:
	* Date: 2024-06-28		* Date: 2024-06-28
	* Author: Ilija Tovilo (tovilo.ilija@gmail.com), Larry Garfield (larry@garfieldtech.com)		* Author: Ilija Tovilo (tovilo.ilija@gmail.com), Larry Garfield (larry@garfieldtech.com)
-	* Status: Approved	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/hook_improvements		* First Published at: http://wiki.php.net/rfc/hook_improvements

horizontalreuse

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/03/09 21:04		current
Line 3:		Line 3:
	* Date: 2008-10-12, last update 2011-01-09		* Date: 2008-10-12, last update 2011-01-09
	* Author: Stefan Marr <php.at.stefan-marr.de>		* Author: Stefan Marr <php.at.stefan-marr.de>
-	* Status: Committed to trunk (traits only)	+	* Status: Implemented in PHP 5.4 (traits only)
	* First Patch: http://www.stefan-marr.de/2009/09/traits-patch-updated-backported-and-available-on-github/		* First Patch: http://www.stefan-marr.de/2009/09/traits-patch-updated-backported-and-available-on-github/
	* First Published at: http://www.stefan-marr.de/artikel/rfc-horizontal-reuse-for-php.html		* First Published at: http://www.stefan-marr.de/artikel/rfc-horizontal-reuse-for-php.html

howto

Anonymous (anonymous@undisclosed.example.com) — 2026-02-20T00:29:50+00:00

2025/11/22 13:50		current
Line 1:		Line 1:
	===== How To Create an RFC =====		===== How To Create an RFC =====

-	Newcomers to PHP core development should read [[https://blogs.oracle.com/opal/the-mysterious-php-rfc-process-and-how-you-can-change-the-web\|The Mysterious PHP RFC Process and How You Can Change the Web]] before starting the RFC process.	+	Newcomers to PHP core development should read [[https://web.archive.org/web/20210621140006/https://blogs.oracle.com/opal/the-mysterious-php-rfc-process-and-how-you-can-change-the-web\|The Mysterious PHP RFC Process and How You Can Change the Web]] before starting the RFC process.

	If you don't have the skills to fully implement your RFC and no-one volunteers to code it, there is little chance your RFC will be successful. To learn about PHP core development see [[internals:references\|References about Maintaining and Extending PHP]].		If you don't have the skills to fully implement your RFC and no-one volunteers to code it, there is little chance your RFC will be successful. To learn about PHP core development see [[internals:references\|References about Maintaining and Extending PHP]].

http-interface

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/10/31 03:19		current
Line 106:		Line 106:
	}		}
	</code>		</code>
		+
		+	===== Implementation =====
		+
		+	It appears the SAPI_API to the incoming HTTP request to PHP is already capable of allowing things such as register callbacks for the header, setting different content_type handlers/readers, etc... However, it is not currently exposed directly to userland.
		+
		+	* http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#122
		+	* http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#49
		+
		+
		+	This can be easily achieved by providing a direct interface to the internal API through a new class that will then be called along with the SAPI API on RINIT stage.
		+

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====
Line 142:		Line 153:

	===== Patches and Tests =====		===== Patches and Tests =====
-
-
-	===== Implementation =====

http-last-response-headers

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/02/14 14:09		current
Line 4:		Line 4:
	* Date: 2024-01-03		* Date: 2024-01-03
	* Author: Gina Peter Banyard <girgias@php.net>		* Author: Gina Peter Banyard <girgias@php.net>
-	* Status: Pending Implementation	+	* Status: Implemented in PHP 8.4: https://github.com/php/php-src/commit/47a199c8b43dbf84e66ff6b63f665541ab4eb1d0
	* Target Version: PHP 8.4		* Target Version: PHP 8.4
	* Implementation: [[https://github.com/php/php-src/pull/12500\|https://github.com/php/php-src/pull/12500]]		* Implementation: [[https://github.com/php/php-src/pull/12500\|https://github.com/php/php-src/pull/12500]]

ifsetor

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/12/31 16:55		current
Line 139:		Line 139:
	- The default value can be omitted in which case NULL will be used.		- The default value can be omitted in which case NULL will be used.

-	http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040901.diff.txt	+	http://php.net/~helly/ze2-ifsetor-20040901.diff.txt

	===== Rejected Features =====		===== Rejected Features =====

image2wbmp

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/06/09 22:37		current
Line 61:		Line 61:
	- Implemented in PHP 7.3 via [[http://git.php.net/?p=php-src.git;a=commit;h=3cbf594dfd0708dc36f1655c50e16fa963e61501]]		- Implemented in PHP 7.3 via [[http://git.php.net/?p=php-src.git;a=commit;h=3cbf594dfd0708dc36f1655c50e16fa963e61501]]
	- [[http://php.net/manual/en/function.image2wbmp.php\|doc]] [[http://svn.php.net/viewvc?view=revision&revision=345112\|fix]]		- [[http://php.net/manual/en/function.image2wbmp.php\|doc]] [[http://svn.php.net/viewvc?view=revision&revision=345112\|fix]]
		+	- [[http://git.php.net/?p=php-src.git;a=commit;h=dfa6c2046a8d7b66c4be52e46888f0fefccbcfd4\|Removed for PHP 8]]

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

imagettf_deprecation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/07/27 01:16		current
Line 3:		Line 3:
	* Date: 2014-07-26		* Date: 2014-07-26
	* Author: Lonny Kapelushnik, lonny@lonnylot.com		* Author: Lonny Kapelushnik, lonny@lonnylot.com
-	* Status: Draft	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/imagettf_deprecation		* First Published at: http://wiki.php.net/rfc/imagettf_deprecation

immutability

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2018/02/20 11:19		current
Line 4:		Line 4:
	* Author: Michal Brzuchalski <michal@brzuchalski.com>		* Author: Michal Brzuchalski <michal@brzuchalski.com>
	* Author: Silvio Marijic <marijic.silvio@gmail.com>		* Author: Silvio Marijic <marijic.silvio@gmail.com>
-	* Status: In Discussion	+	* Status: Obsolete
	* First Published at: [[rfc:immutability\|https://wiki.php.net/rfc/immutability]]		* First Published at: [[rfc:immutability\|https://wiki.php.net/rfc/immutability]]
		+
		+	> This proposal has been superseded by [[rfc:readonly_properties_v2\|Readonly properties 2.0]], which has been implemented in PHP 8.1, and [[rfc:readonly_classes\|Readonly classes]], which has been implemented in PHP 8.2.

	===== Introduction =====		===== Introduction =====

implement_sqlite_openblob_in_pdo

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/11/01 19:37		current
Line 4:		Line 4:
	* Date: 2017-09-19		* Date: 2017-09-19
	* Author: bohwaz		* Author: bohwaz
-	* Status: Rejected	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo		* First Published at: http://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo

implement-strrstr-for-consistency

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/06/20 12:06		current
Line 3:		Line 3:
	* Date: 2019-06-20		* Date: 2019-06-20
	* Author: George Peter Banyard <girgias@php.net>		* Author: George Peter Banyard <girgias@php.net>
-	* Status: Draft	+	* Status: Withdrawn (2019-07-03)
	* First Published at: http://wiki.php.net/rfc/implement-strrstr-for-consistency		* First Published at: http://wiki.php.net/rfc/implement-strrstr-for-consistency

implicit_move_optimisation

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2023/05/13 22:46		current
Line 28:		Line 28:
	The code example shows an array being passed to "my_function", which modifies the array and returns the modified result. However, due to the copy-on-write (CoW) mechanism, the variable "$my_array" is copied within "my_function" because the array's reference count is greater than 1 and it is modified. In this example, the copy is unnecessary because the result always overwrites the original array. The purpose of this RFC is to propose an optimisation for avoiding such unnecessary copies.		The code example shows an array being passed to "my_function", which modifies the array and returns the modified result. However, due to the copy-on-write (CoW) mechanism, the variable "$my_array" is copied within "my_function" because the array's reference count is greater than 1 and it is modified. In this example, the copy is unnecessary because the result always overwrites the original array. The purpose of this RFC is to propose an optimisation for avoiding such unnecessary copies.

-	While this example may not highlight the significance of the copy cost, there are scenarios where it does matter, such as processing large data batches (e.g., ETL-like processes) or having more complex data manipulation functions. The reason for having a separate "main()" function in the example will become clear later in the proposal.	+	While this example may not highlight the significance of the copy cost, there are scenarios where it does matter, such as processing large data batches (e.g., Extract-Transform-Load processes) or having more complex data manipulation functions. The reason for having a separate "main()" function in the example will become clear later in the proposal.

	A similar case where this optimisation is beneficial is for variables which are passed to functions and then never used again the caller.		A similar case where this optimisation is beneficial is for variables which are passed to functions and then never used again the caller.

implicit-float-int-deprecate

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/05/31 14:26		current
Line 3:		Line 3:
	* Date: 2021-02-03		* Date: 2021-02-03
	* Author: George Peter Banyard, <girgias@php.net>		* Author: George Peter Banyard, <girgias@php.net>
-	* Status: Accepted https://externals.io/message/113371	+	* Status: Implemented (https://github.com/php/php-src/commit/b6958bb8476306c2f6ce110782330c41e6a5df3a)
		+	* Discussion: https://externals.io/message/113371
	* First Published at: http://wiki.php.net/rfc/implicit-float-int-deprecate		* First Published at: http://wiki.php.net/rfc/implicit-float-int-deprecate
	* GitHub mirror: https://github.com/Girgias/float-int-warning		* GitHub mirror: https://github.com/Girgias/float-int-warning
Line 115:		Line 116:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+	Implemented in https://github.com/php/php-src/commit/b6958bb8476306c2f6ce110782330c41e6a5df3a
-	- the version(s) it was merged into	+
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+
-	- a link to the language specification section (if any)	+
	===== References =====		===== References =====

	Initial mailing list discussion: <https://externals.io/message/113077> \\		Initial mailing list discussion: <https://externals.io/message/113077> \\
	Revised mailing list discussion: <https://externals.io/message/113371> \\		Revised mailing list discussion: <https://externals.io/message/113371> \\

improve_callbacks_dom_and_xsl

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2024/01/12 23:02		current
Line 6:		Line 6:
	* Implementation: https://github.com/php/php-src/commit/90785dd865aa14005611107d566aa2a664572d8a		* Implementation: https://github.com/php/php-src/commit/90785dd865aa14005611107d566aa2a664572d8a
	* First Published at: https://wiki.php.net/rfc/improve_callbacks_dom_and_xsl		* First Published at: https://wiki.php.net/rfc/improve_callbacks_dom_and_xsl
		+	* Target: PHP 8.4

	===== Introduction =====		===== Introduction =====

improve_hash_hkdf_parameter

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/03/25 22:20		current
Line 4:		Line 4:
	* Discussion Start: 2017-03-26		* Discussion Start: 2017-03-26
	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>		* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>
-	* Status: Voting	+	* Status: Rejected
	* First Published at: http://wiki.php.net/rfc/improve_hash_hkdf_parameter		* First Published at: http://wiki.php.net/rfc/improve_hash_hkdf_parameter

Line 690:		Line 690:
	State whether this project requires a 2/3		State whether this project requires a 2/3

-	<doodle title="Fix hash_hkdf() signature and behavior" auth="yohgaki" voteType="single" closed="false">	+	<doodle title="Fix hash_hkdf() signature and behavior" auth="yohgaki" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

improve_hash_hkdf_pramater

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/02/05 06:30		current
Line 1:		Line 1:
-	====== PHP RFC: Improve hash_hkdf() parameter order and handling ======	+	Page name had typo and renamed during draft.
-	* Version: 0.9	+	See [[rfc::improve_hash_hkdf_parameter]]
-	* Create Date: 2017-02-05	+
-	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>	+
-	* Status: Draft (or Under Discussion or Accepted or Declined)	+
-	* First Published at: http://wiki.php.net/rfc/improve_hash_hkdf_pramater	+
-		+
-	===== Introduction =====	+
-		+
-	HKDF is informational internet standard defined by [[https://tools.ietf.org/html/rfc5869\|RFC 5869]]. HKDF is designed to generate secure key for encryption/validation/authentication/etc from other key information such as output from hash_password(), API KEY, etc. This PHP RFC will not explain HKDF in detail, please refer to RFC 5869 or other references for details.	+
-		+
-	* https://tools.ietf.org/html/rfc5869	+
-	* https://en.wikipedia.org/wiki/Key_derivation_function	+
-	* https://en.wikipedia.org/wiki/HKDF	+
-		+
-	hash_hkdf() is added to master without PHP RFC already. It has following signature currently.	+
-		+
-	<code>	+
-	string hash_hkdf(string algo, string ikm [, int length = 0 [, string info = '' [, string salt = '']]])	+
-	</code>	+
-		+
-	Issue is parameter order and handling.	+
-		+
-	RFC 5869 "Notes for HKDF Users" states,	+
-		+
-	<blockquote>3.1. To Salt or not to Salt	+
-		+
-	**HKDF is defined to operate with and without random salt. This is	+
-	done to accommodate applications where a salt value is not available.	+
-	We stress, however, that the use of salt adds significantly to the	+
-	strength of HKDF, ensuring independence between different uses of the**	+
-	hash function, supporting "source-independent" extraction, and	+
-	strengthening the analytical results that back the HKDF design.	+
-		+
-	Random salt differs fundamentally from the initial keying material in	+
-	two ways: it is non-secret and can be re-used. As such, salt values	+
-	are available to many applications. For example, a pseudorandom	+
-	number generator (PRNG) that continuously produces outputs by	+
-	applying HKDF to renewable pools of entropy (e.g., sampled system	+
-	events) can fix a salt value and use it for multiple applications of	+
-	HKDF without having to protect the secrecy of the salt. In a	+
-	different application domain, a key agreement protocol deriving	+
-	cryptographic keys from a Diffie-Hellman exchange can derive a salt	+
-	value from public nonces exchanged and authenticated between	+
-	communicating parties as part of the key agreement (this is the	+
-	approach taken in [IKEv2]).	+
-		+
-	Ideally, the salt value is a random (or pseudorandom) string of the	+
-	length HashLen. Yet, even a salt value of less quality (shorter in	+
-	size or with limited entropy) may still make a significant	+
-	contribution to the security of the output keying material; designers	+
-	of applications are therefore encouraged to provide salt values to	+
-	HKDF if such values can be obtained by the application.	+
-		+
-	It is worth noting that, while not the typical case, some	+
-	applications may even have a secret salt value available for use; in	+
-	such a case, HKDF provides an even stronger security guarantee. An	+
-	example of such application is IKEv1 in its "public-key encryption	+
-	mode", where the "salt" to the extractor is computed from nonces that	+
-	are secret; similarly, the pre-shared mode of IKEv1 uses a secret	+
-	salt derived from the pre-shared key.	+
-	</blockquote>	+
-		+
-	<blockquote>	+
-	3.2. The 'info' Input to HKDF	+
-		+
-	While the 'info' value is optional in the definition of HKDF, it is**	+
-	often of great importance in applications. Its main objective is to**	+
-	bind the derived key material to application- and context-specific	+
-	information. For example, 'info' may contain a protocol number,	+
-	algorithm identifiers, user identities, etc. In particular, it may	+
-	prevent the derivation of the same keying material for different	+
-	contexts (when the same input key material (IKM) is used in such	+
-	different contexts). It may also accommodate additional inputs to	+
-	the key expansion part, if so desired (e.g., an application may want	+
-	to bind the key material to its length L, thus making L part of the	+
-	'info' field). There is one technical requirement from 'info': it	+
-	should be independent of the input key material value IKM.	+
-	</blockquote>	+
-		+
-	As you can see from the RFC, it states even weak "salt" can make HKDF result much stronger than without "salt". Thus users should supply "salt" whenever it is possible even if it can be omitted. HKDF is designed to be stronger with "salt".	+
-		+
-	The RFC described "info" parameter in following section. It refers as "often of great importance in applications". This PHP RFC describes how it could be important to applications in following section.	+
-		+
-	As the RFC 3.1 states "HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available." which means "If salt value can be used, use it".	+
-		+
-	The RFC describes "salt" as "salt adds significantly to the strength of HKDF" while "info" as "it is often of great importance in applications". Both parameters are important, but not equally. It is obvious from the RFC "salt" is more important.	+
-		+
-		+
-	==== hash_hkdf() applications =====	+
-		+
-	Typical PHP HKDF application can be used with "salt". This PHP RFC only describes 2 examples, but there are many PHP HKDF applications that can/should/must use with salt. e.g. Object Store, Per session encryption, etc. Developers must consider salt use for better security rather than omitting salt without proper consideration.	+
-		+
-	Please note that HKDF is designed for super secret key like master key for critical systems. There is nothing wrong to use with hash_password() generated string as input key.	+
-		+
-	=== Per user data encryption ===	+
-		+
-	- Get the secret password hash generated by hash_password() for the user. $ikm	+
-	- Get application secret salt stored in secure place. e.g. $_ENV $salt	+
-	- Generate HKDF hash value with 1 and 2. <nowiki> hash_hkdf('sha256', $ikm, 0, '', $salt) </nowiki>	+
-	- Encrypt the user data with the key from 3	+
-		+
-	Although "salt" can be omitted, per user data encryption can be much stronger for attacks.	+
-		+
-	Suppose your application had SQL injection vulnerability and your data is stolen including password hash and encrypted user data. Secret encrypted data can be decrypted by attackers if salt is NOT used.	+
-		+
-	See also Security Note section blow. The same technique can be used for per user encryption key.	+
-		+
-	Other way to encrypt per user	+
-		+
-	- Get system shared secret encryption key from secure place. $ikm	+
-	- Get user ID which is unique in the system. $info	+
-	- Generate HKDF hash value 1 and 2. <nowiki>hash_hkdf('sha256', $ikm, 0, $info)</nowiki>	+
-		+
-		+
-	Note that both method uses "secret" information for $ikm. However, there is notable difference between these 2. This method uses only 1 secret key (encryption key) and info (user ID) is known to public, 1 stolen key allows attackers to decrypt all encrypted data while previous method requires 2 secret information(password hash and secret salt) to attack. (In addition, attackers have to steal all users password hash)	+
-		+
-	There are many usages other than these two. Users can choose appropriate method for their needs.	+
-		+
-		+
-	=== CSRF token ===	+
-		+
-	When session ID is used for CSRF token, there is risk that session ID can leak to others by saving & sending HTML page, by malware web browser plugins that read page content, etc. Therefore, session ID should not be used as CSRF token. HKDF can be used to generate CSRF token belong to specific session with salt.	+
-		+
-	Setting up CSRF token	+
-	- Get expiration timestamp. ($salt)	+
-	- Generate HKDF value with 1 and session ID ($ikm). <nowiki>hash_hkdf('sha256', $ikm, 0, '', $salt)</nowiki>	+
-	- Send key from 2 and timestamp from 1 to browser as CSRF token.	+
-		+
-	Verifying CSRF token	+
-	- Get HKDF key and timestamp($salt) value from request.	+
-	- Check if timestamp is not expired.	+
-	- Generate HKDF value from session ID($ikm) and timestamp($salt). <nowiki> hash_hkdf('sha256', $ikm, 0, '', $salt)</nowiki>	+
-	- Compare HKDF value sent by browser and server generated HKDF value if it matches.	+
-		+
-	Secure CSRF token expiration can be defined with this method regardless of session ID lifetime. i.e. You can set short CSRF token expiration securely.	+
-		+
-	==Security Note==	+
-	Users must regenerate session ID periodically regardless of SSL usage for security reasons. Current OWASP recommends to regenerate rather short period. (Absolute timeout discussion is described in next section.)	+
-		+
-	<blockquote>Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.</blockquote>	+
-	https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Expiration	+
-		+
-	Therefore, use of session ID as CSRF token key source is not recommended. You are better to use separate key for CSRF token generation in $_SESSION. e.g. $_SESSION['CSRF_TOKEN_IKM'] = session_create_id(); Use secret $_SESSION['CSRF_TOKEN_IKM'] for HKDF key generation where above example uses session ID. With this method, you can generate secure HKDF CSRF token even when session ID is regenerated with your defined token expiration time.	+
-		+
-	==Use of info parameter==	+
-		+
-	"info" parameter may be used to specify domain for generated key. In CSRF context, domain could be "admin", "editor", "user", "visitor", etc. For example, if "admin" is required for all administrative features, even if administrator's CSRF token for other domains, e.g. "user", are stolen, administrative features are protected from CSRF attacks.	+
-		+
-	===== Proposal =====	+
-		+
-	Internet RFC clearly recommends "salt" value whenever it is possible. Users are likely to omit optional parameters without consideration, especially the last one when there are less likely used parameters.	+
-		+
-	Change hash_hkdf() signature from	+
-		+
-	<code>	+
-	string hash_hkdf(string algo, string ikm [, int length = 0 [, string info = '' [, string salt = '']]])	+
-	</code>	+
-		+
-	to	+
-		+
-	<code>	+
-	string hash_hkdf(string algo, string ikm, string salt [, string info = ''])	+
-	- Set NULL to use without salt, raise exception for empty string.	+
-	- Note: length is only used for internal execution optimization. It will set to proper value according to inputs.	+
-	</code>	+
-		+
-	From user perspective, "salt" and "info" parameters can be used interchangeably. However, it would be good idea to follow RFC 5869 semantics.	+
-	Unlike "info" which could be an optional in many cases, "salt" cannot be an optional with expiration enabled keys for instance. This kind of expiration is common. e.g. Amazon AWS S3 uses HKDF with expiration to allow access to objects.	+
-		+
-	Typical PHP applications that need HKDF can use (or should use) salt for security reasons as examples above. Users should consider if salt can be used or not. If use of salt is impossible, then it should set to be empty. Users shouldn't omit salt blindly. It could lead serious security issue. Therefore, salt is better to be required parameter because typical PHP applications can supply salt.	+
-		+
-	===== Discussions =====	+
-		+
-	Discussions will be added later.	+
-		+
-	===== Backward Incompatible Changes =====	+
-		+
-	None. hash_hkdf() is new function.	+
-		+
-	===== Proposed PHP Version(s) =====	+
-		+
-	Next PHP 7.x	+
-		+
-	===== RFC Impact =====	+
-		+
-	None.	+
-		+
-	===== Open Issues =====	+
-		+
-	Please comment if any.	+
-		+
-	===== Unaffected PHP Functionality =====	+
-		+
-	Nothing is affected. hash_hkdf() is new function does not affect any.	+
-		+
-	===== Future Scope =====	+
-		+
-	Please comment if any	+
-		+
-	===== Proposed Voting Choices =====	+
-	State whether this project requires a 2/3	+
-		+
-		+
-		+
-	===== Patches and Tests =====	+
-		+
-	TBD	+
-		+
-	===== Implementation =====	+
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged to	+
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+
-	- a link to the language specification section (if any)	+
-		+
-	===== References =====	+
-	Links to external references, discussions or RFCs	+
-		+
-	===== Rejected Features =====	+
-	Keep this updated with features that were discussed on the mail lists.	+

2024/09/26 20:48		current
Line 33:		Line 33:
	===== Comparison with other languages =====		===== Comparison with other languages =====

-	* Python's [[https://docs.python.org/3/library/hashlib.html\|hashlib]] module provides named constructors for each supported algorithm; the minimum list is MD5, SHA-1, four variants of SHA-2 (''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()''), four variants of SHA-3, two of SHAKE, and two of BLAKE2. The SHA-3, SHAKE, and BLAKE2 algorithms were added in Python 3.6 (2016).	+	* Python's [[https://docs.python.org/3/library/hashlib.html\|hashlib]] module provides named constructors for each supported algorithm; the minimum list is MD5, SHA-1, four variants of SHA-2 (''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()''), four variants of SHA-3, two of SHAKE, and two of BLAKE2. The SHA-3, SHAKE, and BLAKE2 algorithms were added in Python 3.6 (2016).
-	* C# has [[https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.hashalgorithm?view=net-8.0\|classes derived from ''HashAlgorithm'']] for ''MD5'', ''SHA1'', ''SHA256', ''SHA384'', ''SHA512'', ''SHA3_256'', ''SHA3_384'', and ''SHA3_512''; separate classes (outside of that hierarchy) also exist for ''Shake128'' and ''Shake256''.	+	* C# has [[https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.hashalgorithm?view=net-8.0\|classes derived from ''HashAlgorithm'']] for ''MD5'', ''SHA1'', ''SHA256'', ''SHA384'', ''SHA512'', ''SHA3_256'', ''SHA3_384'', and ''SHA3_512''; separate classes (outside of that hierarchy) also exist for ''Shake128'' and ''Shake256''.
-	* Java provides only a universal constructor [[https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/security/MessageDigest.html\|''MessageDigest.getInstance(String algorithm)'']]. The minimum set of algorithms supported is SHA-1 and SHA-256.	+	* Java provides only a universal constructor [[https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/security/MessageDigest.html\|''MessageDigest.getInstance(String algorithm)'']]. The minimum set of algorithms supported is SHA-1 and SHA-256.
-	* Apple CryptoKit (for Swift applications) has [[https://developer.apple.com/documentation/cryptokit/hashfunction\|classes adopting the ''HashFunction'' protocol]] for ''SHA256'', ''SHA384'', and ''SHA512''.	+	* Apple CryptoKit (for Swift) has [[https://developer.apple.com/documentation/cryptokit/hashfunction\|classes adopting the ''HashFunction'' protocol]] for ''SHA256'', ''SHA384'', and ''SHA512''.
		+	* Ruby's [[https://docs.ruby-lang.org/en/3.3/Digest.html\|Digest module]] provides classes for MD5, RIPEMD-160, SHA1, and SHA2 (both via ''Digest::SHA2.new(bitlen)'' and short-hand ''Digest::SHA256'', ''Digest::SHA384'', and ''Digest::SHA512'').
		+	* Go's [[https://pkg.go.dev/crypto#pkg-functions\|standard-library ''crypto'' package]] includes classes for ''md5'', ''sha1'', ''sha256'' (which also implements SHA-224), and ''sha512'' (which also implements SHA-384, SHA-512/224 and SHA-512/256).
		+	* The Web Crypto API (for JavaScript) [[https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest\|has a single ''digest()'' method]] taking a string algorithm name; the only supported algorithms are 'SHA-1', 'SHA-256', 'SHA-384', and 'SHA-512'.
		+	* As far as I can see, Rust and Perl do not provide any digest functions in their standard libraries.

	Some databases also provide standalone functions for common hashing algorithms:		Some databases also provide standalone functions for common hashing algorithms:

-	* PostgreSQL offers built-in ''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()'' functions [[https://www.postgresql.org/docs/11/release-11.html#id-1.11.6.27.5.7\|since version 11.0]] (released in 2018). Prior versions offered only ''md5()'' outside of an optional extension, as [[https://www.postgresql.org/message-id/flat/7b5fca2d-1c5d-a991-fe5c-3851ad57017d%402ndquadrant.com\|discussed in the patch proposing them]].	+	* MySQL has functions for ''md5()'' and ''sha1()'', plus [[https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_sha2\|a combined ''sha2()'' function]] which takes an argument to select SHA-224, SHA-256, SHA-384, or SHA-512.
-	* MySQL has functions for ''md5()'' and ''sha1()'', plus [[https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_sha2\|a combined ''sha2()'' function]] which takes an argument to select SHA-224, SHA-256, SHA-384, or SHA-512.	+	* PostgreSQL offers built-in ''sha224()'', ''sha256()'', ''sha384()'', and ''sha512()'' functions [[https://www.postgresql.org/docs/11/release-11.html#id-1.11.6.27.5.7\|since version 11.0]] (released in 2018). Prior versions offered only ''md5()'' outside of an optional extension, as [[https://www.postgresql.org/message-id/flat/7b5fca2d-1c5d-a991-fe5c-3851ad57017d%402ndquadrant.com\|discussed in the patch proposing them]].
-	* Presto and Trino (big data query engines used by tools like Amazon Athena) include [[https://trino.io/docs/current/functions/binary.html#hashing-functions\|nine hashing functions]] - like PHP these include ''crc32()'', ''md5()'' and ''sha1''; ''sha256()'' and ''sha512()'' variants of SHA-2, plus two variants of SpookyHashV2, one of xxHash, and one of Murmur3	+	* Microsoft SQL Server has only [[https://learn.microsoft.com/en-us/sql/t-sql/functions/hashbytes-transact-sql?view=sql-server-ver16\|a ''HASHBYTES'' function]], which takes an algorithm as a string, and accepts ''MD2'', ''MD4'', ''MD5'', ''SHA'', ''SHA1'', ''SHA2_256'', and ''SHA2_512'' (the algorithm older than SHA-2 log a deprecation notice)
		+	* Presto and Trino (big data query engines used by tools like Amazon Athena) include [[https://trino.io/docs/current/functions/binary.html#hashing-functions\|nine hashing functions]] - like PHP these include ''crc32()'', ''md5()'' and ''sha1''; ''sha256()'' and ''sha512()'' variants of SHA-2, plus two variants of SpookyHashV2, one of xxHash, and one of Murmur3

2011/06/01 00:46		current
Line 18:		Line 18:
	* Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne, @Id, etc.		* Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne, @Id, etc.
	* Zend Framework Server classes Used to automate mappings for XML-RPC, SOAP, etc.		* Zend Framework Server classes Used to automate mappings for XML-RPC, SOAP, etc.
-	* **FLOW3** for dependency injection and validation	+	* **TYPO3** for dependency injection and validation
	* Symfony2 for routing rules		* Symfony2 for routing rules
	* Others One clear thing that comes to my mind is Validation, Functional Behavior injection (which could take advantage of [[rfc:Traits]]), etc. Also, any Framework could take advantage of it somehow.		* Others One clear thing that comes to my mind is Validation, Functional Behavior injection (which could take advantage of [[rfc:Traits]]), etc. Also, any Framework could take advantage of it somehow.

2025/09/19 10:05		current
Line 13:		Line 13:
	* Volker Dusch <edorian@php.net>		* Volker Dusch <edorian@php.net>
	* Calvin Buckley <calvinb@php.net>		* Calvin Buckley <calvinb@php.net>
-	* Status: Pending Implementations	+	* Status: Implemented (for the accepted proposals)
-	* Implementation: TBD	+	* Implementation: 8.5
	* [[https://github.com/php/php-src/commit/5f8d648af6ef4e29a3c7f2b2029d08466c12bc6f\|Deprecate semicolon after case in switch statement]]		* [[https://github.com/php/php-src/commit/5f8d648af6ef4e29a3c7f2b2029d08466c12bc6f\|Deprecate semicolon after case in switch statement]]
	* [[https://github.com/php/php-src/commit/3bf21a0d43e8bc8084a19937e5d5dc354f0c07cd\|Deprecate non-standard cast names]]		* [[https://github.com/php/php-src/commit/3bf21a0d43e8bc8084a19937e5d5dc354f0c07cd\|Deprecate non-standard cast names]]
	* [[https://github.com/php/php-src/commit/3d9d68e1cacf8d185de6281bfec058b22e3094f8\|Deprecate backticks as an alias for shell_exec]]		* [[https://github.com/php/php-src/commit/3d9d68e1cacf8d185de6281bfec058b22e3094f8\|Deprecate backticks as an alias for shell_exec]]
-	* Deprecate the <php>__sleep()</php> and <php>__wakeup()</php> magic methods	+	* Deprecate the <php>__sleep()</php> and <php>__wakeup()</php> magic methods ([[https://github.com/php/php-src/commit/f18e99244b675a31a8ee5dea5dbfd75e5abf610a\|__sleep()]], [[https://github.com/php/php-src/commit/a5f2eee785d99ab97e2bfd877f015608d9e9f94e\|__wakeup()]])
-	* Deprecate using values null as an array offset and when calling array_key_exists()	+	* [[https://github.com/php/php-src/commit/49e3956b703b4aeb24c7a42ae3ee89e2a339560d\|Deprecate using values null as an array offset and when calling array_key_exists()]]
	* [[https://github.com/php/php-src/commit/3dc962b9f765f5f4a7f8c4fa93f55fee8dad84ca\|Deprecate __debugInfo() returning null]]		* [[https://github.com/php/php-src/commit/3dc962b9f765f5f4a7f8c4fa93f55fee8dad84ca\|Deprecate __debugInfo() returning null]]
	* [[https://github.com/php/php-src/commit/010fe2bb42abba0d383e9f677850ddadab46ba6a\|Deprecate constant redeclaration]]		* [[https://github.com/php/php-src/commit/010fe2bb42abba0d383e9f677850ddadab46ba6a\|Deprecate constant redeclaration]]
Line 26:		Line 26:
	* [[https://github.com/php/php-src/commit/a84a82ed88cde4dd2e73c2448e089d31c876705a\|Deprecate the report_memleaks INI directive]]		* [[https://github.com/php/php-src/commit/a84a82ed88cde4dd2e73c2448e089d31c876705a\|Deprecate the report_memleaks INI directive]]
	* [[https://github.com/php/php-src/commit/37bf0ec9610d7faf5d24bad58c8873f2452fcb4d\|Deprecate the register_argc_argv INI directive]]		* [[https://github.com/php/php-src/commit/37bf0ec9610d7faf5d24bad58c8873f2452fcb4d\|Deprecate the register_argc_argv INI directive]]
-	* Remove disable_classes INI setting	+	* [[https://github.com/php/php-src/commit/f4e2e91d4b6d28448104500819b68edf58bd263c\|Remove disable_classes INI setting]]
	* [[https://github.com/php/php-src/commit/922c225fbf1a5a7a2e43ebfdff8d91ad91e9cc25\|Deprecate Reflection*::setAccessible()]]		* [[https://github.com/php/php-src/commit/922c225fbf1a5a7a2e43ebfdff8d91ad91e9cc25\|Deprecate Reflection*::setAccessible()]]
	* [[https://github.com/php/php-src/commit/ffdc1044c9bfb6a70cd3112827135333fbdb0ca8\|Deprecate ReflectionClass::getConstant() for missing constants]]		* [[https://github.com/php/php-src/commit/ffdc1044c9bfb6a70cd3112827135333fbdb0ca8\|Deprecate ReflectionClass::getConstant() for missing constants]]
Line 35:		Line 35:
	* [[https://github.com/php/php-src/commit/94a15cc92f2593c4f7bbf0a4ef734e3f80e43e07\|Deprecate the $exclude_disabled parameter of get_defined_functions()]]		* [[https://github.com/php/php-src/commit/94a15cc92f2593c4f7bbf0a4ef734e3f80e43e07\|Deprecate the $exclude_disabled parameter of get_defined_functions()]]
	* [[https://github.com/php/php-src/commit/dc0962c2439d6140c918f132e2a24129c0b3c262\|Deprecate passing null to readdir(), rewinddir(), and closedir()]]		* [[https://github.com/php/php-src/commit/dc0962c2439d6140c918f132e2a24129c0b3c262\|Deprecate passing null to readdir(), rewinddir(), and closedir()]]
-	* Deprecate passing string which are not one byte long to ord()	+	* [[https://github.com/php/php-src/commit/93676a0425147de239f3758de6b0bce359dccdc6\|Deprecate passing string which are not one byte long to ord()]]
	* [[https://github.com/php/php-src/commit/cab46b27b9d0a91c30b596a9e1838ba1e353359c\|Deprecate passing integers outside the interval [0, 255] to chr()]]		* [[https://github.com/php/php-src/commit/cab46b27b9d0a91c30b596a9e1838ba1e353359c\|Deprecate passing integers outside the interval [0, 255] to chr()]]
	* [[https://github.com/php/php-src/commit/21625006e5e20b21f0f814ef6a3903de273f88e2\|Formally deprecate socket_set_timeout()]]		* [[https://github.com/php/php-src/commit/21625006e5e20b21f0f814ef6a3903de273f88e2\|Formally deprecate socket_set_timeout()]]
-	* Deprecate the $http_response_header predefined variable	+	* [[https://github.com/php/php-src/commit/8a5972fd83d801bdf7486178f5898d25de033a90\|Deprecate the $http_response_header predefined variable]]
-	* [ODBC] Remove flags for building against specific drivers directly	+	* [[https://github.com/php/php-src/commit/cebe50a1afa4ec0c4ebe548738975ef585000225\|[ODBC] Remove flags for building against specific drivers directly]]
	* [[https://github.com/php/php-src/commit/60047025db8451ba4a37ded3be4dc9c4afbfbeaa\|Remove support for older ODBC versions]]		* [[https://github.com/php/php-src/commit/60047025db8451ba4a37ded3be4dc9c4afbfbeaa\|Remove support for older ODBC versions]]
	* [[https://github.com/php/php-src/commit/732069d98bcd63c10360ab3f77ae376cab6d6f0d\|Deprecate PDO's 'uri:' scheme]]		* [[https://github.com/php/php-src/commit/732069d98bcd63c10360ab3f77ae376cab6d6f0d\|Deprecate PDO's 'uri:' scheme]]
-	* Deprecate driver specific PDO constants and methods	+	* Deprecate driver specific PDO constants and methods ([[https://github.com/php/php-src/commit/6f32e1c690b07f64df31b3145374ace15cc0c661\|constants]], [[https://github.com/php/php-src/commit/a4afc57f1d5f59296998ef5e3187ca42c0ab1166\|methods]])
-	* Deprecate Pdo\Pgsql constants related to statement transaction state	+	* [[https://github.com/php/php-src/commit/9f8802c41661442d1a18294fb9e9edcfb7c95bab\|Deprecate Pdo\Pgsql constants related to statement transaction state]]
	* [[https://github.com/php/php-src/commit/ccb716dcadf60d989db48e4d2963e14d7dc63df3\|Deprecate finfo_close()]]		* [[https://github.com/php/php-src/commit/ccb716dcadf60d989db48e4d2963e14d7dc63df3\|Deprecate finfo_close()]]
	* [[https://github.com/php/php-src/commit/4de2ec3895e904478df891cb31ca9f425a98dff5\|Deprecate xml_parser_free()]]		* [[https://github.com/php/php-src/commit/4de2ec3895e904478df891cb31ca9f425a98dff5\|Deprecate xml_parser_free()]]