PHP Wiki rfc

rfc:64bit-integer-type

2011-04-06T12:59:26+02:00

1273170854		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 =====

rfc:abstract_final_class

2014-12-23T01:12:53+02:00

1419293143		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

rfc:abstract_syntax_tree

2014-08-27T20:08:05+02:00

1408985860		current
Line 2:		Line 2:
	* Date: 2014-07-28		* Date: 2014-07-28
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7)
-	* Targeting: PHP 7	+
	* Discussion: http://markmail.org/message/br4ixewsnqitrx3n		* Discussion: http://markmail.org/message/br4ixewsnqitrx3n

rfc:add_str_begin_and_end_functions

2016-08-13T02:27:59+02:00

1471048058		current
Line 1:		Line 1:
	====== PHP RFC: Add str begin and end functions ======		====== PHP RFC: Add str begin and end functions ======
-	* Version: 0.1	+	* Version: 0.2
	* Date: 2016-08-01 (use today's date here)		* Date: 2016-08-01 (use today's date here)
	* Author: Will Hudgins, will@wkhudgins.info		* Author: Will Hudgins, will@wkhudgins.info

rfc:add_validate_functions_to_filter

2016-08-17T01:39:42+02:00

rfc:additional-context-in-pcntl-signal-handler

2016-07-15T02:25:21+02:00

1468541990		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

rfc:additional-splat-usage

2014-11-03T23:48:52+02:00

1415054911		current
Line 1:		Line 1:
	====== PHP RFC: Additional Usage for the Splat Operator ======		====== PHP RFC: Additional Usage for the Splat Operator ======
-	* Version: 0.2	+	* Version: 1.0
	* Date: 2014-11-03		* Date: 2014-11-03
	* Author: Chris Wright, daverandom@php.net		* Author: Chris Wright, daverandom@php.net

rfc:additional_soft_reservations_for_php7

2015-07-06T11:57:11+02:00

1435961284		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.

rfc:adopt-code-of-conduct

2016-02-09T15:23:51+02:00

1453315480		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

rfc:aliases_by_reflection

2014-12-23T00:13:21+02:00

1418671802		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

rfc:allow_multiple_simultaneous_syslog_connections

2011-10-08T16:17:21+02:00

1309872972		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

rfc:allow_url_include

2015-02-27T11:05:27+02:00

1425031419		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.

rfc:alpanumeric_decrement

2014-01-28T01:45:21+02:00

1390323321		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

rfc:alternative_callback_syntax

2012-09-19T03:30:07+02:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Alternative syntax for creating fully resolved callbacks ======
	+	* Version: 1.0
	+	* Date: 2012-09-18
	+	* Author: Stephen Clay <steve@mrclay.org>
	+	* Status: Under Discussion
	+	* First Published at: https://wiki.php.net/rfc/alternative_callback_syntax

	+	===== Introduction =====
	+
	+	This RFC proposes the syntax ''func_name::function'' for generating a callback value at runtime with correctly resolved class and function names.
	+
	+	===== Why? =====
	+
	+	The string and array formats for callbacks present difficulties for users and IDEs:
	+
	+	* Most IDEs do not recognize callbacks, and so cannot offer autocompletion, rename refactoring, and other benefits of code comprehension.
	+	* Authors can misspell identifiers inside strings.
	+	* Within namespaced code, authors can forget to prepend the namespace, since function calls within the namespace do not require it.
	+	* Where use statements change the identifier for a class, authors can forget to specify the fully resolved name.
	+
	+	===== Proposal =====
	+
	+	PHP would provide a syntax, similar to a function call, which evaluates to a string or array callback value. This would be composed of the usual function call syntax, but replacing the parameter list and surrounding parenthesis with ''::function''. For example, to create the callback ''"Foo::bar"'', one would use the expression ''Foo::bar::function''.
	+
	+	Under the proposal, the following expressions (within a namespace ''NS'' and a class ''Foo'') would evaluate as true:
	+
	+	<code php>
	+	func::function === 'NS\\func';
	+	\func::function === 'func';
	+	CN::meth::function === 'NS\\CN::meth';
	+	\CN::meth::function === 'CN::meth';
	+	self::meth::function === 'NS\\Foo::meth';
	+	$obj->meth::function === [$obj, 'meth'];
	+	parent::{'meth'}::function === ['NS\\Foo', 'parent::meth'];
	+	</code>
	+
	+	==== Example Code ====
	+
	+	<code php>
	+	namespace NS1;
	+	use NS2\Bee as B;
	+
	+	class A {
	+	static function init() {
	+	$inst = new self;
	+	var_export($inst->bar::function);
	+	$inst->bar();
	+	}
	+	function bar() {
	+	var_export(B::baz::function);
	+	}
	+	}
	+
	+	function c() {}
	+
	+	var_export(var_export ::function);
	+	var_export(A::init ::function);
	+	A::init();
	+	var_export(c ::function);
	+	</code>
	+
	+	At runtime, these values would be passed to ''var_export'':
	+
	+	<code php>
	+	'var_export';
	+	'NS1\\A::init';
	+	[$inst, 'bar'];
	+	'NS2\\Bee::baz';
	+	'NS1\\c';
	+	</code>
	+
	+	===== Considerations =====
	+
	+	As ''function'' is a reserved word, it should not be misinterpreted as a constant or method in previous versions (this idea borrowed from Ralph Schindler’s [[rfc:class_name_scalars]] RFC). If the implementation reused the T_FUNCTION token, the syntax would be case-insensitive.
	+
	+	Any other use of ''::function'' should throw a parse error. Although it may be reasonable to suggest supporting syntaxes like ''($callable)::function'' (evaluating to the value of ''$callable''), I believe this would not provide much benefit and would complicate the spec.
	+
	+	As it is permitted between a function name and its argument list, for consistency and flexibility, whitespace should be permitted before the ''::function'' tokens. It's not clear whether whitespace would improve or worsen readability of the expression in practice; this will likely depend on how syntax highlighters display the ''::function'' tokens.
	+
	+	===== Summary =====
	+
	+	''::function'' would give authors a straightforward and reliable way to specify correctly-formed callbacks without being tripped up by namespaces and ''use'' statements. Callback expressions would also be more clearly recognized as such by the reader, and by IDEs and static analysis tools.
	+
	+	===== Changelog =====
	+
	+	* 2012-09-18 Created by Steve Clay

rfc:altmbstring

2014-02-24T10:43:26+02:00

1392015858		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

rfc:annotations-in-docblock

2014-04-09T00:49:02+02:00

1305223925		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

rfc:annotations

2014-02-17T08:06:00+02:00

1306889169		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.

rfc:anonymous_catch

2014-04-09T00:53:38+02:00

1372187210		current
Line 4:		Line 4:
	* Date: 2013-06-25		* Date: 2013-06-25
	* Author: Joost Koehoorn, joost.koehoorn@gmail.com		* Author: Joost Koehoorn, joost.koehoorn@gmail.com
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/anonymous_catch		* First Published at: http://wiki.php.net/rfc/anonymous_catch

rfc:anonymous_classes

2015-04-27T16:33:18+02:00

1427562644		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

rfc:anonymous_classes_v2

2014-10-22T16:49:18+02:00

1413989312		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.

rfc:apache_tail_request

2015-03-25T12:24:28+02:00

1427282585		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

rfc:apprise_on_invalid_arithmetic_operands

2016-04-06T14:07:04+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Apprise on Invalid Arithmetic Operands ======
	+	* Version: 0.1
	+	* Date: 2016-04-06
	+	* Author: Thomas Punt, tpunt@php.net
	+	* Status: Draft
	+	* First Published at: https://wiki.php.net/rfc/apprise_on_invalid_arithmetic_operands

	+	===== Introduction =====
	+	Following on from the [[rfc:invalid_strings_in_arithmetic\|warning about invalid strings in arithmetic RFC]], this RFC proposes to warn developers when they are using invalid operands with the arithmetic operators. The overall aim is therefore to help developers catch mistakes in their code when doing something non-sensical.
	+
	+	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).
	+
	+	===== Proposal =====
	+	This RFC seeks to do the following:
	+
	+	==== Emit an E_WARNING on resource operands ====
	+	<code php>
	+	var_dump(1 + fopen(__FILE__, 'r')); // currently outputs int(6)
	+	</code>
	+	Reasoning:
	+	It is non-sensical behaviour to want to use a resource's ID, particularly without even notifying the programmer (†).
	+
	+	==== Emit an E_WARNING on null operands ====
	+	<code php>
	+	var_dump(1 + null); // currently outputs int(1)
	+	</code>
	+	Reasoning:
	+	If empty strings ("") now emit an ''E_WARNING'', then other non-numeric falsy values should too
	+
	+
	+	==== Promote the E_NOTICE for object conversions to an E_WARNING ====
	+	<code php>
	+	var_dump(1 + new StdClass); // currently outputs int(2) && Notice: Object of class stdClass could not be converted to int...
	+	</code>
	+	Reasoning:
	+	The coercion is completely non-sensical. It will always coerce an object to int(1) in this context (†), and so the error level should be raised.
	+
	+
	+
	+	(†) Even this, I feel is non-sensical. If other truthy values (such as "abc") are coerced to int(0), then both objects and resources should too. Right now, objects coerce to int(1), and resource coerces to their resource ID. For now though, this is considered out of the scope of this RFC.
	+
	+	===== Backward Incompatible Changes =====
	+	What breaks, and what is the justification for it?
	+
	+	===== Proposed PHP Version(s) =====
	+	PHP 7.1
	+
	+	===== RFC Impact =====
	+	==== To SAPIs ====
	+	Describe the impact to CLI, Development web server, embedded PHP etc.
	+
	+	==== To Existing Extensions ====
	+	Will existing extensions be affected?
	+
	+	==== To Opcache ====
	+	To be done...
	+
	+	==== New Constants ====
	+	None.
	+
	+	==== php.ini Defaults ====
	+	If there are any php.ini settings then list:
	+	* hardcoded default values
	+	* php.ini-development values
	+	* php.ini-production values
	+
	+	===== Open Issues =====
	+	Make sure there are no open issues when the vote starts!
	+
	+	===== Unaffected PHP Functionality =====
	+	List existing areas/features of PHP that will not be changed by the RFC.
	+
	+	This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.
	+
	+	===== Future Scope =====
	+	This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
	+
	+	===== Proposed Voting Choices =====
	+	Include these so readers know where you are heading and can discuss the proposed voting options.
	+
	+	State whether this project requires a 2/3 or 50%+1 majority (see [[voting]])
	+
	+	===== Patches and Tests =====
	+	Links to any external patches and tests go here.
	+
	+	If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
	+
	+	Make it clear if the patch is intended to be the final patch, or is just a prototype.
	+
	+	===== 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
	+
	+	===== References =====
	+	Links to external references, discussions or RFCs
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.

rfc:apxs-loadmodule

2012-03-07T02:25:14+02:00

1330459640		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.

rfc:argon2_password_hash

2016-08-17T20:49:17+02:00

1470766516		current
Line 39:		Line 39:

	<code>		<code>
-	memory_cost = 64 Mib	+	memory_cost = 1 Mib
-	time_cost = 3	+	time_cost = 2
-	threads = 1	+	threads = 2
	</code>		</code>

Line 119:		Line 119:
	==== Cost factors ====		==== Cost factors ====

-	This library proposes the following cost factors:	+	This library initially proposed higher cost factors, but now proposes the following cost factors:

	<code>		<code>
-	memory_cost = 64 Mib //16	+	memory_cost = 1 MiB
-	time_cost = 3	+	time_cost = 2
-	threads = 1	+	threads = 2
	</code>		</code>

-	These values are derived from recommendations from other libraries, and a recommendation from one of the developers. The reference library comes with a CLI program that lists the following defaults which could be used to make this implementation more appealing to those on systems with limited memory.	+	These cost factors are derived from: recommendations from the argon2 reference library and tests on low resource systems.
-		+
-	<code>	+
-	memory_cost = 4 Mib // 12	+
-	time_cost = 3	+
-	threads = 1	+
-	</code>	+

	==== [Resolved] m_cost, t_costs vs memory_cost, time_cost ====		==== [Resolved] m_cost, t_costs vs memory_cost, time_cost ====

rfc:argument_unpacking

2014-07-31T22:32:23+02:00

1393430165		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)

rfc:array-to-string

2016-01-02T13:20:44+02:00

1436130474		current
Line 1:		Line 1:
	====== Improve array to string conversion ======		====== Improve array to string conversion ======
-	* Version: 2.0	+	* Version: 2.1
	* Creation date: 2015-01-10		* Creation date: 2015-01-10
-	* Last modification date : 2015-02-23	+	* Last modification date : 2016-02-02
	* Author: François Laupretre, <francois@tekwire.net>		* Author: François Laupretre, <francois@tekwire.net>
-	* Status: Accepted	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/array-to-string		* First Published at: http://wiki.php.net/rfc/array-to-string
		+
		+	This RFC is withdrawn because discussion shows that the subject is far from mature
		+	and potential side effects require more discussions. It will probably be revived
		+	in the future but potential BC breaks reserve such changes for a major release.

	===== Introduction =====		===== Introduction =====
Line 92:		Line 96:
	None		None

-	===== Vote =====	+	===== Proposed Voting Choices =====

	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="true">	+	<doodle title="array-to-string" auth="francois" voteType="single" closed="false">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

-	Required majority : 2/3 of voters.	+	Voting will close March 6th, 00:00 (UTC).

-	Vote is closed . RFC is approved.	+	Required majority : 2/3 of voters.

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

rfc:array_change_keys

2016-05-31T04:20:52+02:00

1464661004		current
Line 188:		Line 188:
	===== Future Scope =====		===== Future Scope =====

-	Returning ''__toString()''able objects from the callback is not supported by this RFC. This matches the behavior of other functions like ''array_flip()'' and ''array_fill_keys()''. If such functionality is desired, a separate RFC could be created to add this functionality to all similar functions.	+	Other ''array_'' functions do not support certain features like using ''__toString()'' for keys or supporting ''Traversable'' objects like iterators, so support for them is not being proposed here either. If such functionality is desired, a separate RFC could be created to add this functionality to all similar functions.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

rfc:array_column

2013-03-20T15:58:44+02:00

1362834596		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

rfc:array_count_handlers

2011-04-06T12:59:26+02:00

1215000160		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

rfc:array_delete

2014-04-09T00:56:06+02:00

1371678080		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 =====

rfc:array_key_first_last_index

2016-01-04T08:17:34+02:00

1451681020		current
Line 1:		Line 1:
	====== PHP RFC: array_key_(first\|last\|index) ======		====== PHP RFC: array_key_(first\|last\|index) ======
-	* Version: 1.0	+	* Version: 1.0.1
	* Date: 2016-01-01		* Date: 2016-01-01
	* Author: John Bafford		* Author: John Bafford
Line 8:		Line 8:

	===== Introduction =====		===== Introduction =====
-	This RFC and its accompanying patch add the following functions:	+	Sometimes, it is necessary to retrieve the first or last key of an array, but there is no convenient means of doing so currently provided by the language without modifying the source array or resorting to odd-to-read code. This RFC and its accompanying patch add the following functions to assist with that task:

	* $key = array_key_first($array [, &$value])		* $key = array_key_first($array [, &$value])
Line 59:		Line 59:
	* foreach($arr as $key => $value); //Iterate over the entire array, doing nothing, just for the side-effect of $key still contains the last array key beyond the end of the loop.//		* foreach($arr as $key => $value); //Iterate over the entire array, doing nothing, just for the side-effect of $key still contains the last array key beyond the end of the loop.//

-	* reset($arr); $key = current($arr);	+	* reset($arr); $key = key($arr);
		+	* end($arr); $key = key($arr);
	* This modifies the array (resets the array pointer).		* This modifies the array (resets the array pointer).
-	* There is no simple way to get either the last key or an indexed key via this method.

-		+	With the reference implementation provided in the patch referenced below, array_key_first() and array_key_last() directly retrieve the array key from the underlying hash (by setting a local hash pointer to the start/end of the array and retrieving the key for that index). By necessity, array_key_index() iterates through the keys, but does so in C code, rather than in PHP code. array_key_first() and array_key_last() are implemented in terms of array_key_index(); array_key_index() exists a a consequence and extension of generalizing the common code between array_key_first() and array_key_last().
-	With the reference implementation provided below, array_key_first() and array_key_last() directly retrieve the array key from the underlying hash (by setting a local hash pointer to the start/end of the array and retrieving the key for that index). By necessity, array_key_index() iterates through the keys, but does so in C code, rather than in PHP code. array_key_first() and array_key_last() are implemented in terms of array_key_index(); array_key_index() exists a a consequence and extension of generalizing the common code between array_key_first() and array_key_last().	+

	array_key_first() and array_key_last() have O(1) time complexity. array_key_index() (when not retrieving the first or last key) has O(N) time complexity. array_key_index() is intended when only one key or value from an array is needed; if repeated calls to array_key_index() are needed for a particular array, it would likely be more performant to just use array_keys() instead. (Iterating all keys of an array using array_key_index() would be O(N^2).) As such, it's included for sake of completeness, but would likely in practice see limited use.		array_key_first() and array_key_last() have O(1) time complexity. array_key_index() (when not retrieving the first or last key) has O(N) time complexity. array_key_index() is intended when only one key or value from an array is needed; if repeated calls to array_key_index() are needed for a particular array, it would likely be more performant to just use array_keys() instead. (Iterating all keys of an array using array_key_index() would be O(N^2).) As such, it's included for sake of completeness, but would likely in practice see limited use.
Line 83:		Line 82:

	===== Open Issues =====		===== Open Issues =====
-	None noted at this time.	+	* Whether or not to include the corresponding array value as an optional-return-by-reference parameter.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

rfc:array_part

2012-11-19T07:41:15+02:00

1338218370		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

rfc:arrayof

2015-06-23T21:34:21+02:00

1435087995		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

rfc:arrow_functions

2016-08-16T18:03:29+02:00

1471361908		current
Line 119:		Line 119:

	==== Why is the prefix a caret? ====		==== Why is the prefix a caret? ====
-	Originally this RFC used a new token ''fn''. However, adding a new keyword was disliked by a few collaborators. So instead we looked at symbols. There aren't many available. There are basically only the symbols that do not have unary variants:	+	Originally this RFC used a new token ''fn''. However, adding a new keyword was disliked by a few collaborators. So instead we looked at symbols. There aren't many available; only the symbols that do not have unary variants are available. These are:

	* asterisk (''*'')		* asterisk (''*'')
Line 127:		Line 127:
	* backslash (''<nowiki>\</nowiki>'')		* backslash (''<nowiki>\</nowiki>'')
	* percent (''%'')		* percent (''%'')
		+	* greater than (''>'')
		+	* less than (''<'')

	It turns out two of those have precedence in other languagues; Objective-C uses caret and Haskell uses the backslash. The caret was selected because it is used less often in PHP than the backslash currently is. Additionally this RFC author estimates that more people will be familiar with Objective-C than Haskell within our community making the caret symbol more relatable.		It turns out two of those have precedence in other languagues; Objective-C uses caret and Haskell uses the backslash. The caret was selected because it is used less often in PHP than the backslash currently is. Additionally this RFC author estimates that more people will be familiar with Objective-C than Haskell within our community making the caret symbol more relatable.

rfc:assignment-overloading

2016-01-04T01:42:21+02:00

1451867549		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

rfc:ast_based_parsing_compilation_process

2014-08-18T18:46:01+02:00

1408380346		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>

rfc:async_signals

2016-07-06T12:15:01+02:00

1467217359		current
Line 3:		Line 3:
	* Date: 2016-06-24		* Date: 2016-06-24
	* Author: Dmitry Stogov, dmitry@zend.com		* Author: Dmitry Stogov, dmitry@zend.com
-	* Status: Voting	+	* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/async_signals		* First Published at: https://wiki.php.net/rfc/async_signals

Line 37:		Line 37:
	The vote is a straight Yes/No vote, that requires a 2/3 majority. The vote began on June 28 and will finish on July 6.		The vote is a straight Yes/No vote, that requires a 2/3 majority. The vote began on June 28 and will finish on July 6.

-	<doodle title="Asynchronous Signal Handling" auth="dmitry" voteType="single" closed="false">	+	<doodle title="Asynchronous Signal Handling" auth="dmitry" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 45:		Line 45:
	An additional 1/2 majority question:		An additional 1/2 majority question:

-	<doodle title="Chose between old and new behavior in PHP 7.* using" auth="dmitry" voteType="single" closed="false">	+	<doodle title="Chose between old and new behavior in PHP 7.* using" auth="dmitry" voteType="single" closed="true">
	* pcntl.async_signals INI directive		* pcntl.async_signals INI directive
	* pcntl_async_signals() function		* pcntl_async_signals() function
Line 54:		Line 54:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+	After the project is implemented, this section should contain
-	- the version(s) it was merged to	+	- [[http://git.php.net/?p=php-src.git;a=commitdiff;h=c03ccfe78d6b13cab9546efb616a42a8f3e8a4e0\|c03ccfe78d6b13cab9546efb616a42a8f3e8a4e0]]
-	- 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

rfc:attributes

2016-05-24T01:06:43+02:00

1463028671		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)

rfc:autoboxing

2014-04-09T00:52:12+02:00

1302087566		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 =====

rfc:autodefine

2014-04-09T00:51:35+02:00

1302087566		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

rfc:autofunc

2014-04-09T00:46:47+02:00

1313614751		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

rfc:autoload_include

2011-04-06T12:59:26+02:00

1261581134		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]]
-

rfc:automatic_csrf_protection

2016-05-19T05:49:53+02:00

1463629436		current
Line 307:		Line 307:

	* Since users may enable/disable CSRF protection, pages that accept requests must enable CSRF protection. Otherwise, protection will not work. i.e. This feature is not fool proof.		* Since users may enable/disable CSRF protection, pages that accept requests must enable CSRF protection. Otherwise, protection will not work. i.e. This feature is not fool proof.
-	* Since CSRF protections adds CSRF protection token to all applicable URLs, pages that have both private URL and public URL cannot use automatic CSRF protection.	+	* Since GET CSRF protections adds CSRF protection token to all applicable URLs, pages that have both private URL and public URL cannot use automatic GET CSRF protection.
	* CSRF token in URLs has the same risk as Trans SID. (CSRF token in URL is not recommended)		* CSRF token in URLs has the same risk as Trans SID. (CSRF token in URL is not recommended)
	* POST/GET must have a element to be validated. If you need to validate empty POST/GET or any other special inputs, use session_csrf_validate() manually. It returns SESSION_CSRF_DISABLED for empty array.		* POST/GET must have a element to be validated. If you need to validate empty POST/GET or any other special inputs, use session_csrf_validate() manually. It returns SESSION_CSRF_DISABLED for empty array.

rfc:automatic_get_set_methods

2011-04-06T12:59:26+02:00

	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.
	+

rfc:automatic_property_initialization

2014-03-06T15:28:00+02:00

1392069699		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

rfc:backslashnamespaces

2011-04-06T12:59:26+02:00

1224942892		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.

rfc:backwards_compatibility

2011-09-25T03:39:42+02:00

1316914742		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.

rfc:bare_name_array_dereference

2014-06-28T23:25:51+02:00

1403396114		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

rfc:bare_name_array_literal

2015-12-19T02:27:20+02:00

1403990732		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) {

rfc:bare_name_arrays

2014-06-02T00:21:25+02:00

1401661087		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]].

rfc:base-convert

2013-12-22T20:45:48+02:00

	current
Line 1:	Line 1:
	+
	+	====== PHP RFC: Fix base_convert() and related PHP lib functions ======
	+	* Version: 1.0
	+	* Date: 2013-12-22
	+	* Author: Sara Golemon, pollita@php.net
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/base-convert
	+
	+	===== Introduction =====
	+
	+	_php_math_basetozval(), which underlies the base_convert(), bindec(), octdec(), and hexdec() userspace functions, uses a custom parsing loop which ignores any characters in the input string which aren't in the [0-9a-zA-Z] set. This results in input strings containing garbage being quietly processed as though they were valid numeric strings, for example:
	+
	+	base_convert(1.5, 10, 10); -> 15
	+	base_convert("&%^&%^#%#^%4#%#(%!2#(%", 10, 10); -> 42
	+
	+	Equally confusing, ordinals greater or equal to the base being converted are also ignored:
	+
	+	base_convert("12304560", 2, 10); -> 4
	+
	+	===== Proposal =====
	+
	+	One of the following solutions:
	+
	+	* A. Throw a Warning (or Notice) when unexpected characters are encountered, but continue as before
	+	* 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)
	+
	+	Option A is the least BC breaking option of these three, and may be desirable for 5.4, 5.5, 5.6 branches while master takes a more aggressive option.

rfc:basic_scalar_types

2015-05-09T22:46:32+02:00

1426108663		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: Under Discussion	+	* Status: Inactive (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

rfc:batch_use_declarations

2015-01-30T00:16:02+02:00

1422573243		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.	+

rfc:better_benchmarks

2011-04-06T12:59:26+02:00

1248095392		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 =====

rfc:better_type_names_for_int64

2014-08-22T17:52:49+02:00

1408704869		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:

rfc:bigint

2015-02-15T22:06:27+02:00

1424008739		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

rfc:binary_string_comparison

2014-08-20T12:07:42+02:00

1408305877		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')

rfc:binnotation4ints

2011-08-06T21:29:28+02:00

1312628996		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 =====

rfc:boxingandunboxing

2011-04-06T12:59:26+02:00

1246897105		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.

rfc:build-openssl-by-default

2014-02-03T06:02:14+02:00

1391403711		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 =====

rfc:builtincrypt

2011-04-06T12:59:26+02:00

1269451880		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

rfc:builtinwebserver

2011-08-06T21:28:35+02:00

1312658827		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 ..

rfc:callable-interfaces

2016-04-12T12:11:09+02:00

1459944009		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 =====

rfc:callable-types

2016-06-06T23:25:38+02:00

1465248127		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

rfc:callable

2013-10-29T18:28:21+02:00

1311757552		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

rfc:callableconstructors

2016-02-25T23:19:53+02:00

1456418729		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.

rfc:calltimebyref

2011-08-06T13:07:55+02:00

1302087566		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.

rfc:case-sensitivity

2014-12-26T16:03:21+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Make the PHP core case-sensitive ======
	+	* Version: 0.0
	+	* Date: 2014-12-26
	+	* Author: François Laupretre, francois@tekwire.net
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/case-sensitivity

	+
	+	===== Introduction =====
	+
	+	This RFC is about making the PHP core case-sensitive.
	+
	+	===== Proposal =====
	+
	+	==== History ====
	+
	+	==== Why ? ====
	+
	+	==== Detail of proposal by symbol type ====
	+
	+	=== Namespaces ===
	+
	+	Case-sensitive
	+
	+	=== Classes, interfaces, and trait names ===
	+
	+	Case-sensitive
	+
	+	=== Scope resolution operators ===
	+
	+	self, parent, static ->lowercase
	+
	+	=== Functions ===
	+
	+	Case-sensitive
	+
	+	=== Magic methods ===
	+
	+	lowercase except 'toString' ('tostring' and 'toString' are valid).
	+
	+	=== 'Non-magic' Methods ===
	+
	+	Case-sensitive
	+
	+	=== Built-in constants ===
	+
	+	Remove support for case-insensitive constants. Remove CONST_CS flag.
	+
	+	Special cases for existing case-insensitive built-in constants. The following
	+	case-sensitive constants will be defined:
	+
	+	* 'NULL', 'null', 'Null',
	+	* 'TRUE', 'true', 'True',
	+	* 'FALSE', 'false', 'False'
	+
	+	Every other case combination, like 'tRUE' or 'TrUe', will be considered as
	+	userspace constants.
	+
	+	=== User-defined constants ===
	+
	+	Case-sensitive
	+
	+	=== Keywords ===
	+
	+	Keyword list at [[https://github.com/php/php-langspec/blob/master/spec/09-lexical-structure.md#keywords]]
	+
	+	lowercase-only
	+
	+	=== Other reserved names ===
	+
	+	'__halt_compiler' -> lowercase
	+
	+	===== Backward Incompatible Changes =====
	+
	+	===== Discussion and arguments =====
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	List the proposed PHP versions that the feature will be included in. Use relative versions such as "next PHP 5.x" or "next PHP 5.x.y".
	+
	+	===== RFC Impact =====
	+	==== To SAPIs ====
	+	Describe the impact to CLI, Development web server, embedded PHP etc.
	+
	+	==== To Existing Extensions ====
	+
	+	==== To Opcache ====
	+
	+	==== New Constants ====
	+
	+	* 'NULL', 'null', 'Null'
	+	* 'TRUE', 'true', 'True'
	+	* 'FALSE', 'false', 'False'
	+
	+	==== php.ini Defaults ====
	+	If there are any php.ini settings then list:
	+	* hardcoded default values
	+	* php.ini-development values
	+	* php.ini-production values
	+
	+	===== Open Issues =====
	+	Make sure there are no open issues when the vote starts!
	+
	+	===== Unaffected PHP Functionality =====
	+	List existing areas/features of PHP that will not be changed by the RFC.
	+
	+	This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.
	+
	+	===== Future Scope =====
	+	This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
	+
	+	===== Proposed Voting Choices =====
	+	Include these so readers know where you are heading and can discuss the proposed voting options.
	+
	+	State whether this project requires a 2/3 or 50%+1 majority (see [[voting]])
	+
	+	===== Patches and Tests =====
	+	Links to any external patches and tests go here.
	+
	+	If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
	+
	+	Make it clear if the patch is intended to be the final patch, or is just a prototype.
	+
	+	===== 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
	+
	+	===== References =====
	+	Links to external references, discussions or RFCs
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.

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

2015-06-15T19:10:35+02:00

1406820101		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 =====

rfc:change_required_votes_to_two_thirds

2014-11-19T20:32:06+02:00

1416425352		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:

rfc:changes_to_include_and_require

2012-03-12T21:04:50+02:00

1331222488		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 =====

rfc:checkdnsrr-default-type

2014-09-20T04:05:18+02:00

	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.

rfc:class_casting_to_scalar

2011-04-06T12:59:26+02:00

1227529727		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 =====

rfc:class_const_visibility

2016-02-20T03:26:11+02:00

1449590489		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

rfc:class_name_scalars

2013-01-19T02:50:01+02:00

1358535085		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

rfc:class_properties_initialization

2011-04-06T12:59:26+02:00

1280486679		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 ();
	}		}

rfc:cli-strict

2014-04-09T00:47:33+02:00

1309884072		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

rfc:cli_process_title

2013-03-09T14:07:00+02:00

1362701542		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

rfc:cli_server_http2

2016-04-01T06:21:42+02:00

1453105340		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 =====

rfc:closure_apply

2014-08-27T03:08:27+02:00

1408544088		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

rfc:closurefromcallable

2016-07-09T14:49:42+02:00

1467701691		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 =====

rfc:closures

2011-04-06T12:59:26+02:00

1260916857		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.

rfc:coercive_sth

2015-03-29T12:16:49+02:00

1426095850		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: Under discussion	+	* Status: Rejected
	* First Published at: http://wiki.php.net/rfc/coercive_sth		* First Published at: http://wiki.php.net/rfc/coercive_sth

Line 181:		Line 181:
	It absolutely requires a 2/3 majority, with the hope of reaching as close as possible to consensus. The vote starts on March 11th, and will end two weeks later, on March 25th.		It absolutely requires a 2/3 majority, with the hope of reaching as close as possible to consensus. The vote starts on March 11th, and will end two weeks later, on March 25th.

-	<doodle title="coercive_sth" auth="zeev" voteType="single" closed="false">	+	<doodle title="coercive_sth" auth="zeev" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:combined-comparison-operator

2016-05-17T00:10:19+02:00

1424184457		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"];

rfc:comparable

2016-02-02T03:58:18+02:00

1424384755		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 =====

rfc:consistent-names

2014-04-09T01:06:39+02:00

1390429452		current
Line 18:		Line 18:
	Add CODING_STANDARDS compliant name as default name and add legacy name as alias.		Add CODING_STANDARDS compliant name as default name and add legacy name as alias.

-	1) De facto standard names like string operation function (e.g. strcmp()) remains as it is now.	+	- De facto standard names like string operation function (e.g. strcmp()) remains as it is now.
-		+	- Other names like mb_encode_mimeheader() become alias of mb_encode_mime_header().
-	2) Other names like mb_encode_mimeheader() become alias of mb_encode_mime_header().	+	- Names in question are discussed in internals@lists.php.net
-		+	- Aliases are not deprecated and should remain at least next 10 years or more.
-	3) Names in question are discussed in internals@lists.php.net	+
-		+
-	4) Aliases are not deprecated and should remain at least next 10 years or more.	+

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

rfc:consistent_callables

2015-10-11T02:24:55+02:00

rfc:consistent_function_names

2015-03-07T01:52:00+02:00

1425688858		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)

rfc:const_scalar_expressions

2013-09-03T14:28:19+02:00

1376444790		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

rfc:const_scalar_expressions2

2013-12-12T00:06:06+02:00

1383333440		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)

rfc:const_scalar_exprs

2013-11-28T15:34:41+02:00

1385643660		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)

rfc:constant_redefinition

2016-06-20T22:33:55+02:00

1466066475		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 =====

rfc:constdereference

2014-07-07T17:41:43+02:00

1383067374		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

rfc:constructor-promotion

2013-08-07T18:27:36+02:00

	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.
	+

rfc:context_sensitive_lexer

2015-11-24T23:46:01+02:00

1432613361		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

rfc:continue_ob

2015-03-25T15:11:43+02:00

1426405048		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

rfc:cookie_max-age

2013-09-16T18:58:05+02:00

1357817647		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

rfc:core-function-exceptions

2015-08-22T06:54:50+02:00

	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]]

rfc:crypt_function_salt

2013-10-07T10:51:35+02:00

1379986684		current
Line 4:		Line 4:
	* Date: 2013-08-22		* Date: 2013-08-22
	* Author: Yasuo Ohgaki ( yohgaki@ohgaki.net )		* Author: Yasuo Ohgaki ( yohgaki@ohgaki.net )
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/crypt_function_salt		* First Published at: http://wiki.php.net/rfc/crypt_function_salt

rfc:csprng_exceptions

2015-08-10T17:11:41+02:00

1439217309		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. :)

rfc:csrandombytes

2012-01-09T15:51:34+02:00

1326113934		current
Line 65:		Line 65:
	This function shuld have a parameter specifying the number of random bytes the caller requests. The return value is a string of the requested byte length, the value being provided by the system CSPRNG.		This function shuld have a parameter specifying the number of random bytes the caller requests. The return value is a string of the requested byte length, the value being provided by the system CSPRNG.

-	The function should neither block nor return a failure status in the case that the systems entropy pool is depleted. However, it should allow the caller to discover if this is the case. Thus it should behave as openssl_random_pseudo_bytes() does, continuing to return bytes from the system CSPRNG even when its entropy sources are low and offering a flag it sets if the caller reads beyond what the CSPRNG considers secure. In other words, it should neither behave like /dev/random on Linux, which blocks when entropy is low, nor like mcrypt_create_iv(), which can return insecure results without the caller’s knowledge.	+	The function should neither block nor return a failure status in the case that the systems entropy pool is depleted. However, it should allow the caller to discover if this is the case. Thus it should behave as openssl_random_pseudo_bytes() does, continuing to return bytes from the system CSPRNG even when its entropy sources are low and offering a flag that is set if the caller reads beyond what the CSPRNG considers secure. In other words, it should neither behave like /dev/random on Linux, which blocks when entropy is low, nor like mcrypt_create_iv(), which can return insecure results without the caller’s knowledge.
-	owledge.	+

rfc:curl-file-upload

2013-10-29T18:23:21+02:00

1359402231		current
Line 3:		Line 3:
	* Date: 2013-01-06		* Date: 2013-01-06
	* Author: Stas Malyshev <stas@php.net>		* Author: Stas Malyshev <stas@php.net>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.5
	* First Published at: http://wiki.php.net/rfc/curl-file-upload		* First Published at: http://wiki.php.net/rfc/curl-file-upload
	* See also: https://bugs.php.net/bug.php?id=46439		* See also: https://bugs.php.net/bug.php?id=46439

rfc:curl-wrappers-removal-rfc

2014-01-15T01:05:35+02:00

1368094305		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

rfc:curl_http2_push

2015-12-23T16:38:58+02:00

1449687035		current
Line 3:		Line 3:
	* Date: 2015-10-01		* Date: 2015-10-01
	* Author: Davey Shafik, davey@php.net		* Author: Davey Shafik, davey@php.net
-	* Status: Voting	+	* Status: Approved
	* First Published at: https://wiki.php.net/rfc/curl_http2_push		* First Published at: https://wiki.php.net/rfc/curl_http2_push

Line 129:		Line 129:
	This vote will close on 13:00 UTC on Wed 2015-12-23		This vote will close on 13:00 UTC on Wed 2015-12-23

-	<doodle title="Add HTTP/2 Server Push Support to ext/curl" auth="davey" voteType="single" closed="false">	+	<doodle title="Add HTTP/2 Server Push Support to ext/curl" auth="davey" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:currying

2011-06-07T13:51:07+02:00

1307447380		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.

rfc:customfactories

2011-04-06T12:59:26+02:00

1258557639		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/
-

rfc:cyclic-replace

2016-01-16T01:05:03+02:00

1452902684		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: Under discussion	+	* Status: Draft
	* First Published at: http://wiki.php.net/rfc/cyclic-replace		* First Published at: http://wiki.php.net/rfc/cyclic-replace

rfc:date.timezone_warning_removal

2015-02-27T23:29:32+02:00

1424822798		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

rfc:datetime-tostring

2012-09-01T12:00:09+02:00

1346493561		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 =====

rfc:datetime_and_daylight_saving_time

2011-11-02T14:02:27+02:00

1320238783		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

rfc:datetime_tostring

2014-04-09T00:54:34+02:00

1346494398		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 =====

rfc:dbc

2015-03-01T04:45:46+02:00

1425181091		current
Line 15:		Line 15:

	This RFC is part of "Design by Contract Introduction" RFC		This RFC is part of "Design by Contract Introduction" RFC
		+
	* https://wiki.php.net/rfc/introduce_design_by_contract		* https://wiki.php.net/rfc/introduce_design_by_contract
		+
	There is alternative implementation proposal by "Definition"		There is alternative implementation proposal by "Definition"
-	* https://wiki.php.net/rfc	+
		+	* https://wiki.php.net/rfc/dbc2

rfc:dbc2

2015-03-01T04:35:25+02:00

1423955693		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: Draft	+	* Status: Discussion
	* First Published at: http://wiki.php.net/rfc/dbc2		* First Published at: http://wiki.php.net/rfc/dbc2

	===== Important Note =====		===== Important Note =====
		+
		+	This RFC is part of "Design by Contract Introduction" RFC
		+	* https://wiki.php.net/rfc/introduce_design_by_contract

	This RFC is an alternative approach to "Native DbC support" RFC.		This RFC is an alternative approach to "Native DbC support" RFC.
-	http://wiki.php.net/rfc/dbc	+	* http://wiki.php.net/rfc/dbc

	Contracts can be defined without modification to the language, however, the D documentation calls the resulting implementation "clumsy and inconsistent".		Contracts can be defined without modification to the language, however, the D documentation calls the resulting implementation "clumsy and inconsistent".

rfc:debug-info

2014-03-06T15:23:52+02:00

1394115738		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

rfc:debugoptions

2011-04-06T12:59:26+02:00

1295041233		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 =====

rfc:default_ctor

2015-01-25T09:04:54+02:00

1420936585		current
Line 110:		Line 110:
	Since this RFC changes the language semantics, the 2/3+1 vote majority is required for it to pass. The vote is a straight Yes/No vote.		Since this RFC changes the language semantics, the 2/3+1 vote majority is required for it to pass. The vote is a straight Yes/No vote.

-	<doodle title="Should PHP 7 have default constructor semantics as described in this proposal?" auth="stas" voteType="single" closed="false">	+	<doodle title="Should PHP 7 have default constructor semantics as described in this proposal?" auth="stas" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:default_encoding

2014-02-15T01:50:31+02:00

1392359644		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 =====

rfc:deprecate-ini-functions

2014-03-13T04:01:26+02:00

	current
Line 1:	Line 1:

	+	====== PHP RFC: Deprecate INI functions ======
	+	* Version: 0.9
	+	* Created Date: 2014-03-13
	+	* Modified Date: 2014-03-13
	+	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/deprecate-ini-functions
	+
	+	===== Introduction =====
	+
	+	There session_module_name(), mb_regex_encoding(), etc that get/set INI values. These functions are duplicate of ini_get()/ini_set(). In addition, INI name and function name does not match in many cases.
	+
	+	===== Proposal =====
	+
	+	Deprecate INI functions:
	+
	+	- Document deprecation in the manual now.
	+	- Add E_DEPRECATED error for PHP 5.x+
	+	- Remove deprecated functions PHP 6+
	+
	+
	+	===== Backward Incompatible Changes =====
	+
	+	- None for documentation.
	+	- E_DEPRECATED for PHP 5.x+
	+	- No function for PHP 6+
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	- E_DEPRECATED for PHP 5.x+
	+	- Remove INI functions for PHP 6+
	+
	+	===== Impact to Existing Extensions =====
	+
	+	- session
	+	- mbstring
	+	- (more modules)
	+
	+
	+
	+	===== Open Issues =====
	+
	+	- None
	+
	+
	+	===== Proposed Voting Choices =====
	+
	+	VOTE: 2014/XX/XX - 2014/XX/XX
	+
	+	<doodle title="Deprecate INI functions" auth="yohgaki" voteType="single" closed="true">
	+	* Yes
	+	* No
	+	</doodle>
	+
	+	===== 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
	+
	+	===== References =====
	+
	+	Links to external references, discussions or RFCs
	+
	+	===== Rejected Features =====
	+
	+	Keep this updated with features that were discussed on the mail lists.

rfc:deprecate_ini_set_get_aliases

2015-02-01T22:22:35+02:00

1422690409		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 =====

rfc:deprecate_mb_ereg_replace_eval_option

2016-07-11T14:10:45+02:00

1468074308		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]]

rfc:deprecate_mcrypt_rand

2016-07-16T02:59:24+02:00

1415129076		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

rfc:deprecated-modifier

2014-04-09T00:52:36+02:00

1356462487		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: Under Discussion	+	* Status: Inactive
	* First Published at: https://wiki.php.net/rfc/deprecated-modifier		* First Published at: https://wiki.php.net/rfc/deprecated-modifier

rfc:deprecations_php_7_1

2016-03-27T13:36:08+02:00

1455891930		current
Line 99:		Line 99:
	* ''sizeof'', which is an alias of ''count''.		* ''sizeof'', which is an alias of ''count''.
	* Second argument to ''spl_autoload''.		* Second argument to ''spl_autoload''.
		+	* ''gmp_random'', which is obsoleted by ''gmp_random_bits'' and ''gmp_random_range''.

	===== Rejected deprecations =====		===== Rejected deprecations =====

rfc:docblockparser

2014-04-09T00:48:49+02:00

1302087566		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

rfc:drop-datetimeinterface

2015-07-21T15:49:36+02:00

1437486079		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) =====

rfc:drop_sql.safe_mode

2014-04-09T01:00:26+02:00

1302087566		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

rfc:dtrace

2011-04-06T12:59:26+02:00

1248095145		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

rfc:dvcs

2011-09-07T15:30:08+02:00

1315215570		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

rfc:dvcsmigration

2011-04-06T12:59:26+02:00

	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
	+
	+

rfc:e-user-deprecated-warning

2013-10-29T18:30:48+02:00

1302087566		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

rfc:easy_userland_csprng

2015-05-09T22:43:18+02:00

1428598535		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

rfc:empty_isset_exprs

2012-05-24T23:06:43+02:00

1337632571		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.

rfc:encapsulation

2015-02-19T23:02:33+02:00

	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]]

rfc:engine_exceptions

2013-12-14T17:01:17+02:00

1386683567		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.

rfc:engine_exceptions_for_php7

2015-03-09T15:17:07+02:00

1425838664		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 =====

rfc:enhanced_error_handling

2014-04-09T00:56:34+02:00

1344018181		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

rfc:enum

2016-07-26T17:36:00+02:00

1467043526		current
Line 63:		Line 63:
	===== Voting =====		===== Voting =====

-	The vote will be a simple "yes" or "no" and requires 2/3 of the votes to be "yes" to pass. This RFC targets PHP version 7.1 .	+	The vote will be a simple "yes" or "no" and requires 2/3 of the votes to be "yes" to pass. This RFC targets PHP version 7.2.

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

rfc:error-formatting-for-developers

2013-10-29T18:24:06+02:00

1312993490		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

rfc:error-optimizations

2014-04-09T01:00:50+02:00

1302087566		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

rfc:error_handler_callback_parameters_passed_by_reference

2015-02-28T00:26:56+02:00

1425078997		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

rfc:error_reporting_e_notice

2012-02-27T16:56:58+02:00

	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.

rfc:errors_as_exceptions

2014-04-09T00:53:50+02:00

1302087566		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

rfc:escaper

2013-09-27T06:17:13+02:00

1380255301		current
Line 103:		Line 103:

	===== Implementation Notes =====		===== Implementation Notes =====
		+
		+	IMPORTANT: Since proper escape requires proper character encoding handling, multibyte string feature in core is mandatory for implementation.

	I am strongly opposed to allowing these functions accept unpredictable character encoding directives via php.ini. That would require additional work to validate which is precisely what this RFC should seek to avoid. By validation, I mean having programmers determine how dependencies implement escaping, what encoding they enforce (usually the default), and then determining if it can be changed by the depending applications or if the library must be forked, re-edited, etc. Those who are concious of security will review dependencies for such issues rather than blindly trust dependencies.		I am strongly opposed to allowing these functions accept unpredictable character encoding directives via php.ini. That would require additional work to validate which is precisely what this RFC should seek to avoid. By validation, I mean having programmers determine how dependencies implement escaping, what encoding they enforce (usually the default), and then determining if it can be changed by the depending applications or if the library must be forked, re-edited, etc. Those who are concious of security will review dependencies for such issues rather than blindly trust dependencies.

rfc:escaping_operator

2016-08-07T16:00:16+02:00

1470449004		current
Line 3:		Line 3:
	* Date: 2016-07-14		* Date: 2016-07-14
	* Author: Michael Vostrikov <michael.vostrikov@gmail.com>		* Author: Michael Vostrikov <michael.vostrikov@gmail.com>
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/escaping_operator		* First Published at: http://wiki.php.net/rfc/escaping_operator

rfc:exception_bt_provide_object

2016-04-11T02:16:39+02:00

	current
Line 1:	Line 1:
	+	====== Extending Exception backtraces to provide 'object' ======
	+	* Version: 1.0
	+	* Date: 11/04 - 2016
	+	* Author: Kalle Sommer Nielsen <kalle@php.net>
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/exception_bt_provide_object

	+	===== Proposal =====
	+	This RFC proposes to extend or change the way that backtraces that come with Exception works, currently it is impossible to obtain the 'object' value in backtrace frames from the \Exception::getTrace() method/\Exception::$trace property, like you would with the \debug[_print]_backtrace() functions (with the $options parameter).
	+
	+	Currently if an exception is thrown within an class instance, the $this cannot be obtained by using the exception's provided backtrace for debuggers that does more extensive analytics in userland code.
	+
	+	This RFC proposes two solutions:
	+
	+	====== Solution 1 ======
	+
	+	Always provide the 'object' index for backtrace frames, this means that the exception object will be a bit heavier as it needs to hold a reference to the callee's $this object, for each frame. This means that both the return value of the property and method will always carry the 'object' index when available.
	+
	+	====== Solution 2 ======
	+
	+	By adding a parameter to \Exception::getTrace() to pass debug options, and always keep \Exception::$trace on pair with the default of \debug[_print]_backtrace(). Internally this means we may need to save the execution state to make this possible, and I would like some input on this from Engine developers to make come up with an implementation that suits this if possible. This means only the returned value of \Exception::getTrace() will have the 'object' index if specified, the property will remain the same as it currently is.
	+
	+	====== Example ======
	+
	+	If either of the solutions is accepted, then the following example will now be possible:
	+
	+	Solution 1
	+	<code php>
	+	<?php
	+	class Test
	+	{
	+	public function error()
	+	{
	+	throw new Exception('This is a test');
	+	}
	+	}
	+
	+	try
	+	{
	+	(new Test)->error();
	+	}
	+	catch(Exception $e)
	+	{
	+	// "Test"
	+	echo(get_class($e->getTrace()[0]['object']));
	+	}
	+	?>
	+	</code>
	+
	+	Solution 2
	+	<code php>
	+	<?php
	+	class Test
	+	{
	+	public function error()
	+	{
	+	throw new Exception('This is a test');
	+	}
	+	}
	+
	+	try
	+	{
	+	(new Test)->error();
	+	}
	+	catch(Exception $e)
	+	{
	+	// "Test"
	+	echo(get_class($e->getTrace(DEBUG_BACKTRACE_PROVIDE_OBJECT)[0]['object']));
	+	}
	+	?>
	+	</code>
	+
	+	===== Backward Incompatible Changes =====
	+	There is no backwards incompatible changes to this RFC.
	+
	+	===== Proposed PHP Version =====
	+	PHP 7.1
	+
	+	===== Proposed Voting Choices =====
	+	Since this is not a language change, then this RFC requires a majority of 50%+1 to be accepted.
	+
	+	===== Patches and Tests =====
	+	Should this RFC be accepted, then a patch will be provided and committed including tests.

rfc:expectations

2015-03-28T17:56:30+02:00

1425838756		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 =====

rfc:experimental

2014-10-28T20:07:42+02:00

1414523070		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.

rfc:extdep

2011-04-06T12:59:26+02:00

1234996209		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 =====

rfc:extension_prepend_files

2015-01-04T13:55:45+02:00

1420376130		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>

rfc:extensions_load_order

2013-03-02T05:11:14+02:00

1362197387		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.

rfc:extensionsiberia

2011-04-06T12:59:26+02:00

1208198450		current
Line 1:		Line 1:
-	Siberia, the graveyard for PHP Extensions	+	Siberia, the cemetery for PHP Extensions

	TBW		TBW

rfc:fast_zpp

2015-01-28T01:38:28+02:00

1422393531		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 =====

rfc:fcallfcall

2011-04-06T12:59:26+02:00

1265823615		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]

rfc:finally

2012-10-19T23:33:13+02:00

1344963268		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

rfc:fix_list_behavior_inconsistency

2014-10-18T23:33:11+02:00

1412540127		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

rfc:forbid_dynamic_scope_introspection

2016-05-24T20:50:16+02:00

1464107948		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">

rfc:forbid_null_this_in_methods

2016-07-22T22:30:44+02:00

1461957788		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

rfc:foreach-non-scalar-keys

2013-03-12T17:53:07+02:00

1363106839		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.

rfc:foreach_void

2016-01-09T23:45:12+02:00

1452378631		current
Line 1:		Line 1:
-	====== PHP RFC: foreach iteration of keys with no values ======	+	====== PHP RFC: foreach iteration of keys without values ======
	* Version: 0.1		* Version: 0.1
	* Date: 2016-01-09		* Date: 2016-01-09
Line 7:		Line 7:

	===== Introduction =====		===== Introduction =====
-	When iterating over an array with foreach, it is not possible to retrieve only the array keys without unnecessary extra work or semantic overhead. This RFC proposes new syntax that makes this possible.	+	When iterating with foreach, it is not possible to retrieve only the keys (and not also the values) without unnecessary extra work or semantic overhead. This RFC proposes new syntax that makes this possible.

	===== Background =====		===== Background =====
Line 14:		Line 14:

	<code php>		<code php>
-	foreach ($array as $key => $value) {	+	foreach ($source as $key => $value) {
	// use the $key, ignore the $value		// use the $key, ignore the $value
	}		}
	</code>		</code>

-	Retrieving the array value and ignoring it has a performance cost in that an opcode is emitted in compilation (and executed during iteration) to retrieve the value at each iteration. If the $value is never actually used, this is an unnecessary cost.	+	Retrieving the $value and ignoring it has a performance cost in that an opcode is emitted in compilation (and executed during iteration) to retrieve the value at each iteration. If the $value is never actually used, this is an unnecessary cost.

-	Additionally, there is a semantic cost, in that even though the $value is intended to be unused, it still exists. There is no clear indication strictly via code that the value is intended to be ignored.	+	Additionally, there is a semantic cost, in that even though the $value is intended to be unused, it still exists. There is no clear indication strictly via code that the value is intended to be unused. Even when the variable is named accordingly, such as $unused, $dummy, $ignore, $_, etc, it is not always clear as to the intent. For example, $unused, $dummy, and $ignore could be all be an accurate representation of the meaning of an array's values.


Line 30:		Line 30:

	Retrieving the list of array keys for iteration in this manner is more semantically pure because it clearly indicates intent, but it involves a performance cost as a result of the call to array_keys. (An additional traversal of the array, as well as the time and memory cost of allocating/deallocating a new array to receive copies of the keys from the source array.)		Retrieving the list of array keys for iteration in this manner is more semantically pure because it clearly indicates intent, but it involves a performance cost as a result of the call to array_keys. (An additional traversal of the array, as well as the time and memory cost of allocating/deallocating a new array to receive copies of the keys from the source array.)
		+

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

-	In order to iterate over an array and retrieve only its keys, we add the following syntax:	+	In order to iterate over an array (or generator, or other object that can be iterated) and retrieve only its keys, we add the following syntax:

	<code php>		<code php>
-	foreach ($array as $key => void) {	+	foreach ($source as $key => void) {
	}		}
	</code>		</code>


-	By adding ''foreach ($array as $key => void)'', we gain the ability to iterate over the array’s keys in a performant and semantically appropriate manner, while still making it relatively easy to retrieve the array values should they be needed (either by replacing void with a variable definition, or by actually accessing the value from the source array using the key retrieved in iteration).	+	By adding this syntax, we gain the ability to iterate over the keys in a performant and semantically appropriate manner.

	By not having a target variable that receives the value, an opcode is no longer emitted (or executed) to copy that value from the source. This provides a minor performance enhancement at runtime at the expense of a slightly more complicated parser and compiler for foreach.		By not having a target variable that receives the value, an opcode is no longer emitted (or executed) to copy that value from the source. This provides a minor performance enhancement at runtime at the expense of a slightly more complicated parser and compiler for foreach.
Line 52:		Line 53:

	While in draft, the direct link to the relevant tree is: https://github.com/jbafford/php-src/tree/foreachvoid		While in draft, the direct link to the relevant tree is: https://github.com/jbafford/php-src/tree/foreachvoid
-
-	At present, this is a prototype, pending review.


Line 71:		Line 70:

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====
-	* Whether to add ''foreach ($array as $key => void)'' syntax	+	* Whether to add ''foreach ($source as $key => void)'' syntax

	This proposal adds new syntax. Accordingly, it requires a 2/3 vote.		This proposal adds new syntax. Accordingly, it requires a 2/3 vote.

rfc:foreachlist

2012-12-11T04:38:22+02:00

1350673171		current
Line 14:		Line 14:
	$users = array(		$users = array(
	array('Foo', 'Bar'),		array('Foo', 'Bar'),
-	array('Baz', 'Qux');	+	array('Baz', 'Qux'),
	);		);

rfc:fpm

2013-10-29T18:31:11+02:00

1302087566		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

rfc:fpm_change_hat

2014-01-24T18:56:21+02:00

1378461323		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

rfc:free-json-parser

2013-08-29T07:50:28+02:00

1377681399		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

rfc:friend-classes

2016-01-08T05:45:49+02:00

1452227526		current
Line 329:		Line 329:
	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

-	As this is a language change, a 2/3 majority is required for whether to add Friend Classes to PHP. (see [[voting]])	+	As this is a language change, a 2/3 majority is required. (see [[voting]])

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

rfc:function_autoloading

2015-09-03T07:10:07+02:00

1441256769		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) ===

rfc:function_autoloading2

2013-12-12T14:24:43+02:00

1386804994		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.

rfc:function_referencing

2014-11-03T23:02:28+02:00

1408380208		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

rfc:functional-elements

2011-04-06T12:59:26+02:00

1205746698		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>

rfc:functional-interfaces

2016-06-02T07:33:31+02:00

1464845590		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

rfc:functionarraydereferencing

2013-10-29T18:23:45+02:00

1302087566		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 =====

rfc:functiongetentropy

2011-08-06T12:51:31+02:00

1302087566		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.

rfc:gc_fn_pointer

2015-04-10T18:12:15+02:00

1428051804		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 =====

rfc:generator-delegation

2015-04-18T18:49:13+02:00

1427690043		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

rfc:generator-return-expressions

2015-03-17T21:58:55+02:00

1426603715		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

rfc:generators

2013-04-06T13:27:50+02:00

1356306285		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 ====

rfc:generic-arrays

2016-02-13T20:08:38+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Generic arrays ======
	+
	+	* Version: 0.1
	+	* Date: 2016-02-13
	+	* Author: Rasmus Schultz <rasmus@mindplay.dk>
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/generic-arrays
	+
	+	===== Introduction =====
	+
	+	This RFC is supplemental to the [[https://wiki.php.net/rfc/generics\|generics RFC]].
	+
	+	This RCF proposes the addition of generic arrays and enhancements to array-related functions.
	+
	+	TBD: should generic versions of the standard (SPL) collection types in PHP be part of this RFC?
	+
	+	===== Proposal =====
	+
	+	This RFC proposes the addition of two generic, type-checked countersparts to the built-in ''array'' type: one with a value type, and one with key and value types.
	+
	+	The ''array'' keyword is overloaded, such that the following will work as expected:
	+
	+	<code>
	+	$counts = array<string, int>(); // array<TKey,TValue>
	+	$counts["kittens"] = 12;
	+
	+	$versions = array<float>(); // array<TValue>
	+	$versions["php"] = 7.1;
	+	</code>
	+
	+	Violating the key or value type of a type-checked array will trigger a ''TypeError''.
	+
	+	The actual type-checks or type-conversions performed will depend on the ''strict_mode'' flag and normal type conversion rules.
	+
	+	Note that there is no generic form of the short array syntax - generic arrays can only be created explicitly by using the ''array'' keyword.
	+
	+	=== Array Type-casting ===
	+
	+	Generic arrays can be explicitly [[http://php.net/manual/en/language.types.array.php#language.types.array.casting\|type-cast]] using the following syntax:
	+
	+	<code php>
	+	$array = [1,2,3];
	+
	+	$numbers = (array<int>) $array;
	+	</code>
	+
	+	In this example, the array is fully copied, and every element is type-checked, because ''int'' is a less general element type than ''mixed''.
	+
	+	Casting to a less general index or element type than that of the source array, results in creation of a new array, and keys/elements being copied. If an index or element in the source array is incompatible with the index or element types of the created generic array, a ''TypeError'' is triggered.
	+
	+	If an array is cast to a more general (or identical) index and element type, a lazy reference to the source array is made, identical to how PHP arrays normally work internally.
	+
	+	The following results in an implicit type-cast:
	+
	+	<code php>
	+	function tally(array<int> $numbers) {
	+	// ...
	+	}
	+
	+	tally([7,8,9]);
	+	</code>
	+
	+	In this case, the implicit type-cast is successful. In a case where the conversion fails, a ''TypeError'' is thrown.
	+
	+	=== Reification ===
	+
	+	TODO describe reification of generic type arguments, describe ''array_type()'' and ''array_key_type()'' functions.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	No BC breaks are expected from this proposal.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	TBD
	+
	+	===== Proposed Voting Choices =====
	+
	+	For this proposal to be accepted, a 2/3 majority is required.
	+
	+	===== Patches and Tests =====
	+
	+	No patch has been written for this RFC.

rfc:generics

2016-04-27T06:19:57+02:00

1461597552		current
Line 289:		Line 289:
	The first example is able to infer the type argument ''T'' as ''Hat'', because the type alias was used to type-hint the argument given for the ''$content'' parameter.		The first example is able to infer the type argument ''T'' as ''Hat'', because the type alias was used to type-hint the argument given for the ''$content'' parameter.

-	The second example results in a ''TypeError'', because the type parameter ''T'' was explicitly defined as ''string''. (Note that, if we had not used ''declare(strict_types=1)'', and if ''Box'' had implemented ''__toString()'', this would have been acceptable, due to the default behavior of weak scalar type-checking.)	+	The second example results in a ''TypeError'', because the type parameter ''T'' was explicitly defined as ''string''. (Note that, if we had not used ''declare(strict_types=1)'', and if ''Box'' had implemented ''<nowiki>__toString()</nowiki>'', this would have been acceptable, due to the default behavior of weak scalar type-checking.)

	Note the addition of ''func_type_args()'', which returns a list of type-hints pertaining to the current generic function call or constructor invocation. This complements ''func_get_args()'' by providing the list of type-arguments as fully-qualified class-names.		Note the addition of ''func_type_args()'', which returns a list of type-hints pertaining to the current generic function call or constructor invocation. This complements ''func_get_args()'' by providing the list of type-arguments as fully-qualified class-names.

rfc:get-random

2014-04-09T01:00:39+02:00

1302087566		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

rfc:get_class_disallow_null_parameter

2016-08-15T09:11:03+02:00

1471218805		current
Line 61:		Line 61:
	<code php>		<code php>
	if ($some_value_that_may_be_null === null) {		if ($some_value_that_may_be_null === null) {
-	$x = __CLASS__;	+	$x = get_class();
	}		}
	else {		else {

rfc:github-pr

2014-11-01T20:10:53+02:00

1414866378		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

rfc:gmp-floating-point

2014-01-05T23:40:06+02:00

1388961488		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 =====

rfc:gmp_number

2014-01-04T08:05:32+02:00

1388447871		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.
-
-

rfc:google_groups

2016-01-11T13:30:51+02:00

1452515158		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 =====

rfc:grisu3-strtod

2014-04-09T00:47:54+02:00

1310748108		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

rfc:group_use_declarations

2015-03-08T19:19:28+02:00

1424896912		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

rfc:hash-functions-empty-key-warning

2016-04-21T02:33:17+02:00

1461196970		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.

rfc:hash_pbkdf2

2012-07-10T18:04:02+02:00

1341929364		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

rfc:hashkey

2014-10-24T07:39:37+02:00

1414000643		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.	+

rfc:heredoc-scanner-loosening

2014-09-10T05:48:34+02:00

1410320821		current
Line 108:		Line 108:
	Voting choices will be:		Voting choices will be:
	- No, leave the scanner as it is.		- No, leave the scanner as it is.
-	- Yes, loosen the newline restriction with a selected set of characters.	+	- Yes, loosen the newline restriction with characters that can't be part of an identifier.
	- Yes, remove the newline restriction altogether.		- Yes, remove the newline restriction altogether.

rfc:heredoc-with-double-quotes

2013-10-29T18:30:07+02:00

1302087566		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

rfc:horizontalreuse

2013-10-29T18:24:37+02:00

1362863048		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

rfc:howto

2015-03-11T15:04:25+02:00

1390263242		current
Line 8:		Line 8:
	- Get wiki RFC karma (this is only required if you don't have a VCS account for php.net. PHP developers can log on with their credentials and already have the necessary karma to create RFCs):		- Get wiki RFC karma (this is only required if you don't have a VCS account for php.net. PHP developers can log on with their credentials and already have the necessary karma to create RFCs):
	- Register for a wiki account at https://wiki.php.net/start?do=register.		- Register for a wiki account at https://wiki.php.net/start?do=register.
-	- Email php-webmaster@lists.php.net requesting RFC karma for your wiki account. In the email, remind people about the RFC you plan to create. Note that RFC karma does not automatically give you karma to vote. See https://wiki.php.net/rfc/voting#rfc_proposer	+	- Email internals@lists.php.net requesting RFC karma for your wiki account. In the email, remind people about the RFC you plan to create. Note that RFC karma does not automatically give you karma to vote. See https://wiki.php.net/rfc/voting#rfc_proposer
	- Create the RFC:		- Create the RFC:
	- Log into the wiki with your wiki account.		- Log into the wiki with your wiki account.

rfc:http-interface

2014-11-01T03:43:29+02:00

1414725558		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 =====

rfc:ifsetor

2011-04-06T12:59:26+02:00

1230742513		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 =====

rfc:imagettf_deprecation

2014-07-27T03:20:26+02:00

1406423810		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

rfc:immutability

2016-08-16T22:12:28+02:00

1471377663		current
Line 143:		Line 143:
	===== Examples =====		===== Examples =====
	Notice in above examples removing getters and setting properties to public is optional. They simply doesn't need to be protected anymore in fact that immutable class objects are deeply frozen with eceptions on write.		Notice in above examples removing getters and setting properties to public is optional. They simply doesn't need to be protected anymore in fact that immutable class objects are deeply frozen with eceptions on write.
		+
		+	Every example shows where internal object state is important. Any references to objects passed into immutable class constructor cannot be references to scalars or may be immutable class instances. That gives high guarantee you will keep internal state unchanged for all the time.

	----		----

rfc:improved-parser-error-message

2011-08-06T21:28:49+02:00

1312658853		current
Line 3:		Line 3:
	* Date: 2011-05-16		* Date: 2011-05-16
	* Author: Felipe Pena <felipe@php.net>		* Author: Felipe Pena <felipe@php.net>
-	* Status: Implemented	+	* Status: Implemented in 5.4
	* Discussion: [[http://markmail.org/thread/2vptpqr72xumbfsh\|May 16, 2011]]		* Discussion: [[http://markmail.org/thread/2vptpqr72xumbfsh\|May 16, 2011]]

rfc:improved-tls-defaults

2014-06-20T14:12:50+02:00

1403258973		current
Line 36:		Line 36:
	* [[https://wiki.php.net/rfc/improved-tls-defaults#honor_cipher_order\|Create "honor_cipher_order" context option]]		* [[https://wiki.php.net/rfc/improved-tls-defaults#honor_cipher_order\|Create "honor_cipher_order" context option]]
	* [[https://wiki.php.net/rfc/improved-tls-defaults#expose_negotiated_values\|Expose negotiated values]]		* [[https://wiki.php.net/rfc/improved-tls-defaults#expose_negotiated_values\|Expose negotiated values]]
-	* [[https://wiki.php.net/rfc/improved-tls-defaults#servers_forward_secrecy\|Server forward secrecy]]	+	* [[https://wiki.php.net/rfc/improved-tls-defaults#server_forward_secrecy\|Server forward secrecy]]
	* [[https://wiki.php.net/rfc/improved-tls-defaults#expose_default_cert_paths\|Expose default cert paths]]		* [[https://wiki.php.net/rfc/improved-tls-defaults#expose_default_cert_paths\|Expose default cert paths]]
	* [[https://wiki.php.net/rfc/improved-tls-defaults#stream_wrapper_creep\|Allow fine-grained protocol selection flags]]		* [[https://wiki.php.net/rfc/improved-tls-defaults#stream_wrapper_creep\|Allow fine-grained protocol selection flags]]

rfc:improved_error_callback_mechanism

2015-06-10T17:37:12+02:00

1433950597		current
Line 4:		Line 4:
	* Modify Date: 2015-06-10		* Modify Date: 2015-06-10
	* Author: Patrick Allaert <patrick@catchy.io>, Olivier Garcia <olivier@catchy.io>		* Author: Patrick Allaert <patrick@catchy.io>, Olivier Garcia <olivier@catchy.io>
-	* Status: On hold	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/improved_error_callback_mechanism		* First Published at: http://wiki.php.net/rfc/improved_error_callback_mechanism

rfc:in_operator

2015-03-30T14:42:01+02:00

1426447602		current
Line 3:		Line 3:
	* Date: 2015-03-15		* Date: 2015-03-15
	* Authors: Niklas Keller <me@kelunik.com>, Bob Weinand <bobwei9@hotmail.com>		* Authors: Niklas Keller <me@kelunik.com>, Bob Weinand <bobwei9@hotmail.com>
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/in_operator		* First Published at: http://wiki.php.net/rfc/in_operator

Line 82:		Line 82:
	Requires a 2/3 majority. Even if it passes, it will //only// get merged if the [[rfc/context_sensitive_lexer\|context sensitive lexer]] gets merged.		Requires a 2/3 majority. Even if it passes, it will //only// get merged if the [[rfc/context_sensitive_lexer\|context sensitive lexer]] gets merged.

-	<doodle title="Introduce the in operator?" auth="kelunik" voteType="single" closed="false">	+	<doodle title="Introduce the in operator?" auth="kelunik" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:incompat_ctx

2013-09-25T22:17:14+02:00

1371064001		current
Line 5:		Line 5:
	* Date: 2012-07-30		* Date: 2012-07-30
	* Author: Gustavo Lopes		* Author: Gustavo Lopes
-	* Status: Accepted, pending implementation	+	* Status: Deprecation implemented in PHP 5.6
	* First Published at: http://wiki.php.net/rfc/incompat_ctx		* First Published at: http://wiki.php.net/rfc/incompat_ctx

rfc:inconsistent-behaviors

2014-02-16T08:26:28+02:00

1392147800		current
Line 298:		Line 298:

	https://wiki.php.net/rfc/base-convert		https://wiki.php.net/rfc/base-convert
		+
		+
		+
		+	==== filter_var ====
		+
		+	https://bugs.php.net/bug.php?id=66682
		+
		+	<code php>
		+	var_dump(filter_var('01', FILTER_VALIDATE_INT));
		+	var_dump(filter_var('01', FILTER_VALIDATE_FLOAT));
		+	</code>
		+
		+	<code>
		+	bool(false)
		+	double(1)
		+	</code>


Line 316:		Line 332:

	http://jp2.php.net/min		http://jp2.php.net/min
		+
		+

rfc:indirect-method-call-by-array-var

2011-06-07T00:07:04+02:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Indirect method call by array variable ======
	+	* Version: 1.0
	+	* Date: 2011-06-05
	+	* Author: Felipe Pena <felipe@php.net>
	+	* Status: Implemented
	+	* Published in internals: http://markmail.org/thread/apqqa5lkuuedbbjf
	+
	+
	+	===== Introduction =====
	+
	+	Reading our bug tracker I noticed a good feature request (http://bugs.php.net/bug.php?id=47160) from 2009 which points to an interesting feature that I think makes sense for us, since we are now working with $f() using objects and strings, and the array('class', 'method') is an old known for call_user_func()-like functions.
	+
	+	The array to be a valid callback should be a 2-element array, and it must be for the first element object/string and for the second string only. (just like our zend_is_callable() check and opcodes related to init call)
	+
	+	===== Example =====
	+
	+	<code php>
	+	<?php
	+
	+	class Hello {
	+	public function world($x) {
	+	echo "Hello, $x\n"; return $this;
	+	}
	+	}
	+
	+
	+	$f = array('Hello','world');
	+	var_dump($f('you')); // Hello, you
	+
	+	?>
	+	</code>
	+
	+	Checking for callback, nowadays already recognizes array('class', 'method') as valid callback, so it will facility the indirect call through a variable:
	+
	+	<code php>
	+	<?php
	+
	+
	+	class Hello {
	+	static public function world($x) {
	+	echo "Hello, $x\n";
	+	}
	+	}
	+
	+
	+	function hello_world($x) {
	+	echo "Hello, $x\n";
	+	}
	+
	+
	+	$callbacks = array(
	+	array('Hello', 'world'),
	+	function ($x) { echo "Hello, $x\n"; },
	+	'hello_world'
	+	);
	+
	+
	+	foreach ($callbacks as $k => $callback) {
	+	if (is_callable($callback)) {
	+	$callback($k);
	+	}
	+	}
	+
	+	?>
	+	</code>
	+
	+	Output:
	+	<code>
	+	Hello, 0
	+	Hello, 1
	+	Hello, 2
	+	</code>
	+
	+
	+	===== Patch =====
	+
	+	- http://felipe.ath.cx/diff/fr47160.diff
	+

rfc:instance-method-call

2014-04-09T00:47:58+02:00

1396996919		current
Line 3:		Line 3:
	* Date: 2010-11-26		* Date: 2010-11-26
	* Author: Felipe Pena <felipe@php.net>		* Author: Felipe Pena <felipe@php.net>
-	* Status: Implemented	+	* Status: Implemented (Syntax 2)

	===== Introduction =====		===== Introduction =====
Line 158:		Line 158:

	* 08/04/2014 - Closed as "implemented"		* 08/04/2014 - Closed as "implemented"
-	* 06/11/2011 - Implemented in [[http://git.php.net/?p=php-src.git;a=commit;h=ff48763f4b0fee906293815b42fe3e2a167702c8\|ff48763f4b]] (PHP 5.4.0)	+	* 06/11/2011 - Implemented (Syntax 2) in [[http://git.php.net/?p=php-src.git;a=commit;h=ff48763f4b0fee906293815b42fe3e2a167702c8\|ff48763f4b]] (PHP 5.4.0)
	* 26/11/2010 - Posted RFC on internals		* 26/11/2010 - Posted RFC on internals
	* 27/11/2010 - New syntax proposed		* 27/11/2010 - New syntax proposed
	* 29/11/2010 - Added array dereferencing support (e.g. %%(new foo)[0]%%)		* 29/11/2010 - Added array dereferencing support (e.g. %%(new foo)[0]%%)

rfc:instance_counter

2013-05-08T09:28:05+02:00

1367998074		current
Line 5:		Line 5:
	* Author: Frank Liepert, contact@frank-liepert.de		* Author: Frank Liepert, contact@frank-liepert.de
	* Contributor: Joe Watkins		* Contributor: Joe Watkins
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/instance_counter		* First Published at: http://wiki.php.net/rfc/instance_counter

rfc:intdiv

2015-04-19T03:08:53+02:00

1411257332		current
Line 88:		Line 88:
	It will be in PHP 7. Since there is no 5.7 branch, it is doubtful it will actually be in 5.7.		It will be in PHP 7. Since there is no 5.7 branch, it is doubtful it will actually be in 5.7.

-	It is not yet in the PHP manual.	+	PHP Manual - http://php.net/manual/en/function.intdiv.php

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

rfc:integer_semantics

2014-09-21T01:50:13+02:00

1411254952		current
Line 3:		Line 3:
	* Date: 2014-08-19		* Date: 2014-08-19
	* Author: Andrea Faulds <ajf@ajf.me>		* Author: Andrea Faulds <ajf@ajf.me>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/integer_semantics		* First Published at: http://wiki.php.net/rfc/integer_semantics

Line 69:		Line 69:

	===== Implementation =====		===== Implementation =====
-	After the project is implemented, this section should contain	+
-	- the version(s) it was merged to	+	Merged into master. It will be in PHP 7.
-	- a link to the git commit(s)	+
-	- a link to the PHP manual entry for the feature	+	It is not yet in the manual.

	===== Vote =====		===== Vote =====

rfc:internal_constructor_behaviour

2015-04-01T14:56:17+02:00

1427882374		current
Line 225:		Line 225:
	===== Implementation =====		===== Implementation =====
	After the project is implemented, this section should contain		After the project is implemented, this section should contain
-	- the version(s) it was merged to	+	- the version(s) it was merged to: 7.0
-	- a link to the git commit(s)	+	- a link to the git commit(s): http://git.php.net/?p=php-src.git;a=commit;h=4796e0242b8cdd2a77b552fcbaa74d70d87f6d0a
-	- a link to the PHP manual entry for the feature	+	- a link to the PHP manual entry for the feature: No new manual entry, the changes are conforming to standard practice.

rfc:internal_function_return_types

2015-02-05T05:23:11+02:00

1423108230		current
Line 16:		Line 16:
	API testable, this could also makes extension-implemented frameworks/libraries control their		API testable, this could also makes extension-implemented frameworks/libraries control their
	return types.		return types.
		+
		+	See: https://github.com/php/php-src/pull/1050/files#diff-3ea93da7d1026a9f53948a5d14b1f7bdR247
		+
		+

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

rfc:internal_serialize_api

2013-12-15T19:26:14+02:00

1383166862		current
Line 163:		Line 163:
	===== Patches and Tests =====		===== Patches and Tests =====

-	PAtch is in my branch: https://github.com/bukka/php-src/compare/date_using_serialize_api#files_bucket	+	PAtch is in my branch: https://github.com/bukka/php-src/compare/serialize_internal_api

rfc:intersection_types

2016-04-28T16:26:20+02:00

1461853388		current
Line 47:		Line 47:
	</PHP>		</PHP>

-	Note that if [[rfc:union_types\|Union Types]] are also accepted then something like this will be possible, allowing for an array or an object that satisfies both Countable and Traversable:	+	Note that if [[rfc:union_types\|Union Types]] are also accepted then something like this will be possible((The experimental patch provided by Joe and Bob currently does not support mixing unions and intersections)), allowing for an array or an object that satisfies both Countable and Traversable:
	<PHP>		<PHP>
	function RecordsToList(Array \| (Countable & Traversable) $input): String {		function RecordsToList(Array \| (Countable & Traversable) $input): String {

rfc:intl.char

2015-01-16T18:17:21+02:00

1421428613		current
Line 3:		Line 3:
	* Date: 2014-11-24		* Date: 2014-11-24
	* Author: Sara Golemon, pollita@php.net		* Author: Sara Golemon, pollita@php.net
-	* Status: Under Discussion	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/intl.char		* First Published at: http://wiki.php.net/rfc/intl.char

rfc:intl.charset-detector

2016-05-15T19:12:12+02:00

1460415091		current
Line 3:		Line 3:
	* Date: 2016-04-11		* Date: 2016-04-11
	* Author: Sara Golemon <pollita@php.net>		* Author: Sara Golemon <pollita@php.net>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: https://wiki.php.net/rfc/intl.charset-detector		* First Published at: https://wiki.php.net/rfc/intl.charset-detector

rfc:intl.timezone.get-windows-id

2016-04-19T01:12:27+02:00

1460917460		current
Line 3:		Line 3:
	* Date: 2016-03-15		* Date: 2016-03-15
	* Author: Sara Golemon, pollita@php.net		* Author: Sara Golemon, pollita@php.net
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/intl.timezone.get-windows-id		* First Published at: https://wiki.php.net/rfc/intl.timezone.get-windows-id

Line 47:		Line 47:
	===== Patches and Tests =====		===== Patches and Tests =====
	https://github.com/php/php-src/compare/master...sgolemon:intl.timezone.52-updates		https://github.com/php/php-src/compare/master...sgolemon:intl.timezone.52-updates
		+
		+	===== Commits =====
		+	https://github.com/php/php-src/commit/a9568d54858912cd741df183f8eee2493361de7f

rfc:introduce-type-affinity

2015-03-17T00:06:34+02:00

1426547103		current
Line 34:		Line 34:

	* Provide data type definition/hint prior to the conversion		* Provide data type definition/hint prior to the conversion
-	* Apply type affinity function and convert	+	* Apply type affinity function and convert (User must write code unlike previous one)
	* If there is conversion error, it may raise error		* If there is conversion error, it may raise error

rfc:introduce_design_by_contract

2015-03-01T04:21:42+02:00

1425179571		current
Line 55:		Line 55:

	If you voted "yes" for DbC, please choose implementation.		If you voted "yes" for DbC, please choose implementation.
-	Requires 50%+1.	+	Requires 50%+1. In case we have the same votes, vote period is extended few days.

	<doodle title="DbC implementation" auth="yohgaki" voteType="single" closed="true">		<doodle title="DbC implementation" auth="yohgaki" voteType="single" closed="true">

rfc:invalid_strings_in_arithmetic

2016-03-30T17:48:02+02:00

1459352534		current
Line 148:		Line 148:
	The interpreter patch was merged into 7.1 here: https://github.com/php/php-src/commit/1e82ad8038d3100b7e27be870652c1f639a7200a		The interpreter patch was merged into 7.1 here: https://github.com/php/php-src/commit/1e82ad8038d3100b7e27be870652c1f639a7200a

-	The UPGRADING file notes can be found here (more extensive than in the previously-linked patch), see sections 1 and 2: https://github.com/php/php-src/blob/5be140004d8079dca6e91801c1857d1119bf4408/UPGRADING	+	The UPGRADING file notes can be found here (more extensive than in the previously-linked patch), see sections 1 and 2: https://github.com/php/php-src/blob/0105bd20b706c8ab5b0a71f59f11a9dabe735f6b/UPGRADING

	The language specification patch was merged into 7.1 here: https://github.com/php/php-langspec/commit/a3ea4e992f43ea9083c3fe3738a5ded03412f6e1		The language specification patch was merged into 7.1 here: https://github.com/php/php-langspec/commit/a3ea4e992f43ea9083c3fe3738a5ded03412f6e1

rfc:invokable

2011-04-06T12:59:26+02:00

1217693463		current
Line 13:		Line 13:
	Currently, there is no sane way to detect whether an object can be invoked or not. What this RFC proposes is an interface that covers %%__invoke()%%:		Currently, there is no sane way to detect whether an object can be invoked or not. What this RFC proposes is an interface that covers %%__invoke()%%:

		+	<code php>
	interface Invokable {		interface Invokable {
	public function __invoke($args);		public function __invoke($args);
Line 25:		Line 25:
	/* ... */		/* ... */
	}		}
		+	</code>
	And make $obj(); possible only if the interface is implemented, and not only the method.		And make $obj(); possible only if the interface is implemented, and not only the method.
	We have other examples of magic features that are covered by interfaces, like ArrayAccess or Iterator/Traversable.		We have other examples of magic features that are covered by interfaces, like ArrayAccess or Iterator/Traversable.

rfc:isset-set-operator

2014-04-09T00:48:09+02:00

1385828789		current
Line 4:		Line 4:
	* Date: 2013-11-24		* Date: 2013-11-24
	* Author: Chris London, me chrislondon co		* Author: Chris London, me chrislondon co
-	* Status: Draft	+	* Status: Draft (Inactive)

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

rfc:isset_ternary

2016-03-13T03:04:12+02:00

1450991656		current
Line 105:		Line 105:
	===== Rejected Features =====		===== Rejected Features =====
	Keep this updated with features that were discussed on the mail lists.		Keep this updated with features that were discussed on the mail lists.
		+
		+	===== Errata =====
		+
		+	The name of this RFC [[http://blog.ajf.me/2015-12-07-poorly-named-rfcs\|ought to have been "null coalescing operator", not "null coalesce operator"]].

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

		+	* (2016-03-13) Added Errata
	* v0.2.3 - Added short-circuit example		* v0.2.3 - Added short-circuit example
	* v0.2.2 - Added precedence example		* v0.2.2 - Added precedence example

rfc:iterable

2016-07-03T16:53:29+02:00

1467325736		current
Line 96:		Line 96:
	Voting began on 2016-06-24 at 6:00 pm GMT and will remain open until 2016-07-02 at 11:59 pm GMT		Voting began on 2016-06-24 at 6:00 pm GMT and will remain open until 2016-07-02 at 11:59 pm GMT

-	<doodle title="Add iterable type to PHP 7.1" auth="trowski" voteType="single" closed="false">	+	<doodle title="Add iterable type to PHP 7.1" auth="trowski" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:iteration-tools

2011-04-06T12:59:26+02:00

1225724618		current
Line 27:		Line 27:
	==== Why do we need tools for iteration ====		==== Why do we need tools for iteration ====

-	Given that iteration is such a recurrent situation and conforming to the DRY principle, but also in total respect with common sense, an abstraction is required. Thankfully, patterns regarding iteration were observed almost fourty years ago by some very smart people. These people found out that iterative processes can be abstracted away in a handful of functions.	+	Given that iteration is such a recurrent situation and conforming to the DRY principle, but also in total respect with common sense, an abstraction is required. Thankfully, patterns regarding iteration were observed almost forty years ago by some very smart people. These people found out that iterative processes can be abstracted away in a handful of functions.
	For example:		For example:
	* some of the functions modify data in the set		* some of the functions modify data in the set
Line 44:		Line 44:
	While these classes do their job they have some shortcomings:		While these classes do their job they have some shortcomings:
	* They only iterate over Traversables. Supporting arrays would be nice (Indeed, we have array_map(), array_walk() and some other similar functions for array processing, yet, I think we should unify these similar tools. Not to mention that array_* functions do not adhere to some param order standard.		* They only iterate over Traversables. Supporting arrays would be nice (Indeed, we have array_map(), array_walk() and some other similar functions for array processing, yet, I think we should unify these similar tools. Not to mention that array_* functions do not adhere to some param order standard.
-	* FilterIterator, RecursiveFilterIterator and SearchIterator require declaration of an aditional classes that extend them	+	* FilterIterator, RecursiveFilterIterator and SearchIterator require declaration of an additional classes that extend them
	* CallbackFilterIterator, although I haven't had the chance to use it, it misses one important thing. It's not passing the iterator itself as a third parameter to the callback.		* CallbackFilterIterator, although I haven't had the chance to use it, it misses one important thing. It's not passing the iterator itself as a third parameter to the callback.

Line 147:		Line 147:
	</code>		</code>

-	While the 1.2 example is very similar to 2.1 it differs from it in that it's not passing the iterator to the callback function and, of course, the fact that I use a function instead of an object. Another difference is that present implementation of CallbackFilterIterator (as documented on http://www.php.net/~helly/php/ext/spl/) may also be used as a virtual CallbackMapIterator. For example, it's not only filtering the elements of the iterator into a new iterator, but it MAY also change those values. In my proposal, the function that changes values is map() which translates a certain value to another depending on the callback function. filter() only keeps items that validate agains certain criteria inside the callback function. I believe a clear distinction between these features must be reflected in the API, thus two different functions in my proposal.	+	While the 1.2 example is very similar to 2.1 it differs from it in that it's not passing the iterator to the callback function and, of course, the fact that I use a function instead of an object. Another difference is that present implementation of CallbackFilterIterator (as documented on http://www.php.net/~helly/php/ext/spl/) may also be used as a virtual CallbackMapIterator. For example, it's not only filtering the elements of the iterator into a new iterator, but it MAY also change those values. In my proposal, the function that changes values is map() which translates a certain value to another depending on the callback function. filter() only keeps items that validate against certain criteria inside the callback function. I believe a clear distinction between these features must be reflected in the API, thus two different functions in my proposal.

-	=====Some aditional benefits=====	+	=====Some additional benefits=====
	As you have seen, my proposal includes a function called walk() which does exactly the same thing as a foreach construct. The real useful thing this function provides is the ability to mimic scope inside a foreach block. So, for example:		As you have seen, my proposal includes a function called walk() which does exactly the same thing as a foreach construct. The real useful thing this function provides is the ability to mimic scope inside a foreach block. So, for example:

Line 192:		Line 192:
	Python:		Python:
	* http://www.python.org/doc/2.5.2/tut/node7.html#SECTION007130000000000000000		* http://www.python.org/doc/2.5.2/tut/node7.html#SECTION007130000000000000000
-	* http://www.python.org/doc/2.5.2/lib/itertools-functions.html (these Python package differs quite much from what I have proposed, nevertheles we may extract other useful things from there too)	+	* http://www.python.org/doc/2.5.2/lib/itertools-functions.html (this Python package differs quite much from what I have proposed, nevertheless we may extract other useful things from there too)

rfc:jenkins

2014-04-09T00:53:26+02:00

1320843785		current
Line 3:		Line 3:
	* Date: 2011-10-20		* Date: 2011-10-20
	* Authors: Ferenc Kovacs <tyra3l.at.gmail.com>, Hannes Magnusson <bjori.at.php.net>		* Authors: Ferenc Kovacs <tyra3l.at.gmail.com>, Hannes Magnusson <bjori.at.php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: [[http://www.mail-archive.com/internals@lists.php.net/msg54099.html]]		* First Published at: [[http://www.mail-archive.com/internals@lists.php.net/msg54099.html]]

rfc:json_numeric_as_string

2015-06-16T22:02:32+02:00

1433874651		current
Line 3:		Line 3:
	* Date: 2015-05-24		* Date: 2015-05-24
	* Author: Jakub Zelenka <bukka@php.net>, Pasindu De Silva <pasindu@php.net>		* Author: Jakub Zelenka <bukka@php.net>, Pasindu De Silva <pasindu@php.net>
-	* Status: Voting	+	* Status: Rejected
	* First Published at: http://wiki.php.net/rfc/json_numeric_as_string		* First Published at: http://wiki.php.net/rfc/json_numeric_as_string

Line 142:		Line 142:
	50%+1 majority (see [[voting]]) for all votings.		50%+1 majority (see [[voting]]) for all votings.

-	It started on 2015-06-09 at 20:00 UTC and ends on 2015-06-16 at 20:00 UTC.	+	It started on 2015-06-09 at 20:00 UTC and ended on 2015-06-16 at 20:00 UTC.

	==== JSON_FLOAT_TO_STRING for decoding ====		==== JSON_FLOAT_TO_STRING for decoding ====

-	<doodle title="Include JSON_FLOAT_TO_STRING for decoding?" auth="bukka" voteType="single" closed="false">	+	<doodle title="Include JSON_FLOAT_TO_STRING for decoding?" auth="bukka" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 153:		Line 153:
	==== JSON_FLOAT_TO_STRING for encoding ====		==== JSON_FLOAT_TO_STRING for encoding ====

-	<doodle title="Include JSON_FLOAT_TO_STRING for encoding?" auth="bukka" voteType="single" closed="false">	+	<doodle title="Include JSON_FLOAT_TO_STRING for encoding?" auth="bukka" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 160:		Line 160:
	==== JSON_INT_TO_STRING for decoding ====		==== JSON_INT_TO_STRING for decoding ====

-	<doodle title="Include JSON_INT_TO_STRING for decoding?" auth="bukka" voteType="single" closed="false">	+	<doodle title="Include JSON_INT_TO_STRING for decoding?" auth="bukka" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 167:		Line 167:
	==== JSON_INT_TO_STRING for encoding ====		==== JSON_INT_TO_STRING for encoding ====

-	<doodle title="Include JSON_INT_TO_STRING for encoding?" auth="bukka" voteType="single" closed="false">	+	<doodle title="Include JSON_INT_TO_STRING for encoding?" auth="bukka" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 176:		Line 176:
	This option applies only if one of the above votes has 50%+1 votes		This option applies only if one of the above votes has 50%+1 votes

-	<doodle title="PHP version used for the included constant" auth="bukka" voteType="single" closed="false">	+	<doodle title="PHP version used for the included constant" auth="bukka" voteType="single" closed="true">
	* PHP 5.6		* PHP 5.6
	* PHP 7.0		* PHP 7.0

rfc:json_preserve_fractional_part

2015-04-09T18:59:02+02:00

1421555427		current
Line 3:		Line 3:
	* Date: 2014-12-25		* Date: 2014-12-25
	* Author: Juan Basso, jrbasso@gmail.com		* Author: Juan Basso, jrbasso@gmail.com
-	* Status: Accepted	+	* Status: Implemented (PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/json_preserve_fractional_part		* First Published at: http://wiki.php.net/rfc/json_preserve_fractional_part

Line 119:		Line 119:
	===== Patches and Tests =====		===== Patches and Tests =====
	Currently implemented on https://github.com/php/php-src/pull/642		Currently implemented on https://github.com/php/php-src/pull/642
		+
		+	===== Implementation =====
		+
		+	Merged into jsond: https://github.com/bukka/php-src/pull/1
		+
		+	jsond merged into 7.0: https://github.com/php/php-src/pull/993

	===== Rejected Features =====		===== Rejected Features =====
	None so far.		None so far.

rfc:jsonable

2014-04-09T00:55:45+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2010-03-14		* Date: 2010-03-14
	* Author: Guilherme Blanco <guilhermeblanco@hotmail.com>		* Author: Guilherme Blanco <guilhermeblanco@hotmail.com>
-	* Status: In the works	+	* Status: Inactive

rfc:jsond

2015-04-09T19:01:38+02:00

1423423833		current
Line 3:		Line 3:
	* Date: 2015-01-01		* Date: 2015-01-01
	* Author: Jakub Zelenka, bukka@php.net		* Author: Jakub Zelenka, bukka@php.net
-	* Status: Accepted	+	* Status: Implemented (PHP 7.0)

rfc:jsonserializable

2015-07-13T18:06:34+02:00

1436794402		current
Line 35:		Line 35:

	Unlike the ArrayObject, an object like this would not be accessable like an array, and would have an easier support of private variables as the setters are in the class itself. The interface would just ensure that a json_decode would trigger the jsonUnserialize method with the json.		Unlike the ArrayObject, an object like this would not be accessable like an array, and would have an easier support of private variables as the setters are in the class itself. The interface would just ensure that a json_decode would trigger the jsonUnserialize method with the json.
		+
		+	===== Updated Proposal =====
		+
		+	Due to discussions, it seems the best way to implement this method is with a new function.
		+
		+	<code php>
		+
		+	$user = json_decode_to_class($json, User::class);
		+
		+	</code>

	===== Vote ======		===== Vote ======

rfc:karma-ml

2011-04-06T12:59:26+02:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Karma-based Mailing List ======
	+	* Version: 1.0
	+	* Date: 2008-11-07
	+	* Author: Davey Shafik <davey@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/karma-ml
	+
	+	===== Introduction =====
	+
	+	This RFC is to start a discussion on technical solutions to the noise:signal ratio on internals and other mailing lists.
	+
	+	==== The Problem ====
	+
	+	The problem with mailing lists is that they are a free for all, it doesn't matter who posts, everybody at every level gets to see the post.
	+
	+	In the real world, communications pass through a hierarchy of people, escalating as necessary, passing from person to person up the chain.
	+
	+	This means that, given enough time, any mailing list starts to have a large noise:signal ratio, at least for any given person's take on the list; they want to read what they want to read, and don't need to be distracted ignoring the stuff they don't want to read.
	+
	+	===== Solving the Problem =====
	+
	+	There is an unspoken — some what hap-hazard — hierarchy among the community, which with some thought, I believe, could be defined, refined and utilized to our advantage. As an example:
	+
	+	<code>
	+	- Active internals contributors with access to internals CVS (contributions of code and useful discussions)
	+	\
	+	- Active internals contributiors without access to internals CVS (patch submitters, useful discussions)
	+	\
	+	- Active non-internals, PHP contributions (docs, phpweb, PEAR)
	+	- Active community leaders
	+	- Active project leaders
	+	- Active linux distro maintainers
	+	\
	+	- General Users with a high understand
	+	\
	+	- Genernal users with little understanding (newbies)
	+	</code>
	+
	+	If we take each of these, and assign them a number:
	+
	+	<code>
	+	L1 - Active internals contributors with access to internals CVS (contributions of code and useful discussions)
	+	\
	+	L2 - Active internals contributiors without access to internals CVS (patch submitters, useful discussions)
	+	\
	+	L3 - Active non-internals, PHP contributions (docs, phpweb, PEAR)
	+	L3 - Active community leaders
	+	L3 - Active project leaders
	+	L3 - Active linux distro maintainers
	+	\
	+	L4 - General Users with a high understand
	+	\
	+	L5 - Genernal users with little understanding (newbies)
	+	</code>
	+
	+	Now, what if, at any level, you could only see (by default) 1 level below you (and all levels above you). For example: L1 can see L2, L2 can see L3 etc.
	+
	+	This immediately means that you only see stuff that might be relevant to you; however, as a community, we then lose the ability for newcomers to contribute good ideas; because they would start out with zero karma. To help solve this issue, we adjust karma based on responses:
	+
	+	==== Scenario ====
	+
	+	* A L3 user posts something of interest
	+	* A L2 user see's the post and replies, the reply is L2
	+	* This bumps the original post up to L2 as well, maintaining context
	+	* All L2 users can see the reply and the original thread
	+	* After a second (or more?) L2 response, an L1 see's the post now, and can then participate in the discussion if they choose
	+
	+	In this case, only the thread in question is bumped up, however given enough L2/L1 (weighted) direct responses over different threads, a L3 user can gain karma and eventually become a L2 user (and obviously this applies to anyone moving up the chain)
	+
	+	In this way, threads (and by this mechanism, users also) can organically make their way up the tree as they gain traction, are discussed at each level and moved up.
	+
	+	Furthermore, by not responding to threads, they will organically die, and never make their way up the tree to bother people.
	+
	+	I believe it would be possible to have a single mailing list that could span everything from internals right down to php-general, but this is probably not desired! It would however allow the users of a single list to, regardless of their experience in the tree, contribute without weighing down the list.
	+
	+	==== Features ====
	+
	+	Karma tree seeded by current "social" climate
	+	based on CVS access level, activity in a sliding timescale, community contributions etc
	+	Some manual work will be needed on this
	+	Weighted responses, a L2 responding to a L3, will move it to L2, but 2 L1's or 1 L2 and 1 L1 responding would move it to L1, for example.
	+	Adjustable threshold. Perhaps some magnanimous internals contributor likes to help out newbies, he can choose to see the whole tree, or perhaps just 3 levels down
	+	Championing — it should be possible for a user to champion someone to quickly move them up the ladder, for example a L2 can bring a L5 up to L3, so their peers can see stuff, this is bringing the user up, not the thread
	+	Continued tweaking of karma based on CVS access and contributions
	+	Personal filters, you can add users (of any level) from whom you would like to see threads, helping the movement of stuff up the tree, skipping levels
	+	In this way, we can, in some ways, automate the karma, and in someways advance it through our own choices; creating a hierarchy based on merit and trust.
	+
	+	==== Final Thoughts ====
	+
	+	* Some smart filtering, so that "You're an idiot" responses don't elevate a thread would be good
	+	* That, or just handle it biologically — Don't respond to people in negative ways
	+	* Implementing this as a ML (in terms of interaction) is likely the only way to get some of the higher internals folks using it, a web interface [for the messages] just won't fly
	+	* Personal filters would be handled at master.php.net or maybe a new web interface for this
	+
	+	==== Comments ====
	+
	+	(paraphrased)
	+
	+	* Greg Beaver: The only way to get the core contributors to use the system, is as a mailing list filter
	+	* Lukas Smith: The automatic management is pretty good, but more transparency is needed for users on how posts/users are being ranked

rfc:keywords_as_identifiers

2013-10-28T00:51:13+02:00

1382437912		current
Line 3:		Line 3:
	* Date: 2013-09-14		* Date: 2013-09-14
	* Author: Bob Weinand, bobwei9@hotmail.com		* Author: Bob Weinand, bobwei9@hotmail.com
-	* Status: Vote	+	* Status: Declined
		+	* The implementation was creating too much need for maintenance etc. Don't duplicate that proposal without a better implementation.
	* First Published at: http://wiki.php.net/rfc/keywords_as_identifiers		* First Published at: http://wiki.php.net/rfc/keywords_as_identifiers

Line 163:		Line 164:
	===== Vote =====		===== Vote =====

-	<doodle title="Should the extended keyword support patch be merged into master?" auth="bwoebi" voteType="single" closed="false">	+	<doodle title="Should the extended keyword support patch be merged into master?" auth="bwoebi" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

-	Deadline is Monday, 28th october 2013.	+	Deadline was Monday, 28th october 2013.
	===== Versions =====		===== Versions =====
	* 1.0: Initial proposal (16.9.2013)		* 1.0: Initial proposal (16.9.2013)
	* 1.1: Added some more examples (18.9.2013)		* 1.1: Added some more examples (18.9.2013)
	* 1.2: Removed some restrictions (now all keywords are permitted except the ones which would conflict with the existing language) (16.10.2013)		* 1.2: Removed some restrictions (now all keywords are permitted except the ones which would conflict with the existing language) (16.10.2013)

rfc:kill_real

2015-10-26T11:02:32+02:00

1445853740		current
Line 2:		Line 2:
	* Version: 1.0		* Version: 1.0
	* Date: 2015-10-26		* Date: 2015-10-26
-	* Author: YKalle Sommer Nielsen <kalle@php.net>	+	* Author: Kalle Sommer Nielsen <kalle@php.net>
	* Status: Draft		* Status: Draft
	* First Published at: http://wiki.php.net/rfc/kill_real		* First Published at: http://wiki.php.net/rfc/kill_real

rfc:ldap_modify_batch

2014-01-26T11:03:15+02:00

1389881008		current
Line 4:		Line 4:
	* Date: 2013-03-01		* Date: 2013-03-01
	* Author: Ondřej Hošek, ondra.hosek@gmail.com		* Author: Ondřej Hošek, ondra.hosek@gmail.com
-	* Status: Accepted	+	* Status: Implemented in PHP 5.4
	* First Published at: http://wiki.php.net/rfc/ldap_modify_batch		* First Published at: http://wiki.php.net/rfc/ldap_modify_batch

rfc:lemon

2013-09-09T19:22:11+02:00

1378747318		current
Line 4:		Line 4:
	* Date: 2010-07-13		* Date: 2010-07-13
	* Author: Etienne Kneuss, Felipe Pena		* Author: Etienne Kneuss, Felipe Pena
-	* Status: Abandonned	+	* Status: Abandoned

	=== Abstract ===		=== Abstract ===

rfc:lexical-anon

2016-04-20T08:52:22+02:00

1461135074		current
Line 122:		Line 122:
	The property reference must be well formed, and accessible in the lexical scope:		The property reference must be well formed, and accessible in the lexical scope:

-	''$object->property''	+	<code php>
		+	$object->property
		+	</code>

	A property name cannot be used twice:		A property name cannot be used twice:

-	''use($prop, $prop)''	+	<code php>use($prop, $prop)</code>

	and		and

-	''use($prop, $this->prop)''	+	<code php>use($prop, $this->prop)</code>

	Will both raise compile time errors:		Will both raise compile time errors:

rfc:libsodium

2016-06-01T16:09:34+02:00

1464790157		current
Line 1:		Line 1:
	====== PHP RFC: Make Libsodium a Core Extension ======		====== PHP RFC: Make Libsodium a Core Extension ======
-	* Version: 0.3	+	* Version: 0.3.1
	* Date: 2016-01-07		* Date: 2016-01-07
	* Author: Scott Arciszewski, scott@paragonie.com		* Author: Scott Arciszewski, scott@paragonie.com

rfc:linecontrol

2014-04-09T00:51:43+02:00

1313036627		current
Line 3:		Line 3:
	* Date: 2011-08-11		* Date: 2011-08-11
	* Author: Gwynne Raskind <gwynne@php.net>		* Author: Gwynne Raskind <gwynne@php.net>
-	* Status: Draft	+	* Status: Draft (Inactive)
	* First Published at: http://wiki.php.net/rfc/linecontrol		* First Published at: http://wiki.php.net/rfc/linecontrol

rfc:linking_in_stream_wrappers

2014-11-30T22:51:12+02:00

1417383988		current
Line 97:		Line 97:
	==== Limitations ====		==== Limitations ====

-	It will not be possible to create links between two different stream wrappers like so:	+	It will not be possible to create links between two different stream wrappers like this:

	<PHP>		<PHP>
Line 139:		Line 139:

	===== References =====		===== References =====
-	See http://php.net/manual/en/class.streamwrapper.php	+	* http://php.net/manual/en/class.streamwrapper.php
-	See https://github.com/mikey179/vfsStream/wiki/Known-Issues	+	* [[https://github.com/mikey179/vfsStream/wiki/Known-Issues\|List of known issues in vfsStream]]
		+	* [[https://github.com/mikey179/vfsStream/tree/linking\|vfsStream reference userland implementation]]

rfc:list-syntax-trailing-commas

2015-11-04T15:05:00+02:00

1446585060		current
Line 50:		Line 50:
	- Trait implementations on a class		- Trait implementations on a class
	- Class member lists		- Class member lists
		+	- Inheriting variables from the parent scope in anonymous functions

	[[https://people.php.net/user.php?username=marcio\|Marcio Almada]] posted a gist with [[https://gist.github.com/marcioAlmada/75f8f1d47da5dcac2e57\|examples of trailing commas]] for the various lists (shown below):		[[https://people.php.net/user.php?username=marcio\|Marcio Almada]] posted a gist with [[https://gist.github.com/marcioAlmada/75f8f1d47da5dcac2e57\|examples of trailing commas]] for the various lists (shown below):
Line 99:		Line 100:
	}		}
	}		}
		+
		+	// Inheriting variables from the parent scope in anonymous functions
		+	$foo = function ($bar) use (
		+	$a,
		+	$b,
		+	$c,
		+	) {
		+	// . . .
		+	};
	</code>		</code>

Line 158:		Line 168:
	- Trait implementations on a class		- Trait implementations on a class
	- Class member lists		- Class member lists
		+	- Inheriting variables from the parent scope in anonymous functions

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

	The [[https://github.com/sgolemon/php-src/compare/master...trailing-comma\|original patch by Sara Golemon]].		The [[https://github.com/sgolemon/php-src/compare/master...trailing-comma\|original patch by Sara Golemon]].

rfc:list_default_value

2015-11-10T16:33:32+02:00

1447125737		current
Line 15:		Line 15:
	===== Proposal =====		===== Proposal =====

-	Support new syntax to set default value for list elements, when there the requested index it not found in array:	+	Support new syntax to set default values for list elements, when the requested index it is not found in array:

	<code php>		<code php>
Line 22:		Line 22:
	list($a, $b='default') = [1, 2]; // a = 1, b = 2		list($a, $b='default') = [1, 2]; // a = 1, b = 2

-	// comparation	+	// comparation
-	list($a, list($b=1, $c=2) = $arr;	+	list($a, list($b=1, $c=2)) = $arr;
	// or we need to check it ourself		// or we need to check it ourself
	if (!isset($arr[1][0])) {		if (!isset($arr[1][0])) {
Line 51:		Line 51:
	<code php>		<code php>

-	list($a, $b='deafult') = $arr;	+	list($a, $b='default') = $arr;

	// equals		// equals

rfc:list_keys

2016-03-25T18:28:57+02:00

1458926454		current
Line 298:		Line 298:
	===== Implementation =====		===== Implementation =====

-	Merged into PHP 7.1: https://github.com/php/php-src/commit/37c8bb58686b2d86f145ebe4fe39854f5951dcd7	+	Merged into php-src for PHP 7.1: https://github.com/php/php-src/commit/37c8bb58686b2d86f145ebe4fe39854f5951dcd7
		+
		+	Merged into php-langspec for PHP 7.1: https://github.com/php/php-langspec/commit/0b1a497a6c847f6566f32057f55259f68bb9ce38

	After the project is implemented, this section should contain		After the project is implemented, this section should contain

rfc:list_reference_assignment

2014-05-15T21:14:07+02:00

1382653183		current
Line 4:		Line 4:
	* Date: 2013-10-24		* Date: 2013-10-24
	* 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/list_reference_assignment		* First Published at: http://wiki.php.net/rfc/list_reference_assignment

Line 80:		Line 80:

	Any help fixing that issue is appreciated.		Any help fixing that issue is appreciated.
		+
		+	EDIT 2014-05-15: I've withdrawn this RFC, due to discovering that PHP's current approach to parsing and opcode output makes this impossible to implement.

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

rfc:load-ext-by-name

2016-05-10T14:54:13+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Allow loading extensions by name ======
	+	* Version: 1.0
	+	* Date: 2016-05-10
	+	* Author: François Laupretre <francois@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/load-ext-by-name

	+
	+	===== Introduction =====
	+
	+	This RFC proposes a portable way to configure the list of PHP extensions to load.
	+
	+	Today, 'extension=' and 'zend_extension=' lines in php.ini must contain the extension's file name.
	+	Unfortunately, this file name depends on the platform PHP is running on.
	+	The situation is still worse on WIndows, where a 'php_' prefix must be added.
	+
	+	While seasoned PHP administrators are used to this mechanism, the issue remains
	+	when writing documentation, platform-agnostic scripts and, more generally, in
	+	every case where a unified syntax would allow using the same configuration file
	+	in different environments. The typical example is
	+	the coexistence of a Windows development environment and a Linux production. In
	+	this case, it is currently impossible to write a single configuration file that will work
	+	in both environments, forcing developers to manually maintain two separate
	+	versions of the file.
	+
	+	The issue is rather easy to solve because the logic to compute the file name
	+	corresponding to a given extension is well-known and easy to implement.
	+
	+	===== Proposal =====
	+
	+	This RFC allows to load PHP and Zend extensions using the extension name instead
	+	of the file name. File names remain supported as before.
	+
	+	Example :
	+
	+	<code>
	+	extension=bz2
	+	zend_extension=xdebug
	+	</code>
	+
	+	'extension=bz2', for example, will cause PHP to load a file named 'php_bz2.dll'
	+	on Windows, or a file named 'bz2.so' on Linux.
	+
	+	Example php.ini files will be modified because loading extensions by name
	+	becomes the recommended way of configuring additional extensions to load.
	+	File names remain supported and considered as legacy.
	+
	+	Cases where the extension name is accepted :
	+
	+	- 'extension=' INI setting
	+	- 'zend_extension=' INI setting
	+	- argument to the dl() function
	+
	+	Cases where the extension name cannot be used :
	+
	+	- The '-z' CLI option still requires an absolute file path.
	+	- When specifying an absolute path, a filename must be provided. A line like 'extension=/path/to/extensions/bz2' is invalid.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	None, as file names remain supported.
	+
	+	===== Proposed PHP Version(s) =====
	+	7.1
	+	===== RFC Impact =====
	+	==== To SAPIs ====
	+
	+	None
	+
	+	==== To Existing Extensions ====
	+
	+	None
	+
	+	==== To Opcache ====
	+
	+	None
	+
	+	==== New Constants ====
	+
	+	None
	+
	+	===== Open Issues =====
	+
	+	This RFC does not pretend solving every difference that may exist between
	+	Windows and Unix configurations. Where paths are set, the differences will remain.
	+	It allows to unify the configuration in the frequent cases where the only
	+	difference is the 'extension=/zend_extension=' lines.
	+
	+	===== Unaffected PHP Functionality =====
	+
	+	The '-z' CLI option does not support extension names.
	+
	+	===== Future Scope =====
	+
	+	As it is possible to distinguish between PHP and Zend extensions at load time,
	+	the 'zend_extension=' keyword could be suppressed in favor of a single 'extension='.
	+	This is left for the future because specific constraints (like loading Zend
	+	extensions always before PHP ones) make it quite complex to implement.
	+
	+	===== Proposed Voting Choices =====
	+
	+	This RFC requires a 50%+1 majority.
	+
	+	===== Patches and Tests =====
	+
	+	Pull request (final) : [[https://github.com/php/php-src/pull/1741]]
	+
	+	===== 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
	+
	+	===== References =====
	+
	+	[[http://tekwire.net/joomla/projects/ideas/php-load-ext-by-name\|An article on the same subject]]
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.

rfc:logicalshiftoperator

2014-04-09T00:47:42+02:00

1310948762		current
Line 3:		Line 3:
	* Date: 2011-17-07		* Date: 2011-17-07
	* Author: Anthony Ferrara <ircmaxell@php.net>		* Author: Anthony Ferrara <ircmaxell@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/logicalshiftoperator		* First Published at: http://wiki.php.net/rfc/logicalshiftoperator

rfc:loop_default

2014-09-19T14:47:59+02:00

1411124685		current
Line 43:		Line 43:
	In the case of ''for'' and ''foreach'' loops it's immediately obvious that separate tracking variables would be required to monitor whether the loop had been entered. This proposal does away with that necessity and increases performance as a side-effect.		In the case of ''for'' and ''foreach'' loops it's immediately obvious that separate tracking variables would be required to monitor whether the loop had been entered. This proposal does away with that necessity and increases performance as a side-effect.

-	''do {} wile();'' loops have been deliberately excluded from this behaviour as they always enter the loop at least once. The only available behaviour for a ''default'' block on a do while loop is to have it execute if the loop only iterates once, which feels inconsistent.	+	''do {} while();'' loops have been deliberately excluded from this behaviour as they always enter the loop at least once. The only available behaviour for a ''default'' block on a do while loop is to have it execute if the loop only iterates once, which feels inconsistent.

	Alternate syntax loops also gain this functionality with a ''default:'' clause that does not break ''switch'' statements.		Alternate syntax loops also gain this functionality with a ''default:'' clause that does not break ''switch'' statements.

rfc:loop_else

2012-05-11T05:07:24+02:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Loop+Else control structure ======
	+	* Version: 1.0
	+	* Date: 2012-05-10
	+	* Author: Dmitri Ravazin <ravazin@gmail.com>
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/loop_else
	+	* Original discussion: https://bugs.php.net/bug.php?id=26411

	+
	+	===== Introduction =====
	+
	+	Performing a set of actions upon not entering a loop is a very common programming necessity. This RFC proposes an optional "else" clause that can be used after while, for, and foreach loops to simplify handling of this particular scenario.
	+
	+	A secondary objective of this RFC is to bring closure to a number of requests in bug tracker (hopefully they can be closed after this, whatever the resolution).
	+
	+	==== Syntax ====
	+	Proposed syntax will look as follows:
	+	<code php>
	+	// "foreach" example (display a list of names)
	+	foreach ($array as $x) {
	+	echo "Name: {$x->name}\n";
	+	} else {
	+	echo "No records found!\n";
	+	}
	+
	+	// "for" example (unset a range of keys from array, then return it, or return null on error)
	+	for ($i = some_very_expensive_and_ugly_looking_calculation($array); $i >= 0; $i--) {
	+	unset($array[$i]);
	+	} else {
	+	return null; // horrific error!
	+	}
	+	return $array;
	+
	+	// "while" example (return true if any $search matches have been removed from $array)
	+	while ($temp = array_search($search, $array)) {
	+	unset($array[$temp]);
	+	} else {
	+	unset($array[$search]); // just because we can
	+	return false;
	+	}
	+	return true;
	+	</code>
	+	And for comparison purposes, the following block (it's obviously longer and less elegant) contains the same code written //without// loop+else:
	+	<code php>
	+	foreach ($array as $x) {
	+	echo "Name: {$x->name}\n";
	+	}
	+	if (count($array) < 1) {
	+	echo "No records found!\n";
	+	}
	+
	+
	+
	+	if (some_very_expensive_and_ugly_looking_calculation($array) < 0) { // either that or clutter our scope with temporary variable
	+	return null;
	+	}
	+	for ($i = some_very_expensive_and_ugly_looking_calculation($array); $i >= 0; $i--) {
	+	unset($array[$i]);
	+	}
	+	return $array;
	+
	+
	+
	+	$removed = false; // no choice... have to remember this in a variable
	+	while ($temp = array_search($search, $array)) {
	+	unset($array[$temp]);
	+	$removed = true;
	+	}
	+	if (!$removed) {
	+	unset($array[$search]);
	+	}
	+	return $removed;
	+	</code>
	+
	+	===== How does this work? =====
	+
	+	==== When is loop's "else" clause executed? ====
	+	Proposed "else" clause will be executed only if main loop body has not been entered at least once (i.e. loop condition was never satisfied).
	+	For this reason do-while loop cannot have this syntax (as it is guaranteed that its body will be entered at least once).
	+
	+	So in general, a loop+else construct is the equivalent of the following user code:
	+	<code php>
	+	$loop_entered = false;
	+	loop ($condition) {
	+	// "loop" can be for, foreach, or while
	+	$loop_entered = true;
	+	}
	+	if (!$loop_entered) {
	+	// this is our "else" clause
	+	}
	+	</code>
	+
	+	==== What about loops without a body? ====
	+	I suggest loops without a body should not be allowed to have an alternate "else" clause:
	+	<code php>
	+	while($condition); // Can't add an else { } after this statement
	+	for ($i = 0; $i < 10; $i++);
	+	foreach ($array as $x);
	+	</code>
	+
	+	==== What is the precedence? ====
	+	In order to avoid BC breaks when single-statement blocks are not enclosed in {}'s, any ambiguity should always be resolved in favor of if's.
	+	This means that in the following sample "else" block belongs to the "if", and not the "while":
	+	<code php>
	+	if ($hungry)
	+	while (more_food()) {
	+	eat();
	+	else
	+	watch_tv();
	+	</code>
	+	However, when there is no conflict between a loop and an "if", this should be resolved in favor of the "closest" loop, just like it is now with if's.
	+	This means that in the following sample "else" belongs to the "foreach" loop, and not the "while":
	+	<code php>
	+	while ($condition)
	+	foreach ($array as $x)
	+	$x->doWork();
	+	else
	+	echo "No work was done!\n";
	+	</code>
	+
	+	==== Alternative syntax for control structures ====
	+	This should work as expected (while respecting the precedence order described above), e.g.:
	+	<code php>
	+	<?php while ($x = $cursor->fetchObject()): ?>
	+	<p>Hi! My name is <?php echo $x->name; ?>!</p>
	+	<?php else: ?>
	+	<p>Nothing was fetched</p>
	+	<?php endwhile; ?>
	+	</code>
	+
	+	==== How about elseif? ====
	+	Under this proposal, the following PHP code would be valid:
	+	<code php>
	+	while ($condition) {
	+	...
	+	} else if ($another_condition) {
	+	...
	+	} else {
	+	...
	+	}
	+	</code>
	+	Because of that, I believe it would make sense to allow loop+elseif syntax as well.
	+
	+	===== Pros =====
	+	* This makes code shorter, more flat, and more readable. (this is the primary objective)
	+	* Eliminates the annoyance of having to use flag variables in a lot of common use-cases
	+	* Code is more structured and predictable (e.g. no more if's that can come before OR after the loop)
	+	* No new keywords
	+	* No BC breaks
	+	* PHP would not be the first language to implement such a structure. Python has it (although it behaves differently there).
	+	* This feature has almost universal support in userland (related feature requests in bug tracker are among the highest rated of all time)
	+
	+	===== Cons =====
	+	* "This new syntax is excessive and can be confusing to new developers" (c)
	+	* "This violates the KISS principle" (c)
	+	* Overhead?
	+	* Complicated changes to the parser? Too much work for a relatively minor syntax sugar?
	+	* This syntax is not supported by any of the "big mountains" like C, C++, Java, or C#. (the former being most notable since PHP is written in it)
	+
	+	===== Common Misconceptions =====
	+
	+	* Proposed syntax can be achieved by a simple "if" statement before or after the loop.
	+	* While true in some cases (for example in most "foreach" cases this is indeed true), in others (e.g. when checked data is modified inside the loop) a temporary variable will be required to keep track of whether the loop has been entered. This is illustrated in "while" example in the Syntax section.
	+	* Even when temporary variable can be avoided, an extra "if" statement will require the repetition of loop's condition inside the "if", which can contain a very expensive and/or long calculation (see "for" example is Syntax section).
	+
	+	===== Alternative Proposals =====
	+	We could also do it the Python way, which means executing "else" upon the natural completion of the loop, and only skipping it on break, continue, or throw.
	+	I personally see this a lot less useful than this proposal.
	+
	+
	+	===== References =====
	+
	+	Original discussions in bug tracker:
	+
	+	[[https://bugs.php.net/bug.php?id=26411\|while {} else {}]] (by php at bellytime dot com)
	+
	+	[[https://bugs.php.net/bug.php?id=46240\|Build in foreach else support]] (by kjarli at gmail dot com)
	+
	+	[[https://bugs.php.net/bug.php?id=61222\|For... else construct]] (by jeroenvandenenden at gmail dot com)
	+
	+	===== Changelog =====
	+	May 10, 2012 - RFC draft created

rfc:loop_or

2014-10-10T08:49:10+02:00

1412367947		current
Line 168:		Line 168:
	This is a language change and requires a 2/3 majority in favour of the feature.		This is a language change and requires a 2/3 majority in favour of the feature.

-	<doodle title="Loop + or control structure in PHP 7" auth="leigh" voteType="single" closed="false">	+	<doodle title="Loop + or control structure in PHP 7" auth="leigh" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:lsb_parentself_forwarding

2013-10-29T18:30:33+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2008-07-22		* Date: 2008-07-22
	* Author: Etienne Kneuss <colder@php.net>		* Author: Etienne Kneuss <colder@php.net>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.3

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

rfc:magicquotes

2011-07-18T18:39:09+02:00

1311006103		current
Line 7:		Line 7:
	* Note: //This RFC is about PHP 6.0 (our old HEAD/Trunk) and NOT PHP 5.4//		* Note: //This RFC is about PHP 6.0 (our old HEAD/Trunk) and NOT PHP 5.4//
	* First Published at: http://wiki.php.net/rfc/magicquotes		* First Published at: http://wiki.php.net/rfc/magicquotes
		+	* Followed up by: [[rfc/magicquotes_finale]] for PHP 5.4

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

rfc:magicquotes_finale

2011-10-25T17:12:10+02:00

1312589036		current
Line 3:		Line 3:
	* Date: 2011-07-18		* Date: 2011-07-18
	* Author: Daniel Convissor <danielc@php.net>		* Author: Daniel Convissor <danielc@php.net>
-	* Status: Declined	+	* Status: Withdrawn
	* First Published at: https://wiki.php.net/rfc/magicquotes_finale		* First Published at: https://wiki.php.net/rfc/magicquotes_finale
	* Extends: https://wiki.php.net/rfc/magicquotes		* Extends: https://wiki.php.net/rfc/magicquotes

rfc:managinglisttraffic

2011-04-06T12:59:26+02:00

1225478278		current
Line 8:		Line 8:

	This RFC proposes a way to reduce mailinglist traffic on the internals list without making it impossible for the community to raise their concerns on this vital piece of infrastructure on PHP.net decision making.		This RFC proposes a way to reduce mailinglist traffic on the internals list without making it impossible for the community to raise their concerns on this vital piece of infrastructure on PHP.net decision making.
-
	===== Introduction =====		===== Introduction =====

	So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool.		So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool.

-	I had a chat about this with Zoe, Stephan (of symfony fame) and Pierre at IPC. In this discussion I got the following idea (note that I am listing the names here in order to credit them in this idea, not because they necessarily endorse it):	+	I had a chat about this with Zoe, Stefan (of symfony fame) and Pierre at IPC. In this discussion I got the following idea (note that I am listing the names here in order to credit them in this idea, not because they necessarily endorse it):

	===== Proposal =====		===== Proposal =====
Line 24:		Line 23:

	===== Changelog =====		===== Changelog =====
-
-
-

rfc:mcrypt-viking-funeral

2016-07-11T14:09:45+02:00

1468175003		current
Line 3:		Line 3:
	* Date: 2016-01-09		* Date: 2016-01-09
	* Author: Scott Arciszewski, security@paragonie.com		* Author: Scott Arciszewski, security@paragonie.com
-	* Status: Accepted	+	* Status: Implemented (PHP 7.1)
	* First Published at: http://wiki.php.net/rfc/mcrypt-viking-funeral		* First Published at: http://wiki.php.net/rfc/mcrypt-viking-funeral

Line 134:		Line 134:

	Patches are available:		Patches are available:
-	* <https://github.com/php/php-src/pull/1995>	+	* <del><https://github.com/php/php-src/pull/1995></del>
-	* <https://github.com/php/php-src/pull/1996>	+	* <https://github.com/php/php-src/pull/1996> (merged)

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

rfc:mixin

2011-04-06T12:59:26+02:00

1221129050		current
Line 169:		Line 169:

	<code php>		<code php>
-	class_mixin('PHPUnit_Framework_Assert', 'MY_Assert_Methods'); // throws an E_FATAL Error	+	class_mixin('PHPUnit_Framework_Assert', 'MY_Assert_Methods'); // throws an E_ERROR
	</code>		</code>

rfc:moduleapi-inspection

2014-01-24T11:07:12+02:00

	current
Line 1:	Line 1:
	+
	+	====== PHP RFC: Module API Inspection ======
	+	* Version: 1.0
	+	* Date: 2014-01-24
	+	* Author: Sara Golemon, pollita@php.net
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/moduleapi-inspection
	+
	+	===== Introduction =====
	+
	+	Was asked at PHPBenelux about being able to tell what PHP version a given module is loadable in (given only the .so). Since the answer came down to "Try it and see if it works", I thought something more formal would be nice.
	+
	+	===== Proposal =====
	+
	+	Add zend module api introspection to php-cli as two new command line switches
	+
	+	`--apino` option: Outputs PHP's compiled Zend Module API info:
	+
	+	$ sapi/cli/php --apino
	+	ZEND_MODULE_API_NO: 20131227
	+	ZEND_DEBUG: enabled
	+	ZTS: enabled
	+
	+	`--modinfo /path/to/module.so` Options: Loads the .so (without attempting to register it as an extension) and output the corresponding Zend Module API info the module was compiled with.
	+
	+	$ sapi/cli/php --modinfo /usr/libexec/php/hello.so
	+	ZEND_MODULE_API_NO: 20121212
	+	ZEND_DEBUG: disabled
	+	ZTS: disabled
	+
	+	===== Backward Incompatible Changes =====
	+
	+	Very old zend_module_entry versions have slightly different module headers. I addressed this by putting a bottom limit on the Zend Module API Version I'll look at which corresponds to 5.0. In earlier versions only the high-level API version number is shown.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	5.next
	+
	+	===== SAPIs Impacted =====
	+
	+	CLI
	+
	+	===== Unaffected PHP Functionality =====
	+
	+	This doesn't impact the engine or runtime at all. It's just a set of options for the command line sapi which dump some info and exit.
	+
	+	===== Implementation =====
	+
	+	https://github.com/sgolemon/php-src/compare/apino

rfc:multibyte_char_handling

2014-02-24T10:42:53+02:00

1392000146		current
Line 4:		Line 4:
	* Date: 2014-02-03		* Date: 2014-02-03
	* Author: Yasuo Ohgaki, yohgaki@ohgaki.net		* Author: Yasuo Ohgaki, yohgaki@ohgaki.net
-	* Status: Vote	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/multibyte_char_handling		* First Published at: http://wiki.php.net/rfc/multibyte_char_handling

Line 131:		Line 131:
	This vote is only for adding new mb_*() functions to released versions.		This vote is only for adding new mb_*() functions to released versions.

-	<doodle title="Add required mb_() functions to fix vulnerability" auth="yohgaki" voteType="single" closed="false*">	+	<doodle title="Add required mb_() functions to fix vulnerability" auth="yohgaki" voteType="single" closed="true*">
	* Yes		* Yes
	* No		* No

rfc:multiple-catch

2016-05-02T01:22:47+02:00

1462140769		current
Line 3:		Line 3:
	* Date: 2016-03-06		* Date: 2016-03-06
	* Author: Pierrick Charron <pierrick@php.net>, Bronisław Białek <after89@gmail.com>		* Author: Pierrick Charron <pierrick@php.net>, Bronisław Białek <after89@gmail.com>
-	* Status: Approved	+	* Status: Implemented (PHP 7.1)
	* First Published at: http://wiki.php.net/rfc/multiple-catch		* First Published at: http://wiki.php.net/rfc/multiple-catch

Line 90:		Line 90:

	Patch : [[https://github.com/php/php-src/pull/1796/files]]		Patch : [[https://github.com/php/php-src/pull/1796/files]]
		+
		+	===== Implementation =====
		+
		+	Merged into php-src for PHP 7.1: https://github.com/php/php-src/commit/0aed2cc2a440e7be17552cc669d71fdd24d1204a

rfc:my_rfc

2015-01-31T01:59:38+02:00

1422665622		current
Line 9:		Line 9:

	There are number of INI set/get functions. This RFC proposes deprecation of these functions.		There are number of INI set/get functions. This RFC proposes deprecation of these functions.
		+
		+	Use of ini_set()/ini_get() simplifies/improves/cleanups PHP. Some of these alias function names is inconsistent, some aliases are missing while similar INI setting may be set/get by aliases. Simple INI set/get alias functions are just making PHP complex, creating more inconsistencies. PHP needs no more INI set/get aliases at least, document use of ini_get()/ini_set() in the CODING_STANDARDS.
		+

	Pros		Pros
Line 35:		Line 38:
	ini_set('display_errors', 'Off');		ini_set('display_errors', 'Off');
	ini_set('default_charset', 'UTF-8');		ini_set('default_charset', 'UTF-8');
-	mbstring_internal_encoding('UTF-8');	+	mb_internal_encoding('UTF-8');
	</code>		</code>

Line 68:		Line 71:
	===== Proposal =====		===== Proposal =====

-	Use of ini_set()/ini_get() simplifies/improves PHP. PHP needs no more INI set/get aliases at least, document use of ini_get()/ini_set() in the CODING_STANDARDS.	+	There are 2 documentation and 1 code change proposal.

	1. Add plain ini_get/set() usage in CODING_STANDARDS. In the "Code Implementation" session add following standard.		1. Add plain ini_get/set() usage in CODING_STANDARDS. In the "Code Implementation" session add following standard.

rfc:mysql_deprecation

2012-12-10T16:28:07+02:00

1354860472		current
Line 1:		Line 1:
	====== Request for Comments: ext/mysql deprecation ======		====== Request for Comments: ext/mysql deprecation ======
-	* Version: 1.2	+	* Version: 1.2.1
-	* Date: 2012-11-28	+	* Date: 2012-12-10
	* Author: Adam Harvey <aharvey@php.net>		* Author: Adam Harvey <aharvey@php.net>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.5
	* First Published at: https://wiki.php.net/rfc/mysql_deprecation		* First Published at: https://wiki.php.net/rfc/mysql_deprecation
	* Trivial patch: http://files.adamharvey.name/mysql-deprecation.patch		* Trivial patch: http://files.adamharvey.name/mysql-deprecation.patch
Line 164:		Line 164:
	===== Changelog =====		===== Changelog =====

		+	* 1.2.1 (2012-12-10): Update status to Implemented.
	* 1.2 (2012-12-07): Close voting; attempt to summarise the arguments on Internals into a few paragraphs; add links to the discussions for avid readers.		* 1.2 (2012-12-07): Close voting; attempt to summarise the arguments on Internals into a few paragraphs; add links to the discussions for avid readers.
	* 1.1.2 (2012-11-28): Replace the Oracle Wiki link with a link to Ulf's new blog post; moved to voting phase.		* 1.1.2 (2012-11-28): Replace the Oracle Wiki link with a link to Ulf's new blog post; moved to voting phase.

rfc:mysqlnd_localhost_override

2013-02-12T16:25:51+02:00

1360668812		current
Line 1:		Line 1:
	====== Add mysqlnd.localhost_override option ======		====== Add mysqlnd.localhost_override option ======
-	* Version: 0.1	+	* Version: 0.2
	* Date: 2013-02-12		* Date: 2013-02-12
	* Author: Asbjørn Sannes <asbjorn.sannes.at.interhost.no>		* Author: Asbjørn Sannes <asbjorn.sannes.at.interhost.no>
-	* Status: In Draft	+	* Status: Widthdrawn
	* First Published at: https://wiki.php.net/rfc/mysqlnd_localhost_override		* First Published at: https://wiki.php.net/rfc/mysqlnd_localhost_override

		+	===== Withdrawn =====
		+
		+	There are methods to work around this:
		+
		+	* write a mysqlnd plugin (Johannes Schlüter)
		+	* PDO already support DSN-alias, php.net/pdo.configuration#ini.pdo.dsn (Sebastian Krebs)

	===== Introduction =====		===== Introduction =====
Line 38:		Line 44:

	0.1 Initial draft		0.1 Initial draft
		+	0.2 Withdrawn

rfc:named_params

2014-05-22T18:01:54+02:00

1378740223		current
Line 8:		Line 8:
	===== State of this RFC =====		===== State of this RFC =====

-	This is a preliminary RFC for named parameters. It's purpose is to find out if we want to support them in the next PHP version and if so, how the implementation should work. The syntax and behavior described here are just basic ideas that still need to be fleshed out.	+	This is a preliminary RFC for named parameters. It's purpose is to find out if we want to support them in the next PHP version and if so, how the implementation should work. The syntax and behavior described here are not final and still need to be fleshed out.

	The implementation that accompanies this proposal is not complete yet. As this is a very complicated feature I do not wish to spend time finishing it without knowing that we actually want this feature.		The implementation that accompanies this proposal is not complete yet. As this is a very complicated feature I do not wish to spend time finishing it without knowing that we actually want this feature.

-	The implementation is based off and includes the [[rfc:variadics]] and [[rfc:argument_unpacking]] RFCs. I think they are essential if we implement named params (otherwise we couldn't have good error handling for unknown named params and no unpacking support at all, unless we break BC in ''call_user_func_array''). The choice of how they should be implemented somewhat depends on whether we want to support named params, so I'm doing this proposal first.	+	Update 22-05-2014: I'm currently not working on this RFC, because other things are keeping me busy. However this RFC will be resurrected in time for PHP 6. Until then, I'd like to summarize some of the results from [[http://markmail.org/message/yhtrefvpsndqfm34\|the discussion]] regarding the open questions listed below:
		+
		+	* There is still no consensus on the syntax.
		+	* Named argument unpacking and collection of undefined named arguments will integrate with the ''%%...%%'' syntax. As the unpacking and variadics RFCs have already landed there no longer is much choice in this area.
		+	* Parameter names during inheritance will not be enforced by our LSP checks. It was decided that this would be too large of a BC break.
		+
		+	The main open implementational issues are listed in the "Patch" section.

	===== What are named arguments? =====		===== What are named arguments? =====

rfc:namedparameters

2013-09-09T17:32:10+02:00

1334376023		current
Line 1:		Line 1:
-	====== Request for Comments: Named Parameters ======	+	====== Request for Comments: Named Parameters (obsolete) ======
	* Version: 0.1		* Version: 0.1
	* Date: 2012-04-13		* Date: 2012-04-13
	* Author: Needs an owner & champion else this project will not be considered		* Author: Needs an owner & champion else this project will not be considered
	* Status: Draft - no content except a very old decision on the topic		* Status: Draft - no content except a very old decision on the topic
-	* First Published at: https://wiki.php.net/rfc/namedparameters	+	* Superseded by: [[rfc:named_params\|Named Parameters RFC]]

		+	===== Introduction =====

-		+	Note: This RFC has been superseded by another [[rfc:named_params\|Named Parameters RFC]].
-	===== Introduction =====	+

	This document is a placeholder for a future RFC on implementing Named Parameters. This project needs an owner.		This document is a placeholder for a future RFC on implementing Named Parameters. This project needs an owner.

rfc:namespace-importing-with-from

2012-09-11T19:43:57+02:00

1343192795		current
Line 1:		Line 1:
-	====== Request for Comments: Enhance Namespace Importing With From Syntax ======	+	====== Request for Comments: Enhance Namespace Batch Importing Syntax ======
	* Version: 1.0		* Version: 1.0
	* Date: 2012-07-24		* Date: 2012-07-24
-	* Author: Reeze Xia <reeze.xia@gmail.com>	+	* Author: Reeze Xia <reeze@php.net>
	* Status: Under Discussion		* Status: Under Discussion
	* First Published at: https://wiki.php.net/rfc/namespace-importing-with-from		* First Published at: https://wiki.php.net/rfc/namespace-importing-with-from

rfc:namespacecurlies

2011-04-06T12:59:26+02:00

1220189878		current
Line 44:		Line 44:
	- With the new implementation and no blocks, many people expected one namespace per file.		- With the new implementation and no blocks, many people expected one namespace per file.
	- Since fewer files means faster execution, many people simply concatenate PHP scripts. Their expectation is to be able to do this for code that uses namespaces as well.		- Since fewer files means faster execution, many people simply concatenate PHP scripts. Their expectation is to be able to do this for code that uses namespaces as well.
-	- PHP will add [[php.net/phar\|Phar archive]] support and thus does not really require source concatenation any longer.	+	- PHP will add [[http://php.net/phar\|Phar archive]] support and thus does not really require source concatenation any longer.

	* Consistency:		* Consistency:

rfc:namespaceissues

2011-04-06T12:59:26+02:00

1224164718		current
Line 189:		Line 189:
	This will be better for 99% of scripts, as evidenced by the ratio of internal vs. userspace classes (see http://marc.info/?l=php-internals&m=122127176407546&w=2 for detail)		This will be better for 99% of scripts, as evidenced by the ratio of internal vs. userspace classes (see http://marc.info/?l=php-internals&m=122127176407546&w=2 for detail)

-	==== Why Stas's proposed solution doesn't work ====	+	===== Why Stas's proposed solution doesn't work =====

	[[rfc:namespaceref#namespaces_with_functionsconstants\|Stas's proposed solution]] suggests:		[[rfc:namespaceref#namespaces_with_functionsconstants\|Stas's proposed solution]] suggests:

rfc:namespaceref

2011-04-06T12:59:26+02:00

1224019280		current
Line 64:		Line 64:
	* The model is more complex and may be confusing for the new users.		* The model is more complex and may be confusing for the new users.
	* Unqualified name resolutions for classes and functions/constants are slightly different due to the different usage patterns.		* Unqualified name resolutions for classes and functions/constants are slightly different due to the different usage patterns.
		+	* New syntax for static access

	===== See also =====		===== See also =====

rfc:namespaceresolution

2013-10-29T18:40:19+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2008-10-30		* Date: 2008-10-30
	* Author: Lukas Smith <smith@pooteeweet.org>		* Author: Lukas Smith <smith@pooteeweet.org>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.3 (with fallback to global for functions/constants)
	* First Published at: http://wiki.php.net/rfc/namespaceresolution		* First Published at: http://wiki.php.net/rfc/namespaceresolution

rfc:namespaces-for-internal-classes

2013-02-21T04:08:14+02:00

1302087566		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: Namespaces for internal classes ======
	* Version: 0.1		* Version: 0.1
	* Date: 2008-03-06		* Date: 2008-03-06

rfc:namespaces

2011-04-06T12:59:26+02:00

1221524689		current
Line 108:		Line 108:
	<code>		<code>
	defined('DEBUG'): YES (expect YES)		defined('DEBUG'): YES (expect YES)
-	defined('my::test::ns::DEBUG_2'): NO (expect YES)	+	defined('MY::TEST::NS::DEBUG_2'): NO (expect YES)
	defined('my::test::ns::DEBUG_2'): NO (expect NO)		defined('my::test::ns::DEBUG_2'): NO (expect NO)
	defined('my::test::ns::debug_2'): NO (expect NO)		defined('my::test::ns::debug_2'): NO (expect NO)

rfc:namespaces_encapsulation

2012-08-23T21:54:42+02:00

1345749413		current
Line 4:		Line 4:
	* Author: Yahav Gindi Bar <g.b.yahav@gmail.com>		* Author: Yahav Gindi Bar <g.b.yahav@gmail.com>
	* Status: Under Discussion		* Status: Under Discussion
-	* First Published at: http://wiki.php.net/rfc/traits	+	* First Published at: https://wiki.php.net/rfc/namespaces_encapsulation
-	* Other formats ..	+
-		+
-		+
-	This RFC is a template other people can use to write their own RFCs.	+

	===== Introduction =====		===== Introduction =====
Line 14:		Line 10:
	This RFC introduce and suggest adding encapsulation abilities into classes.		This RFC introduce and suggest adding encapsulation abilities into classes.
	Today, namespaces is a tool used to avoid conflicts with other classes and help improve performance. However, with encapsulation abilities to classes, namespaces can be even better.		Today, namespaces is a tool used to avoid conflicts with other classes and help improve performance. However, with encapsulation abilities to classes, namespaces can be even better.
		+
		+	==== Why do we need classes encapsulation? ====

	Today, when one declare few classes, all of them can be accessed and initialized (though you can disable it using private constructor, which is a different story). from any scope - the global scope and namespace specific.		Today, when one declare few classes, all of them can be accessed and initialized (though you can disable it using private constructor, which is a different story). from any scope - the global scope and namespace specific.

-	There are cases which programmer wish, just like when using private class members, to encapsulate and make some classes available only from the namespace it was created in.	+	There are cases which programmer wish, just like when using private class members, to encapsulate and make some of his or her classes available only from the namespace it was created in. This most likely occur when developing a modular site, when one tries to make his or her work simpler for the consumer or end-developer.

-	==== Why do we need RFCs? ====	+	===== Use cases =====

-	They serve to keep a summary of on going discussions. This way people can keep an overview of the state of the discussion. Even if never put into place in the end, they also serve as a historical log of discussions that is much easier to read compared to mailinglist threads.	+	<code php>

-	===== Common Misconceptions =====	+	namespace \Foo;

-	RFCs do not in any way replace discussions on the mailing list.	+	public class Config {
		+	public function getOption($key) { ... }
		+	}
		+
		+	internal abstract class ConfigAdapter {
		+	public abstract function getValue($key);
		+	}
		+
		+	internal class IniConfigAdapter extends ConfigAdapter {
		+	public function getValue($key) { ... }
		+	}
		+
		+	internal class XmlConfigAdapter extends ConfigAdapter {
		+	public function getValue($key) { ... }
		+	}
		+
		+	internal class YamlConfigAdapter extends ConfigAdapter {
		+	public function getValue($key) { ... }
		+	}
		+
		+	</code>
		+
		+	Using the example above, one can encapsulate the many config adapters and use the ''Config'' class in order to retrieve the value requested from the user using the requested adapter.
		+
		+	===== Specification =====
		+
		+	The encapsulation will take place at the class deceleration, by the ability to add the keyword ''internal'' before the class declaration.
		+
		+	===== Optional features =====
		+
		+	==== Prefix classes with the ''public'' keyword (Vote separately): ====
		+	Even though any class which not declared as internal will be public and available, some developers may wish to prefix their classes with public as well.
		+
		+	For example:
		+	<code php>
		+	namespace \Foo;
		+
		+	public class Foo {
		+	public function getBar() {
		+	return (new Bar())->getBar();
		+	}
		+	}
		+
		+	internal class Bar {
		+	public function getBar() {
		+	return "bar";
		+	}
		+	}
		+
		+	</code>

	===== Proposal and Patch =====		===== Proposal and Patch =====

-	Nothing needs to be patched here. Just use this template at your discretion.	+	The patch for this proposal is not written yet.

-	==== Rejected Features ====	+	===== TODO =====

-	Automated voting system.	+	* Decide whether to use a new keyword - ''internal'', or use the ''private'' keyword.

-	==== More about RFCs ====	+	===== Further resources =====

-	http://en.wikipedia.org/wiki/Request_for_Comments	+	Implementation in C#:

-	===== Changelog =====	+	* http://msdn.microsoft.com/en-us/library/7c5ka91b%28v=vs.80%29.aspx

		+	Implementation in Java:

		+	* http://docs.oracle.com/javase/tutorial/java/javaOO/innerclasses.html

		+	===== Changelog =====

rfc:namespaceseparator

2013-10-29T18:39:36+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2008-10-25		* Date: 2008-10-25
	* Author: Lukas Smith <smith@pooteeweet.org>		* Author: Lukas Smith <smith@pooteeweet.org>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.3 (with ''\'' separator)
	* First Published at: http://wiki.php.net/rfc/namespaceseparator		* First Published at: http://wiki.php.net/rfc/namespaceseparator

rfc:native-tls

2014-12-17T21:06:39+02:00

1418238086		current
Line 3:		Line 3:
	* Date: 2014-11-19		* Date: 2014-11-19
	* Author: Anatol Belski, ab@php.net		* Author: Anatol Belski, ab@php.net
-	* Status: Voting	+	* Status: Accepted

	===== Introduction =====		===== Introduction =====
Line 70:		Line 70:

	===== Vote =====		===== Vote =====
-	<doodle title="Native TLS" auth="ab" voteType="single" closed="false">	+	<doodle title="Native TLS" auth="ab" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:native_regular_expressions

2014-08-22T03:38:12+02:00

1408109679		current
Line 1:		Line 1:
	====== PHP RFC: Native Regular Expression ======		====== PHP RFC: Native Regular Expression ======
-	* Version: 0.1
	* Date: 2014-08-13		* Date: 2014-08-13
	* Author: Bishop Bettini, bishop@php.net		* Author: Bishop Bettini, bishop@php.net
	* Status: Draft		* Status: Draft
-	* First Published at: http://wiki.php.net/rfc/native_regular_expressions

	FIXME FIXME FIXME		FIXME FIXME FIXME
	Jotting my ideas down here. Move along. Maybe called "first_class_citizens_regex" or something.		Jotting my ideas down here. Move along. Maybe called "first_class_citizens_regex" or something.
		+	Consider emulating structure of https://wiki.php.net/rfc/abstract_syntax_tree
		+	https://wiki.php.net/rfc/generators
		+
		+
		+	===== Introduction =====
		+
		+	Regular expressions provide powerful string matching capabilities and play a critical role in most software written in PHP. For example, Github reports [[https://github.com/search?q=language%3Aphp+preg_filter+OR+preg_grep+OR+preg_match+OR+preg_match_all+OR+preg_replace+OR+preg_split&type=Code\|10.5 million instances of the ''preg_*()'' family of functions]]((Compared with [[https://github.com/search?q=language%3Aphp+str_replace+OR+explode+OR+strpos&type=Code\|16 million instances]] of the ''explode()'', ''strpos()'', and ''str_replace()'' related functions.))((This RFC does not consider the deprecated POSIX regular expressions to be an active part of PHP and any implementation of this RFC will focus solely upon PCRE regular expressions.)).
		+
		+	In the current engine, regular expressions are plain old strings:
		+
		+	<code php>
		+	while (preg_match('/^\s*[^#]/', $line[$i++])) {}
		+	</code>
		+
		+	The primary disadvantage with string representation comes when the regular expression itself needs to contain a single quote, double quote, or the delimiters bracketing the regular expression. When that happens, the programmer has to make mental shifts to workaround the string representation, sometimes making the regular expression harder to read and maintain. Example:
		+
		+	<code php>
		+	// match foo in examples: ="foo" and ='foo' and = "foo"
		+	preg_match_all('(=\s['."'".'"]([^'."'".'"/])['."'".'"])x', $string, $matches);
		+	</code>((PCRE wizards might rightly scold me for using that example, as it doesn't actually work as described for unbalanced quotation marks or escaped quotation marks, and that a realistic working example would be ''(["'])(?:\\?+.)*?\1'', thus needing only one single quote escaped. I agree, but I generated this example to illustrate a point.))
		+
		+	In some other languages, regular expressions are part of the language itself.
		+
		+
		+
		+
		+	Another problem with regular expressions buried in plain old strings is that syntax highlighting becomes much more difficult.
		+
		+
		+	<code php>
		+	function getLinesFromFile($fileName) {
		+	if (!$fileHandle = fopen($fileName, 'r')) {
		+	return;
		+	}
		+
		+	while (false !== $line = fgets($fileHandle)) {
		+	yield $line;
		+	}
		+
		+	fclose($fileHandle);
		+	}
		+
		+	$lines = getLinesFromFile($fileName);
		+	foreach ($lines as $line) {
		+	// do something with $line
		+	}
		+	</code>
		+
		+	The code looks very similar to the array-based implementation. The main difference is that instead of pushing
		+	values into an array the values are ''yield''ed.
		+
		+	Generators work by passing control back and forth between the generator and the calling code:
		+
		+	When you first call the generator function (''$lines = getLinesFromFile($fileName)'') the passed argument is bound,
		+	but nothing of the code is actually executed. Instead the function directly returns a ''Generator'' object. That
		+	''Generator'' object implements the ''Iterator'' interface and is what is eventually traversed by the ''foreach''
		+	loop:
		+
		+	Whenever the ''Iterator::next()'' method is called PHP resumes the execution of the generator function until it
		+	hits a ''yield'' expression. The value of that ''yield'' expression is what ''Iterator::current()'' then returns.
		+
		+	Generator methods, together with the ''IteratorAggregate'' interface, can be used to easily implement traversable
		+	classes too:
		+
		+	<code php>
		+	class Test implements IteratorAggregate {
		+	protected $data;
		+
		+	public function __construct(array $data) {
		+	$this->data = $data;
		+	}
		+
		+	public function getIterator() {
		+	foreach ($this->data as $key => $value) {
		+	yield $key => $value;
		+	}
		+	// or whatever other traversation logic the class has
		+	}
		+	}
		+
		+	$test = new Test(['foo' => 'bar', 'bar' => 'foo']);
		+	foreach ($test as $k => $v) {
		+	echo $k, ' => ', $v, "\n";
		+	}
		+	</code>
		+
		+	Generators can also be used the other way around, i.e. instead of producing values they can also consume them. When
		+	used in this way they are often referred to as enhanced generators, reverse generators or coroutines.
		+
		+	Coroutines are a rather advanced concept, so it very hard to come up with not too contrived an short examples.
		+	For an introduction see an example [[https://gist.github.com/3111288\|on how to parse streaming XML using coroutines]].
		+	If you want to know more, I highly recommend checking out [[http://www.dabeaz.com/coroutines/Coroutines.pdf\|a presentation
		+	on this subject]].
		+
		+
		+
		+
		+

	New built-in "re". BNF is roughly:		New built-in "re". BNF is roughly:

rfc:negative-index-support

2012-08-30T20:16:56+02:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Negative index support ======
	+	* Version: 0.1
	+	* Date: 2012-08-30
	+	* Author: Marc Easen <marc@easen.co.uk>
	+	* Status: In Draft
	+	* First Published at: https://wiki.php.net/rfc/negative-index-support

	+	===== Introduction =====
	+
	+	The purpose this RFC using negative offsets is to extend the current positive indices support for strings and arrays to allow negative values.
	+
	+	===== Examples ======
	+	Without the support of negative indices to find the character 'd' in 'Hello World' can be done in using various ways
	+
	+	<code php>
	+	$string = 'Hello World';
	+
	+	// using substr
	+	$letter_d = substr($string, strlen($string) -1);
	+
	+	// using a positive index value
	+	$letter_d = $string[strlen($string) -1];
	+	</code>
	+
	+	Using the same example but using a negative index would be
	+
	+	<code php>
	+	$string = 'Hello World';
	+
	+	$letter_d = $string[-1];
	+	</code>
	+
	+	The same could be applied to arrays that are not keyed
	+
	+	<code php>
	+	$array = array(1001, 1002, 1003, 1004);
	+
	+	// using a positive index value
	+	$number_1004 = $array[count($array) -1];
	+
	+	// or using array_slice
	+	$number_1004 = array_slice($array, -1, 1)[0];
	+	</code>
	+
	+	Using a negative index
	+
	+	<code php>
	+	$array = array(1001, 1002, 1003, 1004);
	+
	+	$number_1004 = $array[-1];
	+	</code>
	+
	+	===== What about associated arrays? =====
	+
	+	No change. As associated arrays can have numerical keys.
	+
	+	===== Out of bound negative indices =====
	+
	+	Same notice to be shown as the current out of bound for positive indices that have exceed the length of the string/array.
	+
	+	===== Patch =====
	+
	+	https://github.com/Easen/php-src/tree/negative-string-offset
	+
	+	===== Changelog =====
	+
	+	* 2012-08-30 - Initial RFC

rfc:negative-string-offsets

2016-03-10T13:07:38+02:00

1457346930		current
Line 3:		Line 3:
	* Date: 2016-02-18		* Date: 2016-02-18
	* Author: François Laupretre <francois@php.net>		* Author: François Laupretre <francois@php.net>
-	* Status: Approved	+	* Status: Implemented (in PHP 7.1)
	* First Published at: http://wiki.php.net/rfc/negative-string-offsets		* First Published at: http://wiki.php.net/rfc/negative-string-offsets

rfc:nested_classes

2013-10-13T20:59:22+02:00

1380705335		current
Line 4:		Line 4:
	* Date: 2013-09-29		* Date: 2013-09-29
	* Author: Joe Watkins, krakjoe@php.net		* Author: Joe Watkins, krakjoe@php.net
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/nested_classes		* First Published at: http://wiki.php.net/rfc/nested_classes

rfc:new-curl-error-functions

2016-06-26T19:46:23+02:00

1466800345		current
Line 3:		Line 3:
	* Date: 2016-04-29		* Date: 2016-04-29
	* Author: Pierrick Charron <pierrick@php.net>		* Author: Pierrick Charron <pierrick@php.net>
-	* Status: Accepted	+	* Status: Implemented (PHP 7.1)
	* First Published at: https://wiki.php.net/rfc/new-curl-error-functions		* First Published at: https://wiki.php.net/rfc/new-curl-error-functions

Line 54:		Line 54:

	Patch : [[https://github.com/php/php-src/pull/1896]]		Patch : [[https://github.com/php/php-src/pull/1896]]
		+
		+	===== Implementation =====
		+
		+	Merged into php-src for PHP 7.1: https://github.com/php/php-src/commit/3d71c1de7af6f41653addb7bb75dd37adc4e87b0

rfc:new-output-api

2013-10-29T18:29:02+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2010-04-07		* Date: 2010-04-07
	* Author: Michael Wallner <mike@php.net>		* Author: Michael Wallner <mike@php.net>
-	* Status: old hat	+	* Status: Implemented in PHP 5.4
	* First Published at: http://marc.info/?l=php-internals&m=114210732600710&w=2 etc.pp.		* First Published at: http://marc.info/?l=php-internals&m=114210732600710&w=2 etc.pp.

rfc:newinis

2013-10-29T18:31:51+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2009-02-22		* Date: 2009-02-22
	* Author: Eric Lee Stewart <ericleestewart.at.gmail.com>		* Author: Eric Lee Stewart <ericleestewart.at.gmail.com>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.3
	* First Published at: http://wiki.php.net/rfc/newinis		* First Published at: http://wiki.php.net/rfc/newinis

rfc:nikita_popov

2016-03-30T00:28:21+02:00

1459271281		current
Line 7:		Line 7:

	===== Introduction =====		===== Introduction =====
-	Modern PHP is a manifestation of the best parts of the consciousness of it's contributors.	+	Modern PHP is a manifestation of the best parts of the consciousness of its contributors.

	That totally blew your mind, right ?		That totally blew your mind, right ?

	===== Proposal =====		===== Proposal =====
-	We propose that, after a minimum of 42 lines of any contributors code is merged into PHP, they should become eligible to have their consciousness merged into the core, in it's entirety.	+	We propose that, after a minimum of 42 lines of any contributors code is merged into PHP, they should become eligible to have their consciousness merged into the core, in its entirety.

	We further propose that after an arbitrary and as yet undecided upper limit, merging consciousness with the core becomes mandatory.		We further propose that after an arbitrary and as yet undecided upper limit, merging consciousness with the core becomes mandatory.
Line 29:		Line 29:

	==== To Opcache ====		==== To Opcache ====
-	Opcache will be provided with it's own unicorn.	+	Opcache will be provided with its own unicorn.

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

rfc:nonbreakabletraits

2011-04-06T12:59:26+02:00

1205446171		current
Line 21:		Line 21:
	- Making an //alias// of the property or method and use either scope.		- Making an //alias// of the property or method and use either scope.
	- //Merging// multiple properties or methods in the class scope.		- //Merging// multiple properties or methods in the class scope.
		+

	===== Keywords Used In Sample Code =====		===== Keywords Used In Sample Code =====
Line 26:		Line 27:
	For all of the code examples, the following keywords were used:		For all of the code examples, the following keywords were used:

-	''trait''	+	''trait'': This keyword is used to mark a trait definition exactly as the ''class'' keyword works for classes.
-	This keyword is used to mark a trait definition exactly as the ''class''	+
-	keyword works for classes.	+	''class'': Same as current PHP keyword.
-	''class''	+
-	Same as current PHP keyword.	+	''include'': Used to include a trait into a class definition
-	''include''	+
-	Used to include a trait into a class definition	+	''private'': This keyword is used in its current PHP sense as well as to mean that a property or method is to retain its //local// trait scope.
-	''private''	+
-	This keyword is used in its current PHP sense as well as to mean that	+	''public'': This keyword is used in its current PHP sense as well as to mean that a property or method is to be used within the scope of the including class.
-	a property or method is to retain its //local// trait scope.	+
-	''public''	+	''as'': Used to //alias// or //merge// a trait into a class.
-	This keyword is used in its current PHP sense as well as to mean that	+
-	a property or method is to be used within the scope of the including	+
-	class.	+
-	''as''	+
-	Used to //alias// or //merge// a trait into a class.	+

rfc:nophptags

2014-02-12T07:49:42+02:00

1392187693		current
Line 112:		Line 112:
	* [[http://packetstormsecurity.com/files/120921/AContent-1.3-Local-File-Inclusion.html\|AContent 1.3 Local File Inclusion]]		* [[http://packetstormsecurity.com/files/120921/AContent-1.3-Local-File-Inclusion.html\|AContent 1.3 Local File Inclusion]]
	* [[http://packetstormsecurity.com/files/121347/Fork-CMS-Local-File-Inclusion.html\|Fork CMS Local File Inclusion]]		* [[http://packetstormsecurity.com/files/121347/Fork-CMS-Local-File-Inclusion.html\|Fork CMS Local File Inclusion]]
-	*and many more.	+	and [[http://packetstormsecurity.com/search/?q=LFI\|*many more]].
	* [[nophptags#why_this_is_better_than_now\|Why this is better than now]]		* [[nophptags#why_this_is_better_than_now\|Why this is better than now]]
	* Transition is very easy, compatible for both forward/backward not like the related RFC.		* Transition is very easy, compatible for both forward/backward not like the related RFC.

rfc:normalize_inc_dec

2014-09-21T08:44:00+02:00

1411281780		current
Line 33:		Line 33:
	The proposal is:		The proposal is:
	- always treat boolean and null types as an integer, but raise a warning.		- always treat boolean and null types as an integer, but raise a warning.
-	- deprecate alphanumeric increment and introduce "str_inc()" and "str_dec()".	+	- deprecate alphanumeric increment and introduce ''str_inc()'' and ''str_dec()''.

	==== Operation on bool / null ====		==== Operation on bool / null ====
Line 67:		Line 67:
	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====

-	Incrementing <code>null</code> will now raise a warning; incrementing alphanumeric strings will raise a deprecation notice.	+	Incrementing ''null'' will now raise a warning; incrementing alphanumeric strings will raise a deprecation notice.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====

rfc:notice-for-non-valid-array-container

2016-08-16T19:20:10+02:00

1471367809		current
Line 94:		Line 94:
	</doodle>		</doodle>
	Vote Start: 2016-08-16 15:36		Vote Start: 2016-08-16 15:36
		+
	Vote End: 2016-08-23 23:59		Vote End: 2016-08-23 23:59

rfc:null_coalesce_equal_operator

2016-04-02T18:28:47+02:00

1459369541		current
Line 3:		Line 3:
	* Date: 2016-03-09		* Date: 2016-03-09
	* Author: Midori Kocak, mtkocak@gmail.com		* Author: Midori Kocak, mtkocak@gmail.com
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/null_coalesce_equal_operator		* First Published at: http://wiki.php.net/rfc/null_coalesce_equal_operator

Line 38:		Line 38:
	Voting started at 2016/03/24 16:08 and will be closed at 2016/04/02.		Voting started at 2016/03/24 16:08 and will be closed at 2016/04/02.

-	<doodle title="Approve Equal Null Coalesce Operator RFC and merge patch into master?" auth="midorkocak" voteType="single" closed="false">	+	<doodle title="Approve Equal Null Coalesce Operator RFC and merge patch into master?" auth="midorkocak" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:nullable_return_types

2016-05-05T22:23:57+02:00

1460021916		current
Line 58:		Line 58:
	</code>		</code>

-	==== Nullable Arguemnts without Default Values ====	+	==== Nullable Arguments without Default Values ====

	Usage of the same ?<type> syntax for arguments (and later properties) is not the primary goal of this RFC, because arguments already may be declared as "nullable", using NULL default value (the same may be done for properties). It's also possible to add the same syntax for arguments as it was proposed in [[https://wiki.php.net/rfc/nullable_types\|"Declaring Nullable Types" RFC]]		Usage of the same ?<type> syntax for arguments (and later properties) is not the primary goal of this RFC, because arguments already may be declared as "nullable", using NULL default value (the same may be done for properties). It's also possible to add the same syntax for arguments as it was proposed in [[https://wiki.php.net/rfc/nullable_types\|"Declaring Nullable Types" RFC]]

rfc:nullable_returns

2016-04-14T17:38:17+02:00

1460646350		current
Line 36:		Line 36:
	===== Note to the reader =====		===== Note to the reader =====

-	The following arguments are based on opinion, experience and conversations. I tried to emphasize this by using first person singual when arguing my opinions and first person plural when referring to experience and opinion shared with my colleages. "We" specifically is not the journalistic "we" that refers to broader populations—it literally mean me and others I know and work with.	+	The following arguments are based on opinion, experience and conversations. I tried to emphasize this by using first person singular when arguing my opinions and first person plural when referring to experience and opinion shared with my colleages. "We" specifically is not the journalistic "we" that refers to broader populations—it literally mean me and others I know and work with.

rfc:nullable_typehints

2015-01-14T01:34:43+02:00

1413390001		current
Line 1:		Line 1:
-	====== PHP RFC: Declaring Nullable Types ======	+	This RFC has moved to [[https://wiki.php.net/rfc/nullable_types]].
-	* Version: 0.1	+
-	* Date: 2014-04-10	+
-	* Author: Levi Morrison <levim@php.net>	+
-	* Status: Draft	+
-	* First Published at: https://wiki.php.net/rfc/nullable_typehints	+
-		+
-	===== Introduction =====	+
-	This RFC proposes new syntax to allow type declarations to also accept <php>null</php> without a default value; it also outlines how it will work in return types if that RFC is accepted.	+
-		+
-	Consider the function:	+
-		+
-	<PHP>	+
-	function foo(DateTime $time, $a) {}	+
-	</PHP>	+
-		+
-	In this situation you are not allowed to pass <php>null</php> for the<php>$time</php> parameter; this proposal allows you do pass <php>null</php> without using a default (''= null'').	+
-		+
-	===== Proposal =====	+
-	This proposal adds a marker ''?'' to indicate that a type can also be <php>null</php>. This is allowed for any declared type including <php>array</php> and <php>callable</php>.	+
-		+
-	The ''?'' marker can be placed on any parameter position, provided it does not violate inheritance rules:	+
-	<PHP>	+
-	function f(?callable $p, $a) {} // valid	+
-	</PHP>	+
-		+
-	Note that nullable parameters are required; you cannot omit the parameter like you can with a default parameter.	+
-		+
-	==== Position of ? ====	+
-	The ''?'' marker goes before the type, as in ''?Foo''. If the ''?'' came after the type, as in ''Foo?'', then we'd have an issue if we ever supported generics; ''<Foo?>'' would conflict with a closing ''?>''. Putting it before the type does not have a conflict (''<?Foo'') because at that moment we are already inside of a ''<?php'' declaration.	+
-		+
-	==== Inheritance in Parameters ====	+
-	The ''?'' marker cannot be removed in a sub-class; it can be added if not present in a super-class. This behavior is consistent with the Liskov substitution principle.	+
-		+
-	<PHP>	+
-	// Valid use: loosening the nullable marker in a parameter:	+
-	interface Fooable {	+
-	function foo(Fooable $f);	+
-	}	+
-	interface LooseFoo extends Fooable {	+
-	function foo(?Fooable $f);	+
-	}	+
-	</PHP>	+
-		+
-	<PHP>	+
-	// Invalid use: tightening the nullable marker in a parameter:	+
-	interface Fooable {	+
-	function foo(?Fooable $f);	+
-	}	+
-	interface StrictFoo extends Fooable {	+
-	function foo(Fooable $f);	+
-	}	+
-	</PHP>	+
-		+
-	==== Default Parameters and Nullable Types are not interchangeable ===	+
-	A default parameter and a nullable type are distinct and separate; you cannot use a default parameter where a nullable type existed in a parent; you cannot use a nullable type where a default parameter existed in a parent.	+
-		+
-	==== Return Types ====	+
-	If the [[rfc:returntypehinting\|RFC for Declaring Return Types]] passes, then nullable types would be extended to return types as well; this is a major motivator for introducing this new syntax as return types cannot specify a null default to get around the type check.	+
-		+
-	Here's an example of a binary tree that uses the nullable marker for both parameter and return types:	+
-		+
-	<PHP>	+
-	// Possible usage of ? modifier for both parameters and return types	+
-	class BinaryTree {	+
-	public $value;	+
-	private $right;	+
-	private $left;	+
-		+
-	function right(): ?BinaryTree {	+
-	return $this->right;	+
-	}	+
-	function left(): ?BinaryTree {	+
-	return $this->left;	+
-	}	+
-		+
-	function setRight(?BinaryTree $t) {	+
-	$this->right = $t;	+
-	}	+
-	function setLeft(?BinaryTree $t) {	+
-	$this->left = $t;	+
-	}	+
-	}	+
-	</PHP>	+
-		+
-	It does not make sense to call ''setLeft'' without a parameter: <php>$btree->setLeft();</php> what are you setting the left equal to? In this case the nullable type better reflects the ability to accept ''BinaryTree'' or ''null'' than a default parameter of ''null'' does.	+
-		+
-	=== Inheritance in Return Types ===	+
-		+
-	The nullable marker in return types behaves differently during inheritance than a parameter type does. In a return type, the null marker can be removed by a subclass, but it cannot be added:	+
-	<PHP>	+
-	interface Fooable {	+
-	function foo(): ?Fooable;	+
-	}	+
-	interface StrictFooable extends Fooable {	+
-	function foo(): Fooable; // valid	+
-	}	+
-	</PHP>	+
-	<PHP>	+
-	interface Fooable {	+
-	function foo(): Fooable;	+
-	}	+
-	interface LooseFooable extends Fooable {	+
-	function foo(): ?Fooable; // invalid	+
-	}	+
-	</PHP>	+
-		+
-	==== Differences from Default Parameters ====	+
-	The null marker does not have a default; it does not default to <php>null</php>. The following snippet would result in an error:	+
-	<PHP>	+
-	function f(?callable $p) {}	+
-	f(); // invalid; function f does not have a default	+
-	</PHP>	+
-		+
-	===== Proposed PHP Version(s) =====	+
-	This RFC targets PHP 7.0.	+
-		+
-	===== RFC Impact =====	+
-		+
-	==== To Backward Incompatibility ====	+
-	This RFC maintains backwards compatibility. This RFC does not deprecate the default value syntax.	+
-		+
-	==== To SAPIs ====	+
-	This RFC has no impact to SAPIs.	+
-		+
-	==== To Existing Extensions ====	+
-	TODO	+
-		+
-	==== New Constants ====	+
-	This RFC does not propose any new constants or ini defaults.	+
-		+
-	===== Open Issues =====	+
-	Make sure there are no open issues when the vote starts!	+
-		+
-	===== Unaffected PHP Functionality =====	+
-	This RFC does not deprecate the default value syntax. While there is some overlap of features between it and this RFC, they serve different purposes. As such, the default value syntax will remain.	+
-		+
-	===== Future Scope =====	+
-	TODO	+
-		+
-	===== Proposed Voting Choices =====	+
-	This RFC modifies the PHP language syntax and therefore requires a two-third majority of votes.	+
-		+
-	===== Patches and Tests =====	+
-	There is currently no patch.	+
-		+
-	===== Implementation =====	+
-	TODO	+
-		+
-	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	+
-		+
-	===== References =====	+
-	TODO	+

rfc:nullable_types

2016-05-23T09:19:26+02:00

1462897730		current
Line 4:		Line 4:
	* Author: Levi Morrison <levim@php.net>		* Author: Levi Morrison <levim@php.net>
	* Author: Dmitry Stogov <dmitry@zend.com>		* Author: Dmitry Stogov <dmitry@zend.com>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/nullable_typehints		* First Published at: https://wiki.php.net/rfc/nullable_typehints

Line 146:		Line 146:
	----		----

-	<doodle title="Accept explicitly nullable types? (2/3 affirmative required)" auth="dmitry" voteType="single" closed="false">	+	<doodle title="Accept explicitly nullable types? (2/3 affirmative required)" auth="dmitry" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 153:		Line 153:
	----		----

-	<doodle title="Merge which features? (majority wins)" auth="dmitry" voteType="single" closed="false">	+	<doodle title="Merge which features? (majority wins)" auth="dmitry" voteType="single" closed="true">
	* Both nullable parameter and return types		* Both nullable parameter and return types
	* Only nullable return types		* Only nullable return types
Line 215:		Line 215:
	After the project is implemented, this section should contain		After the project is implemented, this section should contain
	- the version(s) it was merged to		- the version(s) it was merged to
-	- a link to the git commit(s)	+	- a link to the [[http://git.php.net/?p=php-src.git;a=commitdiff;h=9662259cb93ff04be80766bdade39d2e827e0e16\|git commit]]
	- a link to the PHP manual entry for the feature		- a link to the PHP manual entry for the feature

rfc:nullsafe_calls

2014-12-19T23:44:20+02:00

1418166484		current
Line 3:		Line 3:
	* Date: 2014-12-09		* Date: 2014-12-09
	* Author: Josh Watzman (jwatzman@fb.com), Drew Paroski		* Author: Josh Watzman (jwatzman@fb.com), Drew Paroski
-	* Status: Under Discussion	+	* Status: Draft
	* First Published at: https://wiki.php.net/rfc/nullsafe_calls		* First Published at: https://wiki.php.net/rfc/nullsafe_calls

	===== Introduction =====		===== Introduction =====
		+	The RFC has been returned to draft stage after discussion on internals in order to figure out how to deal with short circuiting. See the "open issues" section below. The rest of the RFC currently stands as originally submitted to internals.
		+
	This RFC proposes a new operator, the "nullsafe" operator ''<nowiki>?-></nowiki>'', which allows safe chaining of method calls. This is useful to easily propagate errors forward to the end of a computation which should fail if any of its sub-computations should fail.		This RFC proposes a new operator, the "nullsafe" operator ''<nowiki>?-></nowiki>'', which allows safe chaining of method calls. This is useful to easily propagate errors forward to the end of a computation which should fail if any of its sub-computations should fail.

Line 82:		Line 84:
	===== Open Issues =====		===== Open Issues =====
	Make sure there are no open issues when the vote starts!		Make sure there are no open issues when the vote starts!
		+
		+	==== Short Circuit ====
		+	The behavior for (not) short circuiting argued for above is not clearly the right behavior. There are actually at least //three// meaningful possibilities here. I'm currently investigating implementation feasibility in both PHP7 and in HHVM, as well as generally thinking about what the right thing to do is, and will bring the discussion back up on internals once I've got my thoughts together better.
		+
		+	As a quick preview, the three options can be seen as to how to desugar the following code. I'm not going to argue for or against any of them yet, just show what the range of possibilities are. (I also haven't extensively looked at the following examples, they might have errors or just not make sense, I need more time to put this together properly, dumping here for completeness only, please wait for the full revised proposal to internals :))
		+
		+	<PHP>
		+	$r = $x?->a(f())->b(g());
		+	</PHP>
		+
		+	=== Option 1: no short circuit ===
		+	Arguments are evaluated even if we are doing the nullsafe call on null.
		+
		+	<PHP>
		+	$_tmp1 = f();
		+	$_tmp2 = g();
		+	$_tmp3 = $x === null ? null : $x->a($_tmp1);
		+	$r = $_tmp3->b($_tmp2);
		+	</PHP>
		+
		+	=== Option 2: one-level short circuit ===
		+	Arguments are not evaluated if we are doing the nullsafe call on null. The nullsafe behavior only applies to the single function call where the nullsafe operator is used.
		+
		+	<PHP>
		+	$_tmp1 = $x === null ? null : $x->a(f());
		+	$r = $_tmp1->b(g());
		+	</PHP>
		+
		+	=== Option 3: full short circuit ===
		+	Arguments are not evaluated if we are doing the nullsafe call on null. The nullsafe behavior applies to all calls chained after the nullsafe operator.
		+
		+	<PHP>
		+	$r = $x === null ? null : $x->a(f())->b(g());
		+	</PHP>

	===== Unaffected PHP Functionality =====		===== Unaffected PHP Functionality =====

rfc:number_format_separator

2016-01-20T21:37:07+02:00

1452710877		current
Line 3:		Line 3:
	* Date: 2015-12-19		* Date: 2015-12-19
	* Author: Thomas Punt, tpunt@php.net		* Author: Thomas Punt, tpunt@php.net
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/number_format_separator		* First Published at: http://wiki.php.net/rfc/number_format_separator

Line 156:		Line 156:
	A simple yes/no voting option on whether to support a digit separator in PHP. A 2/3 majority is required.		A simple yes/no voting option on whether to support a digit separator in PHP. A 2/3 majority is required.

-	<doodle title="Include a Digit Separator into PHP" auth="tpunt" voteType="single">	+	<doodle title="Include a Digit Separator into PHP" auth="tpunt" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:object-model-improvements

2011-04-06T12:59:26+02:00

1299161635		current
Line 49:		Line 49:
	try {		try {
	include $file; // as of today we just die here		include $file; // as of today we just die here
-	} catch(PHPParseException $e) {	+	} catch(Exception $e) {
	echo $e->getMessage();		echo $e->getMessage();
	throw new DomainException($e);		throw new DomainException($e);

rfc:object-typehint

2016-08-16T13:16:42+02:00

1471345646		current
Line 68:		Line 68:
	<code php>		<code php>
	function acceptsObject(object $obj) {		function acceptsObject(object $obj) {
-	// there is no need to check `is_object($obj)` yo can simply check for eg. `instanceof`	+	// there is no need to check `is_object($obj)` you can simply check for eg. `instanceof`
	if ($obj instanceOf \stdClass) {		if ($obj instanceOf \stdClass) {

rfc:object_cast_magic

2012-03-04T03:22:46+02:00

1330822934		current
Line 3:		Line 3:
	* Date: 2012-02-28		* Date: 2012-02-28
	* Author: Anthony Ferrara <ircmaxell@php.net>		* Author: Anthony Ferrara <ircmaxell@php.net>
-	* Status: In Draft	+	* Status: Withdrawn
		+
		+	Note that this RFC has been withdrawn in favor of the updated https://wiki.php.net/rfc/object_cast_to_types RFC (due to feedback from several developers).

	===== Introduction =====		===== Introduction =====
Line 116:		Line 118:

	===== Questions =====		===== Questions =====
-	How would this RFC affect:
-
-	resources
-
-	streams
-
-	filters
-
-	...

rfc:object_cast_to_types

2014-04-09T00:48:24+02:00

1386053977		current
Line 4:		Line 4:
	* Author: Anthony Ferrara <ircmaxell@php.net>		* Author: Anthony Ferrara <ircmaxell@php.net>
	* Maintainer: Matiss Treinis <mrtreinis@gmail.com>		* Maintainer: Matiss Treinis <mrtreinis@gmail.com>
-	* Status: In Draft	+	* Status: In Draft (Inactive)
	* Patch: https://gist.github.com/1966809		* Patch: https://gist.github.com/1966809

rfc:objectarrayliterals

2014-04-09T00:49:18+02:00

1307393677		current
Line 4:		Line 4:
	* Date: 2011-06-04 (Updated: 2011-06-06)		* Date: 2011-06-04 (Updated: 2011-06-06)
	* Author: Sean Coates <sean@php.net>		* Author: Sean Coates <sean@php.net>
-	* Status: Under Discussion	+	* Status: Inactive

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

rfc:objkey

2015-01-11T01:36:48+02:00

1420616495		current
Line 3:		Line 3:
	* Date: 2014-10-26		* Date: 2014-10-26
	* Author: Stas Malyshev (stas@php.net), krakjoe		* Author: Stas Malyshev (stas@php.net), krakjoe
-	* Status: In Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/objkey		* First Published at: http://wiki.php.net/rfc/objkey

rfc:octal.overload-checking

2016-05-14T02:26:56+02:00

1463184806		current
Line 3:		Line 3:
	* Date: 2016-04-12		* Date: 2016-04-12
	* Author: Sara Golemon <pollita@php.net>		* Author: Sara Golemon <pollita@php.net>
-	* Status: Voting	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/octal.overload-checking		* First Published at: https://wiki.php.net/rfc/octal.overload-checking

Line 42:		Line 42:
	===== References =====		===== References =====

-	Implementation: https://github.com/php/php-src/compare/master...sgolemon:octal.warning	+	Implementation: https://github.com/php/php-src/commit/95af467d8def3f3453670340f4e65ce7c189d4f6

	The subject of this RFC is [[https://bugs.php.net/bug.php?id=71994\|Bug#71994]]		The subject of this RFC is [[https://bugs.php.net/bug.php?id=71994\|Bug#71994]]

rfc:on_demand_name_mangling

2016-01-09T03:13:16+02:00

1452266345		current
Line 1:		Line 1:
	====== PHP RFC: On-demand Name Mangling ======		====== PHP RFC: On-demand Name Mangling ======
-	* Version: 1.2b	+	* Version: 1.3
	* Created Date: 2016-01-01		* Created Date: 2016-01-01
	* Updated Date: 2016-01-08		* Updated Date: 2016-01-08
Line 99:		Line 99:

	* find all superglobal keys that violate the PHP unquoted variable name regex ((Unquoted variable names must match the regex ''[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*''))		* find all superglobal keys that violate the PHP unquoted variable name regex ((Unquoted variable names must match the regex ''[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*''))
-	* for each, create a new mangled key linked to the corresponding value.	+	* for each, create a new mangled key linked to the corresponding value

	Applications requiring name mangling may call the polyfill during their bootstrap phase to emulate prior engine behavior.		Applications requiring name mangling may call the polyfill during their bootstrap phase to emulate prior engine behavior.

	===== Proposal =====		===== Proposal =====
-	This RFC proposes to phase out automatic name mangling, replacing it with on-demand mangling in ''extract()'':	+	This RFC proposes to remove automatic name mangling, with backward compatibility maintained through a userspace polyfill function that mangles super-globals on-demand:

	* Next minor release (currently 7.1):		* Next minor release (currently 7.1):
-	* Emit an ''E_DEPRECATED'' warning the first time a variable is mangled. The warning indicates that name mangling on import will be removed in the next major PHP version.	+	* Update documentation that name mangling is deprecated and will be removed in 8.0
		+	* Between RFC acceptance and the next major release:
		+	* Release a userland polyfill that implements ''mangle_superglobals''
		+	* Polyfill shall be available via composer (but not PEAR)
	* Next major release (currently 8.0):		* Next major release (currently 8.0):
	* Remove all name mangling code in super-global marshalling functions		* Remove all name mangling code in super-global marshalling functions
-	* Release a userland polyfill implementing ''mangle_superglobals'' that is available as a composable package

	==== Discussion ====		==== Discussion ====
Line 116:		Line 118:
	These questions were raised in the mailing list discussion.		These questions were raised in the mailing list discussion.

-	=== Should multiple ''E_DEPRECATED'' be emitted? ===	+	=== Should a notice be raised if the engine mangles a superglobal? ===

-	No, because we do not know how many instances of mangling may be present and we do not want to flood application logs. The proposed single message intends to provide //some// warning to application developers when there is //known// use of name mangling. This notice is similar to the behavior of the ''datetime.timezone'' INI option: at most once per startup.	+	Before version 1.3, this RFC proposed raising an ''E_DEPRECATED'' message (once per startup) when the engine mangled a name, so that developers were made aware of future changes. However, Rouven Weßling asked:

-	=== How can I disable the ''E_DEPRECATED'' notice? ===	+	> If I have a well behaved application that doesn’t rely on name mangling or have included the polyfill, how can I prevent a log message from being emitted when a user appends (unused) parameters to the query string that require mangling?

-	Rouven Weßling asked:	+	and Nikita Popov commented:
-		+
-	> If I have a well behaved application that doesn’t rely on name mangling or have included the polyfill, how can I prevent a log message from being emitted when a user appends (unused) parameters to the query string that require mangling?	+

-	As written, one can't: the engine emits the error as soon as it mangles a variable, at most one time per startup. While that's annoying, it's also informative: someone's hitting your application in a way that may not expect.	+	> Even if it's only a single deprecation warning instead of multiple, it's still a deprecation warning that I, as the application author, have absolutely no control over. For me, a deprecation warning indicates that *there is some code I must change to make that warning go away.*
		+	> Sure, it's informative. But it's *enough to be informative about this once, rather than every time* a user makes an odd-ish request.

-	This behavior is similar to [[http://php.net/manual/en/info.configuration.php#ini.max-input-vars\|max_input_vars]], which emits a warning as soon as more variables are sent than PHP is configured to accept. This message happens at most once per startup. There's no way to turn the message off: the best one can do is increase the upper limit in the configuration file.	+	Given that (a) an application could get spammed by malicious users((The ''max_input_vars'' configuration option behaves similarly with the once-per-startup deprecation message proposed prior to version 1.3. The difference is the ''max_input_vars'' message could be squelched by increasing the limit, whereas the proposed mangling message could never be squelched by user code)), and (b) that documentation suffices to notify users of this change, then the RFC changed as of 1.3 to only document the removal of name mangling as of the next major version.

	=== Should an INI configuration control mangling? ===		=== Should an INI configuration control mangling? ===
Line 138:		Line 139:
	An INI setting to disable mangling must be engine-wide (e.g., ''PHP_INI_SYSTEM'' or ''PHP_INI_PERDIR'') as its historical effect occurs before userland code runs. Engine-wide settings are tricky because they force conditions across all instances of PHP running in a given SAPI process. In a hosted environment where many unrelated sites share the same engine configuration, it's possible that one site might require mangling while another site requires no-mangling. These two sites could not co-exist unless the site operator allows per directory configuration, which they may not. Thus, an INI setting would introduce operational problems for some definable sub-set of users.		An INI setting to disable mangling must be engine-wide (e.g., ''PHP_INI_SYSTEM'' or ''PHP_INI_PERDIR'') as its historical effect occurs before userland code runs. Engine-wide settings are tricky because they force conditions across all instances of PHP running in a given SAPI process. In a hosted environment where many unrelated sites share the same engine configuration, it's possible that one site might require mangling while another site requires no-mangling. These two sites could not co-exist unless the site operator allows per directory configuration, which they may not. Thus, an INI setting would introduce operational problems for some definable sub-set of users.

-	It's still possible to provide an "escape hatch" for applications requiring name mangling: the polyfill described eariler. Applications need only include the polyfill code and add it to their bootstrapping. The polyfill would be available via Composer, and the polyfill would populate all the mangled variables as before.	+	It's still possible to provide an "escape hatch" for applications requiring name mangling: the polyfill described earlier. Applications need only include the polyfill code and add it to their bootstrapping. The polyfill would be available via Composer, and the polyfill would populate all the mangled variables as before.

	The polyfill approach is considered superior to the INI approach for three reasons:		The polyfill approach is considered superior to the INI approach for three reasons:
Line 148:		Line 149:
	=== Should ''extract()'' automatically mangle names? ===		=== Should ''extract()'' automatically mangle names? ===

-	Early versions of this proposal (< v1.2) proposed using extract to mangle names. Rowan Collins and others pointed out this was an unnecessary complication: ''preg_match'' could also accomplish the goal. Thus, all references to ''extract'' in this RFC have been removed.	+	Early versions of this proposal (< v1.2) proposed using ''extract'' to mangle names. Rowan Collins and others pointed out this was an unnecessary complication: ''preg_match'' could also accomplish the goal. Thus, all references to ''extract'' in this RFC have been removed.

	However, ''extract()'' should have the option to emit mangled names with a new constant (''EXTR_MANGLE''). ''extract()'' should also be fixed to export variables with any variable name, because they are all technically valid with the quoted variable syntax (''${'foo.bar'}''). These will be handled as function fixes and not with this RFC.		However, ''extract()'' should have the option to emit mangled names with a new constant (''EXTR_MANGLE''). ''extract()'' should also be fixed to export variables with any variable name, because they are all technically valid with the quoted variable syntax (''${'foo.bar'}''). These will be handled as function fixes and not with this RFC.
Line 181:		Line 182:
	<code>		<code>
	$ composer require php/mangle-superglobals ^1.0		$ composer require php/mangle-superglobals ^1.0
-	$ cat app/boostrap.php	+	$ cat app/bootstrap.php
	<?php		<?php
	require __DIR__ . '/vendor/autoload.php';		require __DIR__ . '/vendor/autoload.php';

rfc:openssl_aead

2016-01-27T18:12:19+02:00

1453914694		current
Line 86:		Line 86:
	</doodle>		</doodle>

-	Voting starts on January 20th at 17:00 UTC and ends on January 27th at 17:00 UTC.	+	Voting started on January 20th at 17:00 UTC and ended on January 27th at 17:00 UTC.

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

rfc:operator-overloading

2016-01-03T03:10:59+02:00

1451786902		current
Line 2:		Line 2:
	* Version: 0.1		* Version: 0.1
	* Date: 2016-01-02		* Date: 2016-01-02
-	* Author: @pmtarantino, (with Sara Golemon <pollita@php.net>)	+	* Author: Patricio Tarantino <patriciotarantino@gmail.com> (with Sara Golemon <pollita@php.net>)
	* Status: Draft		* Status: Draft
	* First Published at: http://wiki.php.net/rfc/operator-overloading		* First Published at: http://wiki.php.net/rfc/operator-overloading
Line 71:		Line 71:

	===== Future Expansion =====		===== Future Expansion =====
-	Introduce dispatch for additional operations (see Future Expansion)?	+	Introduce dispatch for additional operations?

	public function __mod($__value__); // Overloads % operator		public function __mod($__value__); // Overloads % operator

rfc:operator_overloading_gmp

2013-06-17T18:29:51+02:00

1371482453		current
Line 4:		Line 4:
	* Date: 2013-05-12		* Date: 2013-05-12
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented in PHP 5.6
	* Patch: https://github.com/php/php-src/pull/342		* Patch: https://github.com/php/php-src/pull/342
-	* Target version: PHP 5.6 (or whatever the next one is)

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

rfc:optimizerplus

2013-10-29T18:22:34+02:00

1362674368		current
Line 3:		Line 3:
	* Date: 2013-01-28		* Date: 2013-01-28
	* Author: Zeev Suraski <zeev@php.net>		* Author: Zeev Suraski <zeev@php.net>
-	* Status: Approved, Optimizer+ will be integrated into PHP 5.5.0	+	* Status: Implemented in PHP 5.5
	* First Published at: http://wiki.php.net/rfc/optimizerplus		* First Published at: http://wiki.php.net/rfc/optimizerplus

rfc:optional-t-function

2014-04-09T00:55:13+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2010-11-27		* Date: 2010-11-27
	* Author: Johannes Schlüter		* Author: Johannes Schlüter
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/optional-t-function		* First Published at: http://wiki.php.net/rfc/optional-t-function

rfc:pack_unpack_64bit_formats

2015-07-07T19:35:13+02:00

1412320544		current
Line 3:		Line 3:
	* Date: 2014-09-12		* Date: 2014-09-12
	* Author: leigh@php.net		* Author: leigh@php.net
-	* Status: Voting	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/pack_unpack_64bit_formats		* First Published at: https://wiki.php.net/rfc/pack_unpack_64bit_formats

Line 77:		Line 77:

	===== Implementation =====		===== Implementation =====
-	TODO	+
		+	Done: [[https://github.com/php/php-src/commit/63fd969300e39302b1f8c600bc24f049a0e13370]]

	===== References =====		===== References =====
	[[http://perldoc.perl.org/functions/pack.html\|Perl pack() documentation]]		[[http://perldoc.perl.org/functions/pack.html\|Perl pack() documentation]]

rfc:parameter_type_casting_hints

2012-03-08T01:53:06+02:00

1331126149		current
Line 3:		Line 3:
	* Date: 2012-03-03		* Date: 2012-03-03
	* Author: Anthony Ferrara <ircmaxell@php.net>		* Author: Anthony Ferrara <ircmaxell@php.net>
-	* Status: In Draft	+	* Status: Withdrawn
	* First Published at: https://wiki.php.net/rfc/parameter_type_casting_hints		* First Published at: https://wiki.php.net/rfc/parameter_type_casting_hints
	* Patch: https://gist.github.com/1963999		* Patch: https://gist.github.com/1963999

rfc:parser-extension-api

2015-03-03T09:27:49+02:00

1424673444		current
Line 1:		Line 1:
	====== PHP RFC: Parser Extension API ======		====== PHP RFC: Parser Extension API ======
-	* Version: 0.1	+	* Version: 0.2
	* Date: 2015-02-17		* Date: 2015-02-17
	* Author: Nikita Popov <nikic@php.net>, Alexander Lisachenko <lisachenko.it@gmail.com>		* Author: Nikita Popov <nikic@php.net>, Alexander Lisachenko <lisachenko.it@gmail.com>
Line 9:		Line 9:
	===== Introduction =====		===== Introduction =====
	This RFC proposes an introduction of userland parser extensions API for providing an access to the low-level Abstract Syntax Tree (AST) parser.		This RFC proposes an introduction of userland parser extensions API for providing an access to the low-level Abstract Syntax Tree (AST) parser.
-
-	RFC consists of two parts:
-	* parsing API that provides an AST for a given string of source code
-	* extension API that allows to register custom PHP hooks from userland to modify an Abstract Syntax Tree before transforming it into concrete opcodes.

	===== Parsing API proposal =====		===== Parsing API proposal =====
Line 45:		Line 41:
	/**		/**
	* Returns the text representation of current node		* Returns the text representation of current node
		+	* Recursively applied to all children
	*		*
	* @return string		* @return string
Line 68:		Line 65:
	The `flags` property contains node specific flags. It is always defined, but for most nodes it is always zero. isUsingFlags() method for node can be used to determine whether a node has a meaningful flags value.		The `flags` property contains node specific flags. It is always defined, but for most nodes it is always zero. isUsingFlags() method for node can be used to determine whether a node has a meaningful flags value.

		+	The `value` property contains a value only from zval AST nodes.
	The `lineNumber` property specified the starting line number of the node.		The `lineNumber` property specified the starting line number of the node.
	The `children` property contains an array of child-nodes.		The `children` property contains an array of child-nodes.
Line 80:		Line 78:
	{		{
	/**		/**
-	* Parses given code and returns an AST for it	+	* Parses the given code and returns an AST for it
		+	*
		+	* @param string $phpCode Source code to analyse
	*		*
	* @return Node		* @return Node
Line 88:		Line 88:
	</code>		</code>

-	The static Engine::parse() method accepts a source code string (which is parsed in INITIAL mode, i.e. it should generally include an opening PHP tag) and returns an abstract syntax tree consisting of Node objects.	+	The static Engine::parse() method accepts a source code string (which is parsed in INITIAL mode, i.e. it should generally include an opening PHP tag) and returns an abstract syntax tree consisting of Node objects. An abstract syntax tree can be compiled/pretty-printed later into a Php code.

	Here is an example of getting an AST for simple code:		Here is an example of getting an AST for simple code:
Line 117:		Line 117:
	This information about AST can be used later for custom Parser Extensions, QA static analysis tools, source code rewriting tools and much more.		This information about AST can be used later for custom Parser Extensions, QA static analysis tools, source code rewriting tools and much more.

-	I want to notice, that this part was originally implemented and described by Nikita Popov as an experimental php-ast extension https://github.com/nikic/php-ast, so it can be used as a starting point for this RFC.	+	I want to notice, that this part was originally implemented and described by Nikita Popov as an experimental php-ast extension https://github.com/nikic/php-ast, so it can be used as base implementation.

-	==== Parser Extension API ====
-
-	Second part of this RFC proposes to add an API for building userland parser extensions. We could allow userland extensions to hook into the compilation process. This would allow extensions to implement some types of language features, for example, Design-by-Contract verifying, Aspect-Oriented programming, analysis of annotation metadata and much more.
-
-	Userland parser extension is described by the extension interface with single `process` method that accepts only one argument - top-level AST node and can modify it.
-
-	<code php>
-	<?php
-	namespace Php\Parser;
-
-	interface ExtensionInterface {
-
-	/**
-	* Receives a top-level node of AST and can transform it
-	*/
-	public static function process(Node $node);
-	}
-	</code>
-
-	Each extension can be registered or unregistered in the parser engine class by calling appropriate methods:
-
-	<code php>
-	<?php
-	namespace Php\Parser;
-
-	class Engine {
-
-	/**
-	* @var array\|string[] List of parser extension classes
-	*/
-	private static $extensions;
-
-	/**
-	* Register an extension class in the parser
-	* @param string $extensionClassName Name of the extension class
-	*/
-	public static function registerExtension($extensionClassName)
-
-	/**
-	* Unregister an extension class from the parser
-	* @param string $extensionClassName Name of the extension class
-	*/
-	public static function unregisterExtension($extensionClassName)
-
-	/**
-	* Returns a list of currently registered extensions
-	* @return string[]\|array List of registered extensions
-	*/
-	public static function getRegisteredExtensions()
-	}
-	</code>
-
-	Here is an example with pseudo-code of possible usage for implementing Design-By-Contract paradigm:
-
-	<code php>
-	<?php
-
-	use Php\Parser\Node;
-	use Php\Parser\Engine as ParserEngine;
-	use Php\Parser\ExtensionInterface;
-
-	class DbcParserExtension implements ExtensionInterface
-	{
-	public static function process(Node $node)
-	{
-	// prepare an AST to insert, this can be annotation or anything else
-	$astToInsert = ParserEngine::parse('<?php assert("$this->value > 0")');
-
-	// node visitor, that will traverse the AST for specific nodes
-	$methodNodeVisitor = new NodeVisitor($node, Node::AST_METHOD);
-	$methodNodeVisitor->visit(function (Node $node) use ($astToInsert) {
-	// Insert our AST code before original method statements
-	$node->children = array_merge($astToInsert->children, $node->children);
-	});
-	}
-	}
-
-	// Registration of extension
-	ParserEngine::registerExtension(DbcParserExtension::class);
-
-	// Now every include/eval/create_function/etc will trigger our hook
-	include 'SomeClass.php';
-
-	// We can alos parse a code directly with parser, hook will be called too:
-	ParserEngine::parse(file_get_contents('SomeClass.php'));
-	</code>
-
-	==== General flow of compiling the source code and limitations ====
-
-	Current flow (as of PHP7) of running PHP code can be represented as following:
-
-	''Source Code > Tokenizer > AST > Opcodes > Execution''
-
-	Fist step is lexing (or tokenization) of source code into separate tokens. After that Abstract Syntax Tree is generated by the parser, based on token stream and PHP Grammar. This AST is used for producing concrete opcodes for each node. More details available at [[rfc::abstract_syntax_tree#Overview\|Abstract Syntax Tree RFC]]
-
-	After implementation of this RFC, general flow will be changed in the following way:
-
-	''Source Code > Tokenizer > AST > Parser Extension > Opcodes > Execution''
-
-	Note, that Parser Extension hooks are executing before generating of opcodes, so hooks will be typically called only once per each file, because of opcode cachers. This is considered as limitation of parser extensions, they can receive an AST for file only once, so no dynamic AST transformations are allowed, because all opcodes are fetched directly by file name:
-
-	''Source Code > Opcodes > Execution''
-
-
-	==== Impact on performance ====
-
-	Without registered parser extensions there is no impact on runtime performance, because no extra steps are required to compile a source code into the opcodes. Each registered parser extension will have a little impact on runtime performance, because userland hooks should be invoked after parsing of each file or executing `eval` constructions. However, with enabled opcode cacher, this operation is performed only once for each file and then cached version of opcodes is used without future calls to the userland extensions, as such any difference does not have a practical impact.

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====
Line 241:		Line 134:

	==== To Opcache ====		==== To Opcache ====
-	This RFC doesn't affect an opcache logic, because it provides an API for AST-manipulation which is earlier step of execution of source code. However, presence of opcache is highly required for usage of parser extensions to avoid unnecessary call of extensions for not modified files.	+	This RFC doesn't affect an opcache logic, because it provides an API only for accessing the AST information.

	==== New Constants ====		==== New Constants ====
Line 247:		Line 140:

	==== php.ini Defaults ====		==== php.ini Defaults ====
-	Currently no	+	No

	===== Open Issues =====		===== Open Issues =====
-	- Need to clarify/choose the right way of registration of parser extensions (http://news.php.net/php.internals/82951, http://news.php.net/php.internals/82958)	+	- Should each node type be represented as personal class?
-	- Inclusion of `NodeVisitor` class into the parser RFC?	+	- Where metadata should be stored (flags, names of kind nodes, relation between node types)? This information will be needed later for validation of AST
-	- Should voting include 2/3 majority or simple 50%+1 vote?	+

	===== Future Scope =====		===== Future Scope =====
-	This implementation of RFC can be used later for building an API for annotations (metadata) to return values as AST nodes, as well, as Design-By-Contract handler, that operates on AST.	+	This implementation of RFC can be used later for building userland parser extensions (based on zend_ast_process() hook). We could allow userland extensions to hook into the compilation process. This would allow extensions to implement some types of language features, for example, Design-by-Contract verifying, Aspect-Oriented programming, analysis of annotation metadata and much more.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====
-	Not decided yet.	+	Target version:
		+	- 7.0
		+	- 7.x
		+	- Do not include this API into core
		+
		+	Implementation paradigm:
		+	- Object-oriented: Php\Parser\Engine
		+	- Functional: ast_xxx() functions

		+	Namespace:
		+	- None (top-level)
		+	- Php\Parser\
		+	- Ast\

	===== Patches and Tests =====		===== Patches and Tests =====
Line 270:		Line 173:
	- PHP RFC: Abstract syntax tree https://wiki.php.net/rfc/abstract_syntax_tree		- PHP RFC: Abstract syntax tree https://wiki.php.net/rfc/abstract_syntax_tree
	- PHP-AST Extension https://github.com/nikic/php-ast		- PHP-AST Extension https://github.com/nikic/php-ast
		+	- Compiler hook for altering the AST pre-compilation https://github.com/php/php-src/commit/1010b0ea4f4b9f96ae744f04c1191ac228580e48
	- Userland PHP Parser https://github.com/nikic/PHP-Parser		- Userland PHP Parser https://github.com/nikic/PHP-Parser
	- Userland PHP-Token-Reflection https://github.com/Andrewsville/PHP-Token-Reflection		- Userland PHP-Token-Reflection https://github.com/Andrewsville/PHP-Token-Reflection
		+	- Abstract Syntax Trees API in Python Language https://docs.python.org/2/library/ast.html


	===== Rejected Features =====		===== Rejected Features =====
-	None	+	- Userland parser extensions - need more time to clarify details, possible targets are 7.x or 8.0

rfc:partial_function_application

2016-08-10T18:00:41+02:00

1470844203		current
Line 17:		Line 17:
	$array = ['arg' => 0];		$array = ['arg' => 0];

-	// the following two statements are equivalent	+	// the following two groups of statements are equivalent
-	// (assuming we supported variable assignment for function use-statements)	+
	f(_, $array['arg']);		f(_, $array['arg']);

-	function($value) use($ref = &$array['arg']) {	+	$ref = &$array['arg'];
		+	function($value) use(&$ref) {
	return f($value, $ref);		return f($value, $ref);
	};		};

rfc:password_hash

2013-10-28T15:36:43+02:00

1350378347		current
Line 27:		Line 27:
	===== Common Misconceptions =====		===== Common Misconceptions =====

-	==== Salts Need To Be Cryptographically Secure ====	+	==== Salts Need To Be True Random ====

-	Salts exist for a single reason: To make it so that any time (CPU effort) spent cracking a single password hash cannot be amortized across multiple hashes. That means that attacking a single password hash will have no impact on the time it will take attacking another hash. Based on that reason, salts only need to be unique in a system. There is no requirement for them to be cryptographically secure.	+	Salts exist for a single reason: To make it so that any time (CPU effort) spent cracking a single password hash cannot be amortized across multiple hashes. That means that attacking a single password hash will have no impact on the time it will take attacking another hash. Based on that reason, salts only need to be statistically globally unique. There is no requirement for them to be true random (as you would need for an encryption key). This means that ///dev/urandom// is acceptable, while //mt_rand()// and //rand()// are not (except as fallbacks).

	==== Hash(password + salt) Is Fine ====		==== Hash(password + salt) Is Fine ====
Line 423:		Line 423:
	* 1.4 - Close Voting - Moving To Accepted		* 1.4 - Close Voting - Moving To Accepted
	* 1.5 - Implemented!		* 1.5 - Implemented!
		+	* 1.5.1 - Fine tune wording of "Cryptographically Secure Salt Requirement"

rfc:password_hash_spec

2014-07-24T01:09:20+02:00

1406092878		current
Line 37:		Line 37:
	</code>		</code>

-	In general, users are recommended to use crypt related functions as is and this is documented currently. However, SOME_STATIC_SECRET_SALT is still useful as mitigation when password database is stolen while SOME_STATIC_SECRET_SALT is _not_ stolen. (e.g. Stolen password DB via SQL injection, stolen password db backup, etc) Therefore, some organizations require to add secret salt for an additional mitigation.	+	In general, users are recommended to use crypt related functions as is and this is documented currently. However, SOME_STATIC_SECRET_SALT is still useful as mitigation when password database is stolen while SOME_STATIC_SECRET_SALT is _not_ stolen. (e.g. Stolen password DB via SQL injection, stolen password db backup, etc) Therefore, some organizations require to add secret salt for an additional mitigation. 72 bytes limits is real problem in this case.


Line 51:		Line 51:
	- Add PASSWORD_SHA512 hashing to password_hash() that is compatible with crypt-sha512		- Add PASSWORD_SHA512 hashing to password_hash() that is compatible with crypt-sha512

-	password hashing related documentation:	+	Password hashing related documentation:

	Recommend plain use of password_hash() with less than 72 bytes.		Recommend plain use of password_hash() with less than 72 bytes.
Line 58:		Line 58:

	- Suggest PBKDF2 SHA512 functions ([[http://jp2.php.net/manual/en/function.hash-pbkdf2.php\|hash]] or [[http://jp2.php.net/manual/en/function.openssl-pbkdf2.php\|openssl]]) as an alternative. (rounds larger than 10,000)		- Suggest PBKDF2 SHA512 functions ([[http://jp2.php.net/manual/en/function.hash-pbkdf2.php\|hash]] or [[http://jp2.php.net/manual/en/function.openssl-pbkdf2.php\|openssl]]) as an alternative. (rounds larger than 10,000)
-	- Suggest (not recommend) prehash with raw SHA512. (e.g. password_hash(hash('sha512', SOME_STATIC_SCRET_SALT . $password), PASSWORD_DEFAULT);)	+	- Suggest workaround (not recommend) by prehash with raw SHA512. (e.g. password_hash(hash('sha512', SOME_STATIC_SCRET_SALT . $password), PASSWORD_DEFAULT);)


Line 72:		Line 72:
	==== To Existing Extensions ====		==== To Existing Extensions ====

-	string	+	* [[http://jp2.php.net/manual/en/book.password.php\|Password Hashing]]


	==== New Constants ====		==== New Constants ====

-	PASSWORD_SHA512 for crypt-sha512	+	* PASSWORD_SHA512 for crypt-sha512

	==== php.ini Defaults ====		==== php.ini Defaults ====

rfc:pdonotices

2011-04-06T12:59:26+02:00

1255423307		current
Line 8:		Line 8:
	===== Databases notices =====		===== Databases notices =====

-	The most important Databases have a functionality which	+	The most important Databases have a functionality which returns some notices about the current query. These notices can be raised by the Database engine within a ''CREATE TABLE'', ''UPDATE'' or ''DELETE'' query for instance or by a user function.
-	returns some notices about the current query. These	+
-	notices can be raised by the Database engine within a	+
-	''CREATE TABLE'', ''UPDATE'' or ''DELETE'' query for instance or by	+
-	a user function.	+

-	Generally, notices contain information about the	+	Generally, notices contain information about the parallel executions, about the number of fetched rows or about the performances of the query.
-	parallel executions, about the number of fetched rows or	+
-	about the performances of the query.	+

	===== Get notices in PDO =====		===== Get notices in PDO =====

-	In PDO, notices are stored into a "''notices''" HashTable in	+	In PDO, notices are stored into a "''notices''" HashTable in the "''_pdo_dbh_t''" structure. Notices are inserted into it by each Database's PDO's driver using:
-	the "''_pdo_dbh_t''" structure. Notices are inserted into it	+
-	by each Database's PDO's driver using:	+

-	> ''zend_hash_next_index_insert(dbh->notices, &val, sizeof(zval *), NULL);''	+	<code c>zend_hash_next_index_insert(dbh->notices, &val, sizeof(zval ), NULL);</code>*

-	Where zval is the zval message string and val the	+	Where zval is the zval message string and val the allocated message string.
-	allocated message string.	+

-	This is done if user have specified that he want to	+	This is done if user have specified that he want to fetch notices using the setAttribute or the $option parameter on the PDO constructor.
-	fetch notices using the setAttribute or the $option	+
-	parameter on the PDO constructor.	+
-	* The name of the attribute is: ''PDO::ATTR_LOG_NOTICES''	+
-	* The possible values are:	+
-	- PDO::NOTICES_NONE -- no fetching	+
-	- PDO::NOTICES_ARRAY -- fetching & noticeInfo returning	+
-	value is an array.	+

-	The name of the function that users have use to get	+	* The name of the attribute is: ''PDO::ATTR_LOG_NOTICES''
-	notices is "''noticeInfo''" which returns an ''array'' (when	+	* The possible values are:
-	''PDO::NOTICES_ARRAY'' is the value of	+	* PDO::NOTICES_NONE -- no fetching
-	''PDO::ATTR_LOG_NOTICES''). The name is based on the	+	* PDO::NOTICES_ARRAY -- fetching & noticeInfo returning value as an array
-	"errorInfo" function to be more user-friendly.	+

-	Note: ''noticeInfo'' is a ''PDO'' function, not a ''PDOStatement''	+	The name of the function that users have use to get notices is "''noticeInfo''" which returns an ''array'' (when ''PDO::NOTICES_ARRAY'' is the value of ''PDO::ATTR_LOG_NOTICES''). The name is based on the "errorInfo" function to be more user-friendly.
-	function.	+
		+	Note: ''noticeInfo'' is a ''PDO'' function, not a ''PDOStatement'' function.

	==== Get notices with PostgreSQL ====		==== Get notices with PostgreSQL ====

-	Notices in PostgreSQL are raised in Pl/PgSQL with the	+	Notices in PostgreSQL are raised in Pl/PgSQL with the "''RAISE NOTICE''" command. They can be fetched using a notice processor defined by the "''PQsetNoticeProcessor''" pointing on a "''_pdo_pgsql_notice''" function which insert the message into ''dbh->notices'' like the principle described into the [[#get notices with postgresql\|Get notices in PDO]] part.
-	"''RAISE NOTICE''" command. They can be fetched using a	+
-	notice processor defined by the "''PQsetNoticeProcessor''"	+
-	pointing on a "''_pdo_pgsql_notice''" function which insert	+
-	the message into ''dbh->notices'' like the principle	+
-	described into the [[#get notices with postgresql\|Get notices in PDO]] part.	+

	==== Get notices in MySQL ====		==== Get notices in MySQL ====

-	In MySQL, the working of notices is NOT like PostgreSQL.	+	In MySQL, the working of notices is NOT like PostgreSQL. MySQL raise notices within simple queries like ''UPDATE'' or ''DELETE''. These notices cannot be raised by a user function.
-	MySQL raise notices within simple queries like ''UPDATE'' or	+
-	''DELETE''. These notices cannot be raised by a user	+
-	function.	+

-	In the MySQL C API, there's a function whose purpose is	+	In the MySQL C API, there's a function whose purpose is to get the number of warnings (and notices) for the last
-	to get the number of warnings (and notices) for the last	+	query. This function is ''mysql_warning_count()''\\ [http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html]
-	query. This function is ''mysql_warning_count()''\\	+
-	[http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html]	+

-	If ''mysql_warning_count'' result is greater than or equal	+	If ''mysql_warning_count'' result is greater than or equal to 1, there are warnings and we will get them. To get
-	to 1, there are warnings and we will get them. To get	+	these warning, we have to fetch results of the "SHOW WARNINGS" query.\\ [http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html]
-	these warning, we have to fetch results of the "SHOW	+
-	WARNINGS" query.\\	+
-	[http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html]	+

-	If ''mysql_warning_count() = 0'', we can get the result of	+	If ''mysql_warning_count() = 0'', we can get the result of mysql_info which returns informations about the last
-	mysql_info which returns informations about the last	+	query. If the result of it is different to NULL, put the results into ''dbh->notices''.\\ [http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html]
-	query. If the result of it is different to NULL, put the	+
-	results into ''dbh->notices''.\\	+
-	[http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html]	+


	==== Get notices in Oracle ====		==== Get notices in Oracle ====

-	In Oracle, notices can be raised by ''DBMS_OUTPUT'' within a	+	In Oracle, notices can be raised by ''DBMS_OUTPUT'' within a Pl/SQL function and some notifications are created by the Oracle Server.
-	Pl/SQL function and some notifications are created by	+
-	the Oracle Server.	+

-	"Call ''OCIInitialize()'' with ''OCI_EVENTS'' mode to specify	+	"Call ''OCIInitialize()'' with ''OCI_EVENTS'' mode to specify that the application is interested in registering for and receiving notifications. This starts a dedicated listening thread for notifications on the client."\\ [http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1428]
-	that the application is interested in registering for	+
-	and receiving notifications. This starts a dedicated	+
-	listening thread for notifications on the client."\\	+
-	[http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1428]	+

-	Informations about notification callback which I didn't	+	Informations about notification callback which I didn't understand very much: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1446
-	understand very much: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1446	+

	This is about getting notifications from Oracle: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci10new.htm#sthref1457		This is about getting notifications from Oracle: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci10new.htm#sthref1457

-	Global method for Oracle, in addition of these previous	+	Global method for Oracle, in addition of these previous methods, to get DMBS_OUTPUT:
-	methods, to get DMBS_OUTPUT:	+

-	- Execute "''BEGIN DBMS_OUTPUT.ENABLE(NULL); END;''" when ''PDO::ATTR_LOG_NOTICES'' is turned a value different to ''PDO::NOTICES_NONE''.\\	+	* Execute <code plsql>BEGIN DBMS_OUTPUT.ENABLE(NULL); END;</code> when ''PDO::ATTR_LOG_NOTICES'' is turned a value different to ''PDO::NOTICES_NONE''.\\
-	- After each successful queries, fetch: "''BEGIN DBMS_OUTPUT.GET_LINE(:LN, :ST); END;''" with '':LN'' and '':ST'' two OUT parameters which define the informations and the number of them. \\	+	* After each successful queries, fetch: <code plsql>BEGIN DBMS_OUTPUT.GET_LINE(:LN, :ST); END;</code> with '':LN'' and '':ST'' two OUT parameters which define the informations and the number of them. \\
-	- Execute "''BEGIN DBMS_OUTPUT.DISABLE(); END;''" when ''PDO::ATTR_LOG_NOTICES'' is turned a value equal to ''PDO::NOTICES_NONE''.\\	+	* Execute <code plsql>BEGIN DBMS_OUTPUT.DISABLE(); END;</code> when ''PDO::ATTR_LOG_NOTICES'' is turned a value equal to ''PDO::NOTICES_NONE''.\\

	==== For others Databases ====		==== For others Databases ====

-	For others Databases who have a notice functionality, we	+	For others Databases who have a notice functionality, we have to
-	have to	+
	reflect. Personally, i do not know which Databases...		reflect. Personally, i do not know which Databases...

rfc:pdov1

2014-04-09T00:50:24+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2008-03-06		* Date: 2008-03-06
	* Author: Lukas Smith <smith@pooteeweet.org>		* Author: Lukas Smith <smith@pooteeweet.org>
-	* Status: In the works	+	* Status: Draft (Inactive)

	This RFC aims to collect a set of ideas to improve PDO version 1. These ideas will hopefully end up in a set of concret feature requests and patches.		This RFC aims to collect a set of ideas to improve PDO version 1. These ideas will hopefully end up in a set of concret feature requests and patches.

rfc:pecl_http

2015-03-09T13:43:21+02:00

1425070958		current
Line 4:		Line 4:
	* Last-Modified: 2015-02-20		* Last-Modified: 2015-02-20
	* Author: Michael Wallner, <mike@php.net>		* Author: Michael Wallner, <mike@php.net>
-	* Status: Vote	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/pecl_http		* First Published at: http://wiki.php.net/rfc/pecl_http

rfc:peclversioning

2011-04-06T12:59:26+02:00

1216213241		current
Line 1:		Line 1:
	===== Request for Comments: PECL Versioning =====		===== Request for Comments: PECL Versioning =====

-	=== The Problem ===	+	=== History ===
-	Currently, PECL versioning is fairly anarchic. It is impossible to determine the status of an extension, or whether an update will break binary compatibility with previous versions (or work with a given PHP release) without a long try-&-fail process. Windows PECL binaries should have reliable version information in the DLL resources (physically visible in the file properties) as well as at runtime (through phpinfo(), phpversion('extname') etc.). Some of the processes in php.net that currently use hard-coded lists could also benefit from a standardized versioning process. This problem has to be fixed to bring PECL to a higher quality and reliability level.	+	PECL versioning has historically been fairly anarchic. This made it impossible to determine the status of an extension, or whether an update would break binary compatibility with previous versions (or work with a given PHP release) without a long try-&-fail process. Some of the processes in php.net that currently use hard-coded lists could also benefit from a standardized versioning process.
		+
		+	The base proposal was implemented across PECL by April 2008. Only the question of what to do about PHP extensions that are both in PECL and in the PHP core - and usually symlinked - remains open. //It would be nice to resolve this before the PHP 5.3.0 release!//

	There are actually two RFCs (proposals) to deal with version numbering in PECL and for core PHP extensions in general.		There are actually two RFCs (proposals) to deal with version numbering in PECL and for core PHP extensions in general.

rfc:performanceimprovements

2013-06-17T07:11:05+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2010-04-13		* Date: 2010-04-13
	* Author: Dmitry Stogov <dmitry@zend.com>, Stanislav Malyshev <stas@zend.com>		* Author: Dmitry Stogov <dmitry@zend.com>, Stanislav Malyshev <stas@zend.com>
-	* Status: Under Discussion	+	* Status: Implemented in 5.4
	* First Published at: http://wiki.php.net/rfc/performanceimprovements		* First Published at: http://wiki.php.net/rfc/performanceimprovements

rfc:php-array-api

2013-04-03T04:47:15+02:00

	current
Line 1:	Line 1:

	+	====== PHP RFC: PHP Array API simplification ======
	+	* Version: 0.1
	+	* Date: 2013-04-02
	+	* Author: Sara Golemon, pollita@php.net
	+	* Status: Discussion
	+	* First Published at: http://wiki.php.net/rfc/php-array-api
	+
	+	===== Introduction =====
	+
	+	Adding values to PHP Array style HashTables is already very easy:
	+
	+	add_assoc_long(arr, "life", 42);
	+	add_index_string(arr, 7, "A lucky number");
	+	add_next_index_double(arr, 3.1415926535);
	+
	+	This header file provides similar convenience wrappers to the zend_hash_(index_)_(find\|exists\|del) functions to ease extension writing.
	+
	+	===== Self-documented implementation =====
	+
	+	https://github.com/sgolemon/php-array-api/blob/master/php_array.h
	+
	+	===== Backward Incompatible Changes =====
	+
	+	None, it's a header. My intention at this point is to put this in main/php_array.h and include it in the installed headers target.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	5.6, though non-bundled extensions could easily drop this file into their packages and use it on any PHP version >= 4.0
	+
	+	===== Proposed Voting Choices =====
	+
	+	Could include this in Zend/ instead of main/...

rfc:php6-rethink

2013-02-21T04:07:18+02:00

1343880059		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: PHP6 rethink ======
	* Version: 1.0		* Version: 1.0
	* Date: 2012-07-26		* Date: 2012-07-26

rfc:php6

2014-07-30T01:42:37+02:00

1406123791		current
Line 3:		Line 3:
	* Date: 2014-07-05 (latest 2014-07-22)		* Date: 2014-07-05 (latest 2014-07-22)
	* Authors: Andrea Faulds <ajf@ajf.me>, Zeev Suraski <zeev@php.net>		* Authors: Andrea Faulds <ajf@ajf.me>, Zeev Suraski <zeev@php.net>
-	* Status: In Voting	+	* Status: Accepted (Name is PHP 7)
	* First Published at: http://wiki.php.net/rfc/php6		* First Published at: http://wiki.php.net/rfc/php6

Line 70:		Line 70:
	Voting started 2014-07-20 but was cancelled.		Voting started 2014-07-20 but was cancelled.

-	Voting restarted 2014-07-23 afresh and ends 2014-07-30.	+	Voting restarted 2014-07-23 afresh and ended 2014-07-30.

-	<doodle title="Shall the name of PHP NEXT be PHP 6, or PHP 7?" auth="user" voteType="single" closed="false">	+	<doodle title="Shall the name of PHP NEXT be PHP 6, or PHP 7?" auth="user" voteType="single" closed="true">
	* PHP 6		* PHP 6
	* PHP 7		* PHP 7

rfc:php7_57_roadmap

2014-11-23T03:28:21+02:00

1416628940		current
Line 12:		Line 12:


-	==== Proposals ====	+	===== Proposals =====
	As this time there are two positions about when we should try to release php 7 final:		As this time there are two positions about when we should try to release php 7 final:

Line 19:		Line 19:
	* Whether or not to have a 5.7 release		* Whether or not to have a 5.7 release

-	===== PHP 7, within one year maximum ====	+	==== PHP 7, within one year maximum ====

-	====== Introduction ======	+	=== Introduction ===

	With key decisions about both the version number and the engine for PHP 7 behind us, it's time to define an agreed-upon timeline so that all contributors can align around it.		With key decisions about both the version number and the engine for PHP 7 behind us, it's time to define an agreed-upon timeline so that all contributors can align around it.
Line 27:		Line 27:


-	====== Proposal ======	+	=== Proposal ===

	As the competitive landscape for PHP is evolving, the proposal is to shorten that timeline as much as possible while still taking advantage of the unique opportunities available to us due to the major version number change. A one year timeline will allow us a fair amount of time to work on changes that are only allowed in major versions - namely, ones that break compatibility. Arguably, while we should definitely take the opportunity to implement compatibility-breaking changes in 7.0, we also shouldn't turn it into a compatibility-breaking festival, as the more we break, the more likely it is users would delay upgrades, stay with old, insecure versions - or even consider other alternative options.		As the competitive landscape for PHP is evolving, the proposal is to shorten that timeline as much as possible while still taking advantage of the unique opportunities available to us due to the major version number change. A one year timeline will allow us a fair amount of time to work on changes that are only allowed in major versions - namely, ones that break compatibility. Arguably, while we should definitely take the opportunity to implement compatibility-breaking changes in 7.0, we also shouldn't turn it into a compatibility-breaking festival, as the more we break, the more likely it is users would delay upgrades, stay with old, insecure versions - or even consider other alternative options.
Line 44:		Line 44:


-	===== PHP 7, within one and a half year maximum =====	+	==== PHP 7, within one and a half year maximum ====

-	====== Introduction ======	+	=== Introduction ===

	PHP 6 was one of the biggest trauma in the php.net history. We have magisterially failed to define a clear roadmap, to find consensus on what it should be along many other issues like small groups fighting each other or hidden meetings or developments.		PHP 6 was one of the biggest trauma in the php.net history. We have magisterially failed to define a clear roadmap, to find consensus on what it should be along many other issues like small groups fighting each other or hidden meetings or developments.
Line 52:		Line 52:
	Most of these issues have been solved or can be solved with the RFC process. However the increasing pressure on PHP from the various alternative implementations (hhvm on top) puts us in a difficult position, and we may better have to act quickly to provide a better or similar alternative.		Most of these issues have been solved or can be solved with the RFC process. However the increasing pressure on PHP from the various alternative implementations (hhvm on top) puts us in a difficult position, and we may better have to act quickly to provide a better or similar alternative.

-	====== Proposal ======	+	=== Proposal ===

	The release process clearly defines how a release development phase should be done. Being strict allows us to actually release any version in time, as planed. A clear roadmap defining until when RFCs can be proposed, when they have to be implemented and merged, etc prevents any delay.		The release process clearly defines how a release development phase should be done. Being strict allows us to actually release any version in time, as planed. A clear roadmap defining until when RFCs can be proposed, when they have to be implemented and merged, etc prevents any delay.
Line 72:		Line 72:


-	====== Timetable ======	+	=== Timetable ===
	* Dev and beta allow new features to be added, if accepted via RFCs.		* Dev and beta allow new features to be added, if accepted via RFCs.
	* RC means no new feature, even if accepted via RFCs.		* RC means no new feature, even if accepted via RFCs.
Line 89:		Line 89:
	</code>		</code>

-	===== PHP 5.7 =====	+	=== PHP 5.7 ===

	The idea of a PHP 5.7 is:		The idea of a PHP 5.7 is:

rfc:php7_foreach

2015-02-12T14:13:59+02:00

1423741602		current
Line 3:		Line 3:
	* Date: 2015-01-29		* Date: 2015-01-29
	* Author: Dmitry Stogov, dmitry@zend.com		* Author: Dmitry Stogov, dmitry@zend.com
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/php7_foreach		* First Published at: http://wiki.php.net/rfc/php7_foreach

rfc:php7timeline

2014-11-28T16:06:18+02:00

1416556986		current
Line 3:		Line 3:
	* Date: 2014-11-21		* Date: 2014-11-21
	* Author: Zeev Suraski, zeev@php.net		* Author: Zeev Suraski, zeev@php.net
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/php7timeline		* First Published at: http://wiki.php.net/rfc/php7timeline

Line 34:		Line 34:

	===== Vote ======		===== Vote ======
-	<doodle title="php7timeline" auth="zeev" voteType="single" closed="false">	+	<doodle title="php7timeline" auth="zeev" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

rfc:php8

2015-05-16T19:20:51+02:00

1431796771		current
Line 1:		Line 1:
		+	====== Proposals for PHP 8 ======
		+
		+	===== Introduction =====
	This page is a spot to list and discuss ideas for PHP 8. This is not a place to discuss features which may be accepted in the 7.X series; it is for features which require backwards compatibility breaks to achieve.		This page is a spot to list and discuss ideas for PHP 8. This is not a place to discuss features which may be accepted in the 7.X series; it is for features which require backwards compatibility breaks to achieve.

		+	===== Proposals =====
	* [[rfc:php8:merge_symbol_tables\|Merge Symbol Tables]]. This draft RFC focuses on the benefits and drawbacks to merging the class constant, property and symbol tables.		* [[rfc:php8:merge_symbol_tables\|Merge Symbol Tables]]. This draft RFC focuses on the benefits and drawbacks to merging the class constant, property and symbol tables.

rfc:php53eol

2013-02-07T22:16:24+02:00

1358187995		current
Line 3:		Line 3:
	* Date: 2012-03-02		* Date: 2012-03-02
	* Author: Pierre Joye <pierre@php.net>		* Author: Pierre Joye <pierre@php.net>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/php53eol		* First Published at: http://wiki.php.net/rfc/php53eol

Line 36:		Line 36:
	===== Vote =====		===== Vote =====
	<doodle		<doodle
-	title="Which EOL period should we choose?" auth="pajoye" voteType="single">	+	title="Which EOL period should we choose?" auth="pajoye" voteType="single" closed="true">
	* Two years, one normal fixes and one security fixes only, announce with the next 5.3 release		* Two years, one normal fixes and one security fixes only, announce with the next 5.3 release
	* Two years, one normal fixes and one security fixes only, announce with 5.5 final release		* Two years, one normal fixes and one security fixes only, announce with 5.5 final release

rfc:php56timeline

2016-01-16T05:01:29+02:00

1452680380		current
Line 3:		Line 3:
	* Date: 2015-12-07		* Date: 2015-12-07
	* Author: Zeev Suraski, zeev@php.net		* Author: Zeev Suraski, zeev@php.net
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/php56timeline		* First Published at: http://wiki.php.net/rfc/php56timeline

rfc:php57

2015-01-08T21:32:18+02:00

1420748963		current
Line 3:		Line 3:
	* Date: 2014-12-15		* Date: 2014-12-15
	* Author: Andrea Faulds, ajf@ajf.me		* Author: Andrea Faulds, ajf@ajf.me
-	* Status: Decline	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/php57		* First Published at: http://wiki.php.net/rfc/php57

rfc:php71-crypto

2016-01-10T06:05:12+02:00

1452398834		current
Line 87:		Line 87:
	* Password-Based Key Derivation: Argon2i		* Password-Based Key Derivation: Argon2i
	* OpenSSL (configurable):		* OpenSSL (configurable):
-	* Cipher: AES-128, AES-192, AES-256, Camellia-128, Camellia-192, Camellia-256	+	* Cipher: AES-128, AES-192, AES-256
	* Hash/HMAC: SHA256, SHA384, SHA512, SHA3-356, SHA3-384, SHA3-512		* Hash/HMAC: SHA256, SHA384, SHA512, SHA3-356, SHA3-384, SHA3-512
	* Public keys: ECDH over NIST P-256		* Public keys: ECDH over NIST P-256

rfc:php_engine_constant

2016-02-03T20:56:44+02:00

1454490260		current
Line 21:		Line 21:

	Additionally, we _could_ introduce a further constants to pair with the new ''PHP_ENGINE'' constant: ''PHP_ENGINE_VERSION'' (or perhaps ''PHP_ENGINE__VERSION'' and ''PHP_ENGINE_VERSION_ID'') that would be used to store the engines own version details — with the standard ''PHP_(_)VERSION(_ID)'' constants continuing to be used for compatibility.		Additionally, we _could_ introduce a further constants to pair with the new ''PHP_ENGINE'' constant: ''PHP_ENGINE_VERSION'' (or perhaps ''PHP_ENGINE__VERSION'' and ''PHP_ENGINE_VERSION_ID'') that would be used to store the engines own version details — with the standard ''PHP_(_)VERSION(_ID)'' constants continuing to be used for compatibility.
		+
		+	This would effectively make the original' ''PHP_VERSION'' and related constants indicate what version of the language spec the runtime conforms to, with PHP being the reference implementation and therefore both values would be identical. This should be standardized in the specification as the expected behavior.

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

rfc:php_ini_bcmath_default

2012-03-12T21:24:38+02:00

1331068610		current
Line 31:		Line 31:

	This will be a performance hit when enabled. Other than that though I can't think of any major problems.		This will be a performance hit when enabled. Other than that though I can't think of any major problems.
		+
		+	==== Performance ====
		+
		+	Portable applications would have to perform QA stress tests under both settings to be sure the (probably major) performance issues aren't going to kill it.
		+
		+	Or it needs to be easily turned "off" from within an app and in .htaccess
		+
		+	Even then, somebody who turns this "on" and suddenly their entire website goes down because of the performance penalty is not going to be happy...
		+
		+	Can you write some sample code to measure the performance difference between normal PHP and re-writing the sample to use BCMath?

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

	2012-03-06 Created.		2012-03-06 Created.

rfc:php_native_interface

2011-04-06T12:59:26+02:00

1243365295		current
Line 92:		Line 92:

	* Project Zero		* Project Zero
-	* Supportive	+	* Supportive (see [[http://wiki.php.net/rfc/remove_zend_api/scratchpad\|remove_zend_api/scratchpad]] for their discussion.
	* phc		* phc
	* Involved		* Involved

rfc:phpdbg

2013-12-18T02:21:45+02:00

1386752914		current
Line 194:		Line 194:
	===== Vote =====		===== Vote =====

-	<doodle title="Distribute phpdbg with PHP5.6+" auth="krakjoe" voteType="single" closed="false">	+	<doodle title="Distribute phpdbg with PHP5.6+" auth="krakjoe" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:phpng

2014-08-15T11:33:15+02:00

1408075956		current
Line 3:		Line 3:
	* Date: 2014-07-20		* Date: 2014-07-20
	* Author: Dmitry Stogov, Zeev Suraski		* Author: Dmitry Stogov, Zeev Suraski
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/phpng		* First Published at: http://wiki.php.net/rfc/phpng

rfc:phpng64

2014-05-20T17:30:10+02:00

1400599446		current
Line 11:		Line 11:
	===== Proposal =====		===== Proposal =====

-	The 64bit changes described in the following will be integrated into the phpng branch once it is more stable.	+	The 64bit changes described in the following will be added to the phpng branch once it is more stable.

	The following changes will be made:		The following changes will be made:
Line 21:		Line 21:
	The following changes will not be made:		The following changes will not be made:

-	* Use of ''size_t'' for all lengths. In particular hashtables will always use 32bit lengths. Linenos will be stored in a 32bit type. Special names (like argument or class names) will also use 32bit lengths, where possible.	+	* Use of ''size_t'' for all lengths. In particular hashtables will always use 32bit lengths. Line numbers will be stored in a 32bit type. Special names (like argument or class names) will also use 32bit lengths, where possible.

-	The expected impact memory impact of these changes is around 1%. We are okay with that.	+	The expected memory impact of these changes is around 1%. We are okay with that.

	Unclear as of now: Will we be performing renames like ''IS_LONG'' to ''IS_INT'' along the way? I prefer not (Nikita).		Unclear as of now: Will we be performing renames like ''IS_LONG'' to ''IS_INT'' along the way? I prefer not (Nikita).

rfc:phpp

2013-05-29T23:11:01+02:00

1335296868		current
Line 4:		Line 4:
	* Date: 2012-04-12		* Date: 2012-04-12
	* Author: Kris Craig <kriscraig@php.net>		* Author: Kris Craig <kriscraig@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/phpp		* First Published at: http://wiki.php.net/rfc/phpp

rfc:phpvcs

2011-04-06T12:59:26+02:00

1226582820		current
Line 4:		Line 4:
	* Date: 2008-03-29		* Date: 2008-03-29
	* Author: Gwynne Raskind		* Author: Gwynne Raskind
-	* Status: In the works	+	* Status: Accepted
-	* **Votes: (+0/-0)**	+	* **Progress: Roughly 90% implemented, see [[http://svn.php.net/]]**
-	* **Pro:**	+	* **Votes: While most people prefer a move to Git/Github, a more unanimous desire is required before such a large shift. We're sticking with the status quo and moving to SVN. A git bridge will exist.**
-	* Contra:****	+
	==== Purpose ====		==== Purpose ====

Line 92:		Line 92:

	==== Further Discussion And Reading ====		==== Further Discussion And Reading ====
		+	[[http://news.php.net/svn.migration]]
		+
	[[http://doc.php.net/php/rfc/rfc-proposal-show.php?id=8]]		[[http://doc.php.net/php/rfc/rfc-proposal-show.php?id=8]]

rfc:pickle

2014-06-14T06:44:07+02:00

1402517792		current
Line 112:		Line 112:
	* Finish the port of the binary installer		* Finish the port of the binary installer
	* server side, packagist-like system		* server side, packagist-like system
-	* write a m4/w32 ARG_* parser to fetch the configure option automatically	+	* Improve the m4/w32 ARG_* parser to fetch the configure option default values automatically, detect path options and the likes

rfc:pipe-operator

2016-07-21T02:08:31+02:00

1469057945		current
Line 25:		Line 25:
	$config = loadConfig();		$config = loadConfig();
	$dic = buildDic($config);		$dic = buildDic($config);
-	$app = getApp($dic)	+	$app = getApp($dic);
-	$router = getRouter($app)	+	$router = getRouter($app);
-	$dispatcher = getDispatcher($router, $request)	+	$dispatcher = getDispatcher($router, $request);
-	$logic = dispatchBusinessLogic($dispatcher, $request, new Response())	+	$logic = dispatchBusinessLogic($dispatcher, $request, new Response());
-	$render = renderResponse($logic)	+	$render = renderResponse($logic);
-	$psr7 = buildPsr7Response($render)	+	$psr7 = buildPsr7Response($render);
	$response =emit($psr7);		$response =emit($psr7);

Line 37:		Line 37:
	$x = loadConfig();		$x = loadConfig();
	$x = buildDic($x);		$x = buildDic($x);
-	$x = getApp($x)	+	$x = getApp($x);
-	$x = getRouter($x)	+	$x = getRouter($x);
-	$x = getDispatcher($x, $request)	+	$x = getDispatcher($x, $request);
-	$x = dispatchBusinessLogic($x, $request, new Response())	+	$x = dispatchBusinessLogic($x, $request, new Response());
-	$x = renderResponse($x)	+	$x = renderResponse($x);
-	$x = buildPsr7Response($x)	+	$x = buildPsr7Response($x);
	$response =emit($x);		$response =emit($x);

rfc:pow-operator

2014-08-11T20:24:27+02:00

1391755599		current
Line 79:		Line 79:
	===== Discussion =====		===== Discussion =====

-	> Should ''-2 <nowiki>**</nowiki> 3'' evaluate to ''9'' instead of ''-9''?	+	> Should ''-3 <nowiki>**</nowiki> 2'' evaluate to ''9'' instead of ''-9''?

	According to the following resources, the scale tips more towards having the exponent precede the unary minus:		According to the following resources, the scale tips more towards having the exponent precede the unary minus:

rfc:precise_float_value

2016-07-09T14:05:43+02:00

1466361675		current
Line 3:		Line 3:
	* Date: 2015-07-30		* Date: 2015-07-30
	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>, Jakub Zelenka <bukka@php.net>		* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>, Jakub Zelenka <bukka@php.net>
-	* Status: Accepted	+	* Status: Implemented (PHP 7.1)
	* First Published at: http://wiki.php.net/rfc/precise_float_value		* First Published at: http://wiki.php.net/rfc/precise_float_value

Line 205:		Line 205:

	===== Implementation =====		===== Implementation =====
		+
		+	Merged into php-src for PHP 7.1: https://github.com/php/php-src/commit/75b86a2
		+
	After the project is implemented, this section should contain		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 PHP manual entry for the feature

rfc:precise_session_management

2016-03-24T03:44:24+02:00

1458785977		current
Line 5:		Line 5:
	* Date Updated: 2016-01-29		* Date Updated: 2016-01-29
	* Author: Yasuo Ohgaki <yohgaki@php.net>		* Author: Yasuo Ohgaki <yohgaki@php.net>
-	* Status: Under Discussion	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/session_regenerate_id		* First Published at: http://wiki.php.net/rfc/session_regenerate_id
	* Renamed: https://wiki.php.net/rfc/precise_session_management		* Renamed: https://wiki.php.net/rfc/precise_session_management

rfc:preg_extract

2011-07-08T15:55:44+02:00

1310133295		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: preg_extract function ======
	* Version: 1.0		* Version: 1.0
	* Date: 2008-03-06		* Date: 2008-03-06

rfc:preg_replace_callback_array

2015-05-09T22:44:48+02:00

1426925054		current
Line 3:		Line 3:
	* Date: 2015-03-10		* Date: 2015-03-10
	* Author: Wei Dai, demon@php.net		* Author: Wei Dai, demon@php.net
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)
	* First Published at: https://wiki.php.net/rfc/preg_replace_callback_array		* First Published at: https://wiki.php.net/rfc/preg_replace_callback_array

rfc:property_type_hints

2015-12-20T22:53:38+02:00

1450638453		current
Line 13:		Line 13:
	The significance of type-checked properties is a given, as demonstrated by it's inclusion in Hack, as well as other recent scripting languages, including Typescript, Dart and ActionScript. The need for type-hinting is demonstrated by the widespread use of php-doc, and support for such type-hinting in modern PHP IDEs.		The significance of type-checked properties is a given, as demonstrated by it's inclusion in Hack, as well as other recent scripting languages, including Typescript, Dart and ActionScript. The need for type-hinting is demonstrated by the widespread use of php-doc, and support for such type-hinting in modern PHP IDEs.

-	The proposed syntax is compatible with that of Hack, and is a natural addition to the language, resembling the syntax set forth by otherr gruadually-typed (and statically-typed) languages.	+	The proposed syntax is compatible with that of Hack, and is a natural addition to the language, resembling the syntax set forth by other gruadually-typed (and statically-typed) languages.

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

rfc:propertygetsetsyntax-alternative-typehinting-syntax

2013-01-28T17:11:12+02:00

1358791119		current
Line 2:		Line 2:
	* Date: 2013-01-04		* Date: 2013-01-04
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Voting	+	* Status: Declined

	===== Introduction =====		===== Introduction =====
Line 163:		Line 163:
	This proposal depends on the main accessors RFC. The result of this vote is only relevant if the main RFC is accepted. As this is a language change it requires a 2/3 majority.		This proposal depends on the main accessors RFC. The result of this vote is only relevant if the main RFC is accepted. As this is a language change it requires a 2/3 majority.

-	<doodle title="Should the proposed typehinting syntax be used instead of the current one?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Should the proposed typehinting syntax be used instead of the current one?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>
		+
		+	The vote ended 3 in favor, 12 against, as such this feature is declined.

rfc:propertygetsetsyntax-as-implemented

2013-01-10T22:30:37+02:00

1357853420		current
Line 12:		Line 12:
	* [[rfc/propertygetsetsyntax-as-implemented/change-requests\|v1.1 -> v1.2 Changes]]		* [[rfc/propertygetsetsyntax-as-implemented/change-requests\|v1.1 -> v1.2 Changes]]
	* Version 1.2 Document: [[https://wiki.php.net/rfc/propertygetsetsyntax-v1.2\|v1.2 RFC]]		* Version 1.2 Document: [[https://wiki.php.net/rfc/propertygetsetsyntax-v1.2\|v1.2 RFC]]
-	* [[https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax\|Altnerative typehinting syntax proposal]]	+	* [[https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax\|Alternative typehinting syntax proposal]]

	* Fork: Available at github https://github.com/cpriest/php-src/tree/accessors		* Fork: Available at github https://github.com/cpriest/php-src/tree/accessors

rfc:propertygetsetsyntax-implementation-details

2013-01-21T20:38:54+02:00

1358430187		current
Line 43:		Line 43:
	</code>		</code>

		+	The ''zend_function''s of the accessors have the ''ZEND_ACC_ACCESSOR'' flag set.

	==== Compilation Changes ====		==== Compilation Changes ====
Line 64:		Line 65:


-	A new function flag was added ZEND_ACC_CALL_GUARD which flags a function as "being called and guarded," this was necessary to allow for parent	+	A new function flag was added ''ZEND_ACC_CALL_GUARD'' which flags a function as "being called and guarded," this was necessary to allow for parent
	accessors being able to be properly called. In the case of recursion with accessors a warning will be emitted if recursion is detected and that		accessors being able to be properly called. In the case of recursion with accessors a warning will be emitted if recursion is detected and that
	recursion is not called from the context of the validly scoped accessor.		recursion is not called from the context of the validly scoped accessor.

rfc:propertygetsetsyntax-v1.1

2012-12-30T23:17:54+02:00

1356893215		current
Line 8:		Line 8:

	==== Fork ====		==== Fork ====
-	* The changes for this RFC are available here: https://github.com/cpriest/php-src	+	* The changes for this RFC are available here: https://github.com/cpriest/php-src/tree/accessors

rfc:propertygetsetsyntax-v1.2

2013-03-31T17:19:17+02:00

1359544336		current
Line 3:		Line 3:
	* Created: 2012-12-29		* Created: 2012-12-29
	* Updated: 2013-01-17		* Updated: 2013-01-17
-	* Author: Clint Priest <phpdev at zerocue dot com>	+	* Author: Clint Priest <cpriest at php dot net>
	* Contributors: Nikita Popov		* Contributors: Nikita Popov
	* Status: Declined, Vote Failed		* Status: Declined, Vote Failed

rfc:propertygetsetsyntax

2011-12-22T16:18:07+02:00

1324566934		current
Line 542:		Line 542:
	- 2010-11-29 jbondc: Added another alternative syntax		- 2010-11-29 jbondc: Added another alternative syntax
	- 2010-12-01 Dennis Robinson: Added additional links in the "Further Reading" section		- 2010-12-01 Dennis Robinson: Added additional links in the "Further Reading" section
		+	- 2011-12-22 Dennis Robinson: Added "Implementation" section

rfc:protectedlookup

2014-04-09T01:02:54+02:00

1302087566		current
Line 4:		Line 4:
	* Author: Robin Fernandes <robinf@php.net>		* Author: Robin Fernandes <robinf@php.net>
	* First Published at: http://wiki.php.net/rfc/protectedlookup		* First Published at: http://wiki.php.net/rfc/protectedlookup
-	* Status: in the works	+	* Status: Draft (Inactive)

rfc:protocol_type_hinting

2013-09-03T14:28:35+02:00

1372339028		current
Line 3:		Line 3:
	* Date: 2013-06-25		* Date: 2013-06-25
	* Author: Anthony Ferrara <ircmaxell@php.net>		* Author: Anthony Ferrara <ircmaxell@php.net>
-	* Status: Draft	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/protocol_type_hinting		* First Published at: http://wiki.php.net/rfc/protocol_type_hinting

rfc:prototype_checks

2014-04-09T00:52:51+02:00

1323180353		current
Line 3:		Line 3:
	* Date: 2011-09-19		* Date: 2011-09-19
	* Author: Etienne Kneuss <colder@php.net>		* Author: Etienne Kneuss <colder@php.net>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/prototype_checks		* First Published at: http://wiki.php.net/rfc/prototype_checks

rfc:prototypecasting

2012-02-28T13:04:31+02:00

1330430415		current
Line 19:		Line 19:
	<code php>		<code php>
	<?php		<?php
-	function addProfile( (string) $name, (int) $age, (float) $salary) {	+	function addProfile( (string) $name, (int) $age, (float) $heightInMeters) {
		+	echo gettype($name); // "string"
		+	echo gettype($age); // "integer"
		+	echo gettype($heightInMeters); // "double"
	}		}
		+
		+	addProfile("Davey Shafik", "27", "1.77");
	?>		?>
	</code>		</code>

rfc:random-function-exceptions

2015-09-06T21:57:40+02:00

1440917570		current
Line 3:		Line 3:
	* Date: 2015-08-22		* Date: 2015-08-22
	* Author: Anthony Ferrara <ircmaxell@php.net>, Aaron Piotrowski <aaron@icicle.io>		* Author: Anthony Ferrara <ircmaxell@php.net>, Aaron Piotrowski <aaron@icicle.io>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/random-function-exceptions		* First Published at: http://wiki.php.net/rfc/random-function-exceptions

Line 58:		Line 58:

	<doodle		<doodle
-	title="Should this RFC be accepted for 7.0" auth="ircmaxell" voteType="single">	+	title="Should this RFC be accepted for 7.0" auth="ircmaxell" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:range_checks_for_64_bit

2015-08-27T18:57:01+02:00

1440436019		current
Line 3:		Line 3:
	* Date: 2015-08-24		* Date: 2015-08-24
	* Author: Anatol Belski, ab@php.net		* Author: Anatol Belski, ab@php.net
-	* Status: Draft	+	* Status: withdrawn

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

rfc:readonly_properties

2015-05-10T13:34:23+02:00

1415051914		current
Line 4:		Line 4:
	* Author: Andrea Faulds, ajf@ajf.me		* Author: Andrea Faulds, ajf@ajf.me
	* Status: Withdrawn		* Status: Withdrawn
		+	* Discussion: http://markmail.org/message/7l3ci3sboma2nlzq
	* First Published at: http://wiki.php.net/rfc/readonly_properties		* First Published at: http://wiki.php.net/rfc/readonly_properties

rfc:reclassify_e_strict

2015-04-01T11:59:45+02:00

1427299917		current
Line 2:		Line 2:
	* Date: 2015-02-22		* Date: 2015-02-22
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)

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

rfc:reflection_doccomment_annotations

2013-01-06T23:01:07+02:00

1357509206		current
Line 46:		Line 46:
	$han = new ReflectionClass("User");		$han = new ReflectionClass("User");

-	print_r($han->getAllAnnotations()); // Array( [Table] => Users )	+	print_r($han->getAnnotations()); // Array( [Table] => Users )

	print_r($han->getProperty("name")->getAnnotations()); // Array( [var] => "string", [MaxLength] => 255, [Type] => varchar )		print_r($han->getProperty("name")->getAnnotations()); // Array( [var] => "string", [MaxLength] => 255, [Type] => varchar )
Line 89:		Line 89:
	===== List of methods to implement =====		===== List of methods to implement =====

-	* getAllAnnotations()	+	* getAnnotations()
	* getAnnotation(string annotationName)		* getAnnotation(string annotationName)
	* hasAnnotation(string annotationName)		* hasAnnotation(string annotationName)

rfc:reflectionparameter-getclassname

2015-02-14T17:27:05+02:00

1422725214		current
Line 3:		Line 3:
	* Date: 2015-01-30		* Date: 2015-01-30
	* Author: Phil Sturgeon, me@philsturgeon.uk		* Author: Phil Sturgeon, me@philsturgeon.uk
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/reflectionparameter-getclassname		* First Published at: http://wiki.php.net/rfc/reflectionparameter-getclassname

rfc:reflectionparameter.typehint

2015-01-13T04:17:00+02:00

1401468232		current
Line 8:		Line 8:
	===== Introduction =====		===== Introduction =====

-	This RFC proposes improvements to the way we handle type information in reflection. This work will make it easier for writing tools that convert type information from reflection into strings. This RFC also unifies the reflection API for type information for both parameter and return types if the [[returntypehinting\|Return Type RFC]] is accepted.	+	This RFC proposes improvements to the way we handle type information in reflection. This work will make it easier for writing tools that convert type information from reflection into strings. This RFC also adds support the reflection API for type information return types if the [[returntypehinting\|Return Type RFC]] is accepted.

	===== Proposal =====		===== Proposal =====
Line 18:		Line 18:
	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====

-	5.next (5.7)	+	PHP 7

	===== New Reflection class type: ReflectionTypeAnnotation =====		===== New Reflection class type: ReflectionTypeAnnotation =====

rfc:reflectiontypeimprovements

2016-07-09T15:16:21+02:00

1467302894		current
Line 3:		Line 3:
	* Date: 2016-06-10		* Date: 2016-06-10
	* Author: Levi Morrison <levim@php.net>		* Author: Levi Morrison <levim@php.net>
-	* Status: Voting	+	* Status: Rejected
	* First Published at: https://wiki.php.net/rfc/ReflectionTypeImprovements		* First Published at: https://wiki.php.net/rfc/ReflectionTypeImprovements

Line 43:		Line 43:
	The vote is a simple yes or no for these changes. Voting opened 2016-06-30 and will close 2016-07-08.		The vote is a simple yes or no for these changes. Voting opened 2016-06-30 and will close 2016-07-08.

-	<doodle title="Accept ReflectionType Improvements RFC?" auth="levim" voteType="single" closed="false">	+	<doodle title="Accept ReflectionType Improvements RFC?" auth="levim" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:releaseprocess

2014-08-15T11:02:12+02:00

1328546730		current
Line 103:		Line 103:
	* September, RC phases, biweekly release		* September, RC phases, biweekly release
	* each RC should go through the QA before being published		* each RC should go through the QA before being published
-	* usually2 days	+	* usually 2 days
	* running the various test suites (phpt, custom real life tests, platform specific tests). Some tests need a day to run		* running the various test suites (phpt, custom real life tests, platform specific tests). Some tests need a day to run
	* November, Final		* November, Final

rfc:releaseprocessalternatives

2011-04-06T12:59:26+02:00

1290540538		current
Line 1:		Line 1:
	==== Example FORCETRANSITION time line with two majors versions ====		==== Example FORCETRANSITION time line with two majors versions ====
-	However it could happen that a new major version is desired while the active major version is still heavily used. Like what we had between php 4 and 5 or for the oldest, between php 3 and 4.	+	However it could happen that a new major version is desired while the active major version is still heavily used. Like what we had between php 4 and 5 or for the oldest, between php 3 and 4. We won't make more minor release for the oldmajor, only bugfix micro/build releases until the last oldmajor.minor gets EOLed.
	<code>		<code>
	**** pre release phase		**** pre release phase

rfc:removal-of-deprecated-features

2013-10-29T18:35:30+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 07/04 - 2010		* Date: 07/04 - 2010
	* Author: Kalle Sommer Nielsen <kalle@php.net>		* Author: Kalle Sommer Nielsen <kalle@php.net>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.4

rfc:removal_of_dead_sapis

2015-01-14T09:35:02+02:00

1421221098		current
Line 4:		Line 4:
	* Date: 2014-01-24		* Date: 2014-01-24
	* Author: Anatol Belski, <ab@php.net>		* Author: Anatol Belski, <ab@php.net>
-	* Status: Draft	+	* Status: Abandoned is favour of https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts
	* First Published at: http://wiki.php.net/rfc/removal_of_dead_sapis		* First Published at: http://wiki.php.net/rfc/removal_of_dead_sapis

rfc:removal_of_dead_sapis_and_exts

2015-04-06T23:20:35+02:00

1428355104		current
Line 393:		Line 393:

	The voting options are attached to the corresponding items. The voting starts on 2015-02-02 and ends on 2015-02-09 at 23:00 CET respectively. To be accepted/declined each vote requires 50%+1 acceptance.		The voting options are attached to the corresponding items. The voting starts on 2015-02-02 and ends on 2015-02-09 at 23:00 CET respectively. To be accepted/declined each vote requires 50%+1 acceptance.
		+
		+	===== Implementation =====
		+
		+	Implemented in PHP7, see PRE_NATIVE_TLS_MERGE and POST_NATIVE_TLS_MERGE tags.
		+
		+

rfc:remove_alternative_php_tags

2014-10-01T22:25:47+02:00

1411582064		current
Line 2:		Line 2:
	* Date: 2014-09-09		* Date: 2014-09-09
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Voting	+	* Status: Accepted
	* Targeting: PHP 7		* Targeting: PHP 7
	* Patch: https://github.com/php/php-src/pull/813		* Patch: https://github.com/php/php-src/pull/813
Line 41:		Line 41:
	===== Vote =====		===== Vote =====

-	As this is a language change a 2/3 majority is required. The vote started on 2014-09-24 and ends on 2014-10-01.	+	The vote started on 2014-09-24 and ended on 2014-10-01. The required 2/3 majority has been reached, as such this RFC is accepted.

-	<doodle title="Remove alternative PHP tags in PHP 7?" auth="nikic" voteType="single" closed="false">	+	<doodle title="Remove alternative PHP tags in PHP 7?" auth="nikic" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

rfc:remove_deprecated_functionality_in_php7

2016-07-09T14:56:05+02:00

1429892448		current
Line 2:		Line 2:
	* Date: 2014-09-11		* Date: 2014-09-11
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (PHP 7.0)
	* Targeting: PHP 7		* Targeting: PHP 7
	* Discussion: http://markmail.org/message/vcladdh5sciqjpvg		* Discussion: http://markmail.org/message/vcladdh5sciqjpvg

rfc:remove_hex_support_in_numeric_strings

2015-01-28T22:57:54+02:00

1422398359		current
Line 2:		Line 2:
	* Date: 2014-08-19		* Date: 2014-08-19
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7)
-	* Target version: PHP 7	+

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

rfc:remove_php4_constructors

2015-04-01T12:00:04+02:00

1426015200		current
Line 4:		Line 4:
	* Author: Levi Morrison <levim@php.net>		* Author: Levi Morrison <levim@php.net>
	* Contributors: Andrea Faulds <ajf@ajf.me>		* Contributors: Andrea Faulds <ajf@ajf.me>
-	* Status: Accepted	+	* Status: Deprecation Implemented (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/remove_php4_constructors		* First Published at: http://wiki.php.net/rfc/remove_php4_constructors

rfc:remove_preg_replace_eval_modifier

2012-03-13T18:31:27+02:00

1331659805		current
Line 104:		Line 104:
	===== Vote =====		===== Vote =====

-	<doodle	+	The vote ended with 23 in favor and 4 against the proposal.
-	title="Should the /e modifier be deprecated in trunk and removed at some later point in time?" auth="nikic" voteType="single">	+
-	* yes	+
-	* no	+
-	</doodle>	+

	===== Current state =====		===== Current state =====

rfc:remove_re2c_generated_files

2015-03-15T18:11:07+02:00

1426439430		current
Line 6:		Line 6:


-	===== Introduction =====	+	This should be deleted as I have changed mind about this
-	This should be deleted as it's not valid	+

rfc:remove_utf_8_decode_encode

2016-08-15T05:12:33+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Remove utf8_decode() and utf8_encode() ======
	+	* Version: 0.9
	+	* Date: 2016-08-15
	+	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/remove_utf_8_decode_encode

	+	===== Introduction =====
	+
	+	Purpose of this RFC is described in bug [[https://bugs.php.net/bug.php?id=60429\|#60429]]
	+
	+	The purpose of the functions utf8_encode and utf8_decode are time and again
	+	misunderstood and have probably caused more encoding related problems than they
	+	have solved. The biggest reason for this is their naming. Their purpose is to
	+	convert the encoding of a string from ISO-8859-1 to UTF-8, yet they are named
	+	in a way that suggests some other magical function that is necessary to work
	+	with UTF-8 text. Users looking for "UTF-8 support" in their app quickly find
	+	these functions due to their naming and use them without understanding what they
	+	do, often only testing with ASCII text which appears to work fine of first
	+	sight.
	+
	+	Why is ISO-8859-1 presumed to be the default encoding when converting to UTF-8,
	+	hence why do these functions occupy such a prominent spot in the namespace?
	+	There's simply no good reason for it.
	+
	+	The same functionality is available through iconv and mb_convert_encoding.
	+	Therefore I suggest to slowly deprecate utf8_encode and utf8_decode to clear up
	+	a recurring confusion and consolidate features into the existing, much more
	+	versatile iconv and mb_ functions.
	+
	+
	+
	+	===== Proposal =====
	+
	+	* Document utf8_decode() and utf8_encode() deprecation now.
	+	* Remove utf8_decode() and utf8_encode() from PHP 7.2.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	Programs use utf8_decode() and utf8_encode() for ISO-8859-1 to/from UTF-8 conversion must use other encoding conversion function available. e.g. mb_convert_encoding()
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	* 7.1 - Remove utf8_decode() and utf8_encode()
	+
	+	===== RFC Impact =====
	+	==== To SAPIs ====
	+	None
	+
	+	==== To Existing Extensions ====
	+	XNL module
	+
	+	==== To Opcache ====
	+	None
	+
	+	==== New Constants ====
	+	None
	+
	+	==== php.ini Defaults ====
	+	No change.
	+
	+	===== Open Issues =====
	+	None
	+
	+	===== Unaffected PHP Functionality =====
	+	Other XML module features except utf8_decode() and utf8_encode() are unaffected.
	+
	+	===== Future Scope =====
	+	None
	+
	+	===== Proposed Voting Choices =====
	+	State whether this project requires a 2/3
	+
	+	<doodle title="Remove utf8_decode() and utf8_encode() function" auth="Yasuo Ohgaki" voteType="single" closed="true">
	+	* Yes
	+	* No
	+	</doodle>
	+
	+	Vote starts: 2016/08/22
	+
	+	Vote ends: 2016/08/29 23:59:59 UTC
	+
	+
	+	===== Patches and Tests =====
	+
	+	TDB. Just functions removal. No patch.
	+
	+	===== Implementation =====
	+
	+	- the version(s) it was merged to
	+	- a link to the git commit(s)
	+	- a link to the PHP manual entry for the feature
	+
	+	===== References =====
	+
	+	* https://bugs.php.net/bug.php?id=60429
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.

rfc:remove_zend_api

2011-04-06T12:59:26+02:00

1242129752		current
Line 3:		Line 3:
	* Date: 2009-03-27		* Date: 2009-03-27
	* Author: Paul Biggar <paul.biggar@gmail.com>		* Author: Paul Biggar <paul.biggar@gmail.com>
-	* Status: Soliciting comments for 1.1	+	* **Status: Brainstorming: [[http://wiki.php.net/rfc/remove_zend_api/scratchpad]]**
-		+
-	Currently brainstorming about extensions which are tightly integrated with PHP: [[http://wiki.php.net/rfc/remove_zend_api/scratchpad]]	+

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

rfc:request-tempnam

2013-03-25T19:30:19+02:00

1353970534		current
Line 3:		Line 3:
	* Date: 2012-11-26		* Date: 2012-11-26
	* Author: Sara Golemon <pollita@php.net>		* Author: Sara Golemon <pollita@php.net>
-	* Status: Under Discussion	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/request-tempnam		* First Published at: http://wiki.php.net/rfc/request-tempnam

rfc:reserve_even_more_types_in_php_7

2015-04-06T22:26:27+02:00

1428339738		current
Line 5:		Line 5:
	* Heavily cribbed from Levi Morrison <levim@php.net>		* Heavily cribbed from Levi Morrison <levim@php.net>
	* https://wiki.php.net/rfc/reserve_more_types_in_php_7)		* https://wiki.php.net/rfc/reserve_more_types_in_php_7)
-	* Status: In Voting	+	* Status: Partially Accepted (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/reserve_even_more_types_in_php_7		* First Published at: http://wiki.php.net/rfc/reserve_even_more_types_in_php_7

Line 38:		Line 38:
	* add explicit scalar type support for parameter and return types		* add explicit scalar type support for parameter and return types
	* add union types, such as ''int\|false''		* add union types, such as ''int\|false''
		+
		+	===== Result =====
		+
		+	The following class names are now reserved:
		+
		+	* "resource"
		+	* "object"
		+	* "mixed"
		+	* "numeric"
		+
		+	The following class names have not been reserved:
		+
		+	* "scalar"

	===== Vote =====		===== Vote =====
Line 58:		Line 71:
	.		.

-	<doodle title="Reserved Type: object" auth="pollita" voteType="single" closed="false">	+	<doodle title="Reserved Type: object" auth="pollita" voteType="single" closed="True">
	* Yes		* Yes
	* No		* No

rfc:reserve_more_types_in_php_7

2015-04-01T11:59:18+02:00

1427729947		current
Line 3:		Line 3:
	* Date: 2015-02-18		* Date: 2015-02-18
	* Author: Levi Morrison <levim@php.net>		* Author: Levi Morrison <levim@php.net>
-	* Status: Accepted	+	* Status: Implemented (in PHP 7.0)
	* First Published at: http://wiki.php.net/rfc/reserve_more_types_in_php_7		* First Published at: http://wiki.php.net/rfc/reserve_more_types_in_php_7

rfc:reserve_primitives

2015-02-08T18:09:24+02:00

1423415134		current
Line 121:		Line 121:
	In all situations except the last two options, reserving primitive type names causes a BC break. The options above sketch out how we can cope with this, balancing the usefulness of being able to use these tokens and backwards compatibility on the other side.		In all situations except the last two options, reserving primitive type names causes a BC break. The options above sketch out how we can cope with this, balancing the usefulness of being able to use these tokens and backwards compatibility on the other side.

-	These frameworks would be affected (incomplete list):	+	These frameworks would be affected by reserving the word "string" (incomplete list):

	* CakePHP - ''lib/Cake/Utility/String.php''		* CakePHP - ''lib/Cake/Utility/String.php''
Line 127:		Line 127:
	* ZF2 - ''library/Zend/XmlRpc/Value/String.php''		* ZF2 - ''library/Zend/XmlRpc/Value/String.php''
	* Drupal8 - ''core/lib/Drupal/Component/Utility/String.php''		* Drupal8 - ''core/lib/Drupal/Component/Utility/String.php''
-	* XP Frameworrk - ''src/main/php/lang/types/String.class.php''	+	* XP Framework - ''src/main/php/lang/types/String.class.php''

-	This [[https://searchcode.com/?q=class+String&lan=24\|code search]] suggests various more libraries will be affected.	+	This [[https://searchcode.com/?q=class+String&lan=24\|code search for a PHP String class]] suggests various more libraries will be affected. Same goes for "Boolean", "Integer", "Int", "Float" and "Double"

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

rfc:resource_typehint

2015-11-11T02:41:30+02:00

1447206055		current
Line 1:		Line 1:
-	====== PHP RFC: Your Title Here ======	+	====== PHP RFC: Resource typehint ======
	* Version: 0.1		* Version: 0.1
	* Date: 2015-11-11		* Date: 2015-11-11

rfc:retry-keyword

2015-11-03T23:57:57+02:00

1446587904		current
Line 24:		Line 24:
	===== Proposal =====		===== Proposal =====

-	This new keywords makes what is currently somewhat of a chore into a quick and easy activity.	+	This new keyword makes what is currently somewhat of a chore into a quick and easy activity.

-	Currently in order to retry a block of code that failed with a recoverable error in user-land, the developer needs to write quite a bit of bootstap code. It forces the developer to make extra methods or functions, which are not always necessary or even helpful, and are just written to avoid copy/paste.	+	Currently in order to retry a block of code that failed with a recoverable error in user-land, the developer needs to write quite a bit of bootstrap code. It forces the developer to make extra methods or functions, which are not always necessary or even helpful, and are just written to avoid copy/paste.

	Currently		Currently
Line 124:		Line 124:

	* Ruby has the ''retry'' keyword, highlighted nicely in [[http://ruby.bastardsbook.com/chapters/exception-handling/#retry-section\|Bastards Book of Ruby: Exception and Error Handling]]		* Ruby has the ''retry'' keyword, highlighted nicely in [[http://ruby.bastardsbook.com/chapters/exception-handling/#retry-section\|Bastards Book of Ruby: Exception and Error Handling]]
-	* Spring do [[http://docs.spring.io/spring-batch/reference/html/retry.html\|some really weird stuff]] to make retry possible	+	* Spring does [[http://docs.spring.io/spring-batch/reference/html/retry.html\|some really weird stuff]] to make retry possible
	* Python third party library offers [[https://pypi.python.org/pypi/retrying\|annotations to allow methods retry]]		* Python third party library offers [[https://pypi.python.org/pypi/retrying\|annotations to allow methods retry]]

rfc:return_types

2015-02-28T00:11:39+02:00

1425015386		current
Line 1:		Line 1:
-	====== PHP RFC: Coercive Types for Function Arguments ======
-	* Version: 0.40
-	* Date: 2015-02-26
-	* Authors: Zeev Suraski <zeev@php.net>, Francois Laupretre <francois@php.net>, Dmitry Stogov <dmitry@php.net>
-	* Status: Under discussion
-	* First Published at: http://wiki.php.net/rfc/coercive_sth

-	===== Preamble =====	+	====== PHP RFC: Return Type Declarations ======
		+	* Version: 2.0
		+	* Date: 2014-03-20
		+	* Author: Levi Morrison <levim@php.net>
		+	* Status: Implemented (PHP 7.0)
		+	* First Published at: https://wiki.php.net/rfc/returntypehinting
		+	* Migrated to: https://wiki.php.net/rfc/return_types

-	This version is published as 'near-final', and with the exception of potential minor modifications, is what will be proposed for a vote.	+	===== Introduction =====
		+	Many developers would like to be able to declare the return type of a function. The basic idea of declaring a return type has been included in at least three RFCs and has been discussed in a few other places (see [[#references]]). This RFC proposes a different approach from previous RFC's to accomplish this goal in a simple way.

-	===== Background & Summary =====	+	Declaring return types has several motivators and use-cases:
		+	* Prevent sub-types from breaking the expected return type of the super-type((See [[#variance_and_signature_validation\|Variance and Signature Validation]] and [[#examples]] for more details on how this works)), especially in interfaces
		+	* Prevent unintended return values
		+	* Document return type information in a way that is not easily invalidated (unlike comments)

-	Scalar Type Hints have been a top requested feature for PHP for a very, very long time. There have been numerous attempts at introducing them to the language, all of which failed to make it into the language thus far.	+	===== Proposal =====
		+	This proposal adds an optional return type declaration to function declarations including closures, functions, generators, and methods. This RFC does not change the existing type declarations nor does it add new ones (see [[#differences_from_past_rfcs\|differences from past RFCs]]).

-	While there seems to be consensus regarding the viability and usefulness of adding Scalar Type Hints (STH), theres been a long standing debate regarding what is the correct way to implement them. The two key schools of thoughts around STH that emerged over the years are:	+	Here is a brief example of the syntax in action:
		+	<PHP>
		+	function foo(): array {
		+	return [];
		+	}
		+	</PHP>
		+	More examples can be found in the [[#examples\|Examples]] section.

-	- Strict STH. In essence, this approach conducts a very simple zval.type check on the value being passed from the caller to the callee; If theres a match the argument is accepted, otherwise rejected. Coercion is (almost) never performed, so, for instance, a callee that expects an integer argument and is passed a 32 (string) will reject it.	+	//Code which does not declare a return type will continue to work// exactly as it currently does. This RFC requires a return type to be declared only when a method inherits from a parent method that declares a return type; in all other cases it may be omitted.
-	- Dynamic (weak) STH. Unlike strict STH, dynamic STH automatically converts values which are not already of the type that is expected by the callee into that type, according to the same ruleset presently used by internal functions. That means that a callee expecting an integer that will be passed 32 (string), will successfully receive the argument, and it will be automatically converted to 32 (int). Note that existing dynamic STH rules (as they already exist for internal functions) are stricter than explicit casts. Example: a non-numeric string, like "oranges" is rejected when expecting an integer, while explicitly casting "oranges" into (int) will succeed without a notice, and result in 0.	+

-	Its important to note that in terms of the *code inside* the callee, theres absolutely no difference between the two schools of thought. In both cases, the callee can rely with absolute confidence that if it type hinted a certain argument as an int, this argument will always be an int when function execution begins. The difference is localized to the behavior surrounding the invocation of the callee by the caller, with Strict STH rejecting a lot more potential inputs, compared to Dynamic STH**.	+	==== Variance and Signature Validation ====
		+	The enforcement of the declared return type during inheritance is invariant; this means that when a sub-type overrides a parent method then the return type of the child must exactly match the parent and may not be omitted. If the parent does not declare a return type then the child is allowed to declare one.

-	Proponents of Strict STH cite numerous advantages, primarily around code safety/security. In their view, the conversion rules proposed by Dynamic STH can easily allow garbage input to be silently converted into arguments that the callee will accept but that may, in many cases, hide difficult-to-find bugs or otherwise result in unexpected behavior.	+	If a mismatch is detected during compile time (e.g. a class improperly overriding a return type) then ''E_COMPILE_ERROR'' will be issued. If a type mismatch is detected when the function returns then ''E_RECOVERABLE_ERROR'' will be issued.

-	Proponents of Dynamic STH bring up consistency with the rest of the language, including some fundamental type-juggling aspects that have been key tenets of PHP since its inception. Strict STH, in their view, is inconsistent with these tenets.	+	Covariant return types are considered to be type sound and are used in many other languages((C++, Java and others use covariant return types.)). This RFC originally proposed covariant return types but was changed to invariant because of a few issues. It is possible to add covariant return types at some point in the future.

-	This RFC proposes a composite solution, which attempts to address the main goals of both camps, dubbed Coercive STH. Coercive STH is less restrictive than simple zval.type checks, but a lot more restrictive than the conversion rules presently employed by internal functions. It attempts to strike a balance between rejecting erroneous input, and allowing valid-but-wrongly-typed input, and outlines a gradual roadmap for transitioning internal functions to this new rule-set.	+	Note that this topic of variance is about the declared return type of the function; this means that the following would be valid for either invariant or covariant return types:

-	Finally, the RFC outlines a potential future evolution of employing the new rule-set into additional parts of PHP, most notably implicit type conversions (outside the scope of this specific RFC).	+	<PHP>
		+	interface A {
		+	static function make(): A;
		+	}
		+	class B implements A {
		+	static function make(): A {
		+	return new B();
		+	}
		+	}
		+	</PHP>

		+	The class ''B'' implements ''A'' so it is therefore valid. Variance is about the allowed types when overriding the declared types:

-	===== Proposal =====	+	<PHP>
		+	interface A {
		+	static function make(): A;
		+	}
		+	class B implements A {
		+	static function make(): B { // must exactly match parent; this will error
		+	return new B();
		+	}
		+	}
		+	</PHP>

-	==== Coercion Rules ====	+	The above sample does not work because this RFC proposes only invariant return types; this could be extended in the future to be allowed.

-	A new set of coercion rules will appli to both user-land type hints as well as internal type hints. The guiding principals behind this new rulesete rules are:	+	==== Position of Type Declaration ====
		+	The two major conventions in other programming languages for placing return type information are:

-	- If the type of the value is an exact match to the type requested by the hint - allow.	+	* Before the function name
-	- If the value can be coerced to the type requested by the hint without data loss and without creation of likely unintended data - allow.	+	* After the parameter list's closing parenthesis
-	- In all other cases - reject.	+

-	=== Changes in coercion rules ===	+	The former position has been proposed in the past and the RFCs were either declined or withdrawn. One cited issue is that many developers wanted to preserve the ability to search for <php>function foo</php> to be able to find the definition for ''foo''. A recent discussion about [[http://marc.info/?t=141235344900003&r=1&w=2\|removing the function keyword]] has several comments that re-emphasized the value in preserving this.

-	We first present only the changes we introduce compared to the PHP 5 behavior.	+	The latter position is used in several languages(([[http://hacklang.org/\|Hack]], [[http://www.haskell.org\|Haskell]], [[https://golang.org/\|Go]], [[http://www.erlang.org/\|Erlang]], [[http://www.adobe.com/devnet/actionscript.html\|ActionScript]], [[http://www.typescriptlang.org/\|TypeScript]] and more all put the return type after the parameter list)); notably C++11 also places the return type after the parameter lists for certain constructs such as lambdas and auto-deducing return types.

-	^ ^ Value Type ^^^^	+	Declaring the return type after the parameter list had no shift/reduce conflicts in the parser.
-	^ Hint ^ boolean ^ int ^ float ^ string ^	+
-	^ bool \| No change \| No change \| Disabled \| Disabled \|	+
-	^ int \| Disabled \| No change \| Restricted (1) \| Restricted (1) \|	+
-	^ float \| Disabled \| No change \| No change \| No change \|	+
-	^ string \| Disabled \| No change \| No change \| No change \|	+

-	* (1) Significant digits after the decimal points are now rejected when converting to int.	+	==== Returning by Reference ====

-	And the changes in the way numeric strings are handled :	+	This RFC does not change the location of ''&'' when returning by reference. The following examples are valid:
		+	<PHP>
		+	function &array_sort(array &$data) {
		+	return $data;
		+	}

-	* Trailing blanks are supported as before,	+	function &array_sort(array &$data): array {
-	* but non-blank trailing characters now cause the data to be rejected ("7 dogs" case)	+	return $data;
		+	}
		+	</PHP>

-	=== Final ruleset ===	+	==== Disallowing NULL on Return Types ====
		+	Consider the following function:

-	Here are the rules we get when applying these changes to the rules currently used in PHP 5 :	+	<PHP>
		+	function foo(): DateTime {
		+	return null; // invalid
		+	}
		+	</PHP>

-	^ ^ Value Type ^^^^	+	It declares that it will return ''DateTime'' but returns ''null''; this type of situation is common in many languages including PHP. By design this RFC does not allow ''null'' to be returned in this situation for two reasons:
-	^ Hint ^ boolean ^ int ^ float ^ string ^	+
-	*^ bool \| Yes \| Yes \| Reject \| Reject \|**	+
-	^ int \| Reject \| Yes \| Only if no DL† \| Numeric integer string only‡ \|	+
-	^ float \| Reject \| Only if no DL† \| Yes \| Numeric string only‡ \|	+
-	^ string \| Reject \| Yes \| Yes \| Yes \|	+

-	* Coercion from int to bool is done using the same rules that apply in the rest of PHP; 0 coerces to false; Any other value coerces to true.	+	- This aligns with current parameter type behavior. When parameters have a type declared, a value of ''null'' is not allowed ((Except when the parameter has a ''null'' default)).
		+	- Allowing ''null'' by default works against the purpose of type declarations. Type declarations make it easier to reason about the surrounding code. If ''null'' was allowed the programmer would always have to worry about the ''null'' case.

-	† Float to int coercion will be accepted only if there are no significant digits after the decimal point. E.g. 7.0 will be coerced to 7, but 7.3 will be rejected. Int to float coercion will be accepted only if the integer value can be represented without loss of accuracy using a floating point number. Extremely large integers (with absolute value larger than 2^52) will be rejected.	+	The [[rfc:nullable_types\|Nullable Types RFC]] addresses this shortcoming and more.

-	‡ Numeric strings may be converted to int or float types, only in case there is no loss in data or accuracy. Leading zeroes, as well as leading and trailing whitespaces are accepted. Other non-numeric trailing data will be rejected. For int hints, numeric strings with significant digits after the decimal point will be rejected. For floating point hints, integer values that cannot be represented without loss of accuracy (exceed 2^52 in absolute value) will be rejected as well.	+	==== Methods which cannot declare return types ====

-	==== Handling of non-scalar values ====	+	Class constructors, destructors and clone methods may not declare return types. Their respective error messages are:

-	Generally speaking, coercion from non-scalar values into scalar type hints is not supported and will be rejected, with few exceptions.	+	* ''<nowiki>Fatal error: Constructor %s::%s() cannot declare a return type in %s on line %s</nowiki>''
		+	* ''<nowiki>Fatal error: Destructor %s::__destruct() cannot declare a return type in %s on line %s</nowiki>''
		+	* ''<nowiki>Fatal error: %s::__clone() cannot declare a return type in %s on line %s</nowiki>''

-	Arrays and resources will always be rejected as valid inputs for scalar type hinted arguments .	+	==== Examples ====
-	Objects will always be rejected as valid inputs for scalar type hinted arguments, with one exception - an object with a __toString() method will be accepted for string type hint.	+	Here are some snippets of both valid and invalid usage.
-	Nulls will be rejected as valid inputs for scalar type hinted arguments when using user-land type hints, but presently accepted for internal functions. See the 'Changes to Internal Functions' section for more information.	+

		+	=== Examples of Valid Use ===
		+	<PHP>
		+	// Overriding a method that did not have a return type:
		+	interface Comment {}
		+	interface CommentsIterator extends Iterator {
		+	function current(): Comment;
		+	}
		+	</PHP>
		+	<PHP>
		+	// Using a generator:

-	==== User-land Additions ====	+	interface Collection extends IteratorAggregate {
		+	function getIterator(): Iterator;
		+	}

-	This RFC proposes to introduce four new type hints into PHP – int, float, string and bool. These new hints will adhere to the new coercion rules detailed above. Values that cannot be accepted per the coercion rules above, will result in E_RECOVERABLE_ERROR being triggered. Note that if the [[https://wiki.php.net/rfc/engine_exceptions_for_php7\|Exceptions in the Engine]] RFC is accepted, this will throw an exception instead, making recovery simpler and more straightforward.	+	class SomeCollection implements Collection {
		+	function getIterator(): Iterator {
		+	foreach ($this->data as $key => $value) {
		+	yield $key => $value;
		+	}
		+	}
		+	}
		+	</PHP>

-	These type hints can be used for function arguments, as well as for return values, as described in the [[https://wiki.php.net/rfc/return_types\|Return Type Declarations]] RFC. In both cases, they are handled exactly the same way.	+	=== Examples of Invalid Use ===

-	No type declaration for resources is added, as this would prevent moving from resources to objects for existing extensions which some have already done (e.g. GMP).	+	The error messages are taken from the current patch.
		+	----

-	==== Changes to Internal Functions ====	+	<PHP>
		+	// Covariant return-type:

-	This RFC proposes to bring the rule-set described in the last section to internal functions as well, through updates to the zend_parse_parameters() function.	+	interface Collection {
		+	function map(callable $fn): Collection;
		+	}

-	However, given that unlike the introduction of STH - which is a new, previously unused feature that will (for the most part) not affect existing code - changes to what internal functions would be willing to accept could have substantial compatibility implications.	+	interface Set extends Collection {
		+	function map(callable $fn): Set;
		+	}
		+	</PHP>
		+	''Fatal error: Declaration of Set::map() must be compatible with Collection::map(callable $fn): Collection in %s on line %d''
		+	----
		+	<PHP>
		+	// Returned type does not match the type declaration

-	To mitigate the risk of compatibility breakage being introduced between PHP 5.6 and 7.0, two mitigation steps are proposed:	+	function get_config(): array {
		+	return 42;
		+	}
		+	get_config();
		+	</PHP>
		+	''Catchable fatal error: Return value of get_config() must be of the type array, integer returned in %s on line %d''

-	- To allow developers time to adhere to the updated rules, a two-staged migration strategy will be used. At the first stage - in PHP 7, conversions which were supported in the past and are no longer allowed due to the new rules, will emit E_DEPRECATED warnings, but will still allow the values in and convert them using the same rules as PHP 5. When it is considered safe (PHP 8 or later), the E_DEPRECATED warnings will be upgraded to E_RECOVERABLE_ERROR errors (or exceptions, depending on the engine standards). The two-staged would provide users ample time to update their code as needed to fit the new, more restrictive rule-set.	+	----
-	- Unlike user-land scalar type hints, internal functions will accept nulls as valid scalars. Based on preliminary testing, this is an extremely common use case, most often used in conjunction with uninitialized values. Disallowing it - language-wide for all internal functions - may be too big of a shift. Therefore, internal functions receiving a NULL (non-)value for a scalar will accept it, and convert it to 0 or an empty string in the same way PHP 5 does.	+
-	- As we don't clearly define a date for switching E_DEPRECATE to fatal errors, the RFC states that such decision cannot, in any cases, be made before a delay of 5 years after the first public release of a PHP distribution containing the STH features described here. This statement is voted upon as the rest of the RFC. So, it cannot be violated without a new vote on this specific subject. This statement is provided as a guarantee to the developers that they will have ample time to fix their code.	+

-	=== Examples for conversions now deprecated for Internal Functions ===	+	<PHP>
		+	// Int is not a valid type declaration

-	Here are examples of conversions which, while still providing the same results as in PHP 5, now also raise an E_DEPRECATED error :	+	function answer(): int {
		+	return 42;
		+	}
		+	answer();
		+	</PHP>
		+	''Catchable fatal error: Return value of answer() must be an instance of int, integer returned in %s on line %d''

-	false -> int # No more conversion from bool	+	----
-	true -> string # No more conversion from bool	+
-	5 -> int # 7.5 cannot be converted to an integer without data loss	+
-	"8.2" -> int # "8.2" cannot be converted to an integer without data loss	+
-	4.3 -> bool # No more conversion from float to bool	+
-	"foo" -> bool # No more conversion from string to bool	+
-	"7 dogs" -> int # Trailing characters no longer supported	+
-	" 0" -> int # Leading spaces no longer supported	+
-	"12 " -> int # Trailing spaces no longer supported	+

-	==== Potential Future Changes to Implicit Casting Rules ====	+	<PHP>
		+	// Cannot return null with a return type declaration

-	While outside the scope of this RFC, the introduction of the new coercive-yet-more-restrictive rule-set may be considered for additional areas in PHP, most notably implicit casting.	+	function foo(): DateTime {
-	For example, today, the result of "Apples" + "Oranges" is 0, because the + operator implicitly casts anything into a number. It could be imagined that in the future, the + operator will accept only values that would fit into an int or float STH, and reject others. Users would still be able to use permissive explicit casting ($foo = (int) "Apples"; would still assign 0 into $foo), but the risk sometimes associated with implicit casting will be eliminated.	+	return null;
		+	}
		+	foo();
		+	</PHP>
		+	''Catchable fatal error: Return value of foo() must be an instance of DateTime, null returned in %s on line %d''

		+	----

-	===== Comparison to the other RFC =====	+	<PHP>
		+	// Missing return type on override

-	Numerous community members have invested substantial effort into creating another comprehensive RFC, that proposes to introduce STH into PHP [[https://wiki.php.net/rfc/scalar_type_hints_v5\|Scalar Type Hints RFC v0.5 ("Dual Mode RFC")]]. However, we believe the proposal in this RFC is better, for several different reasons:	+	class User {}

-	- Single Mode. Even though the Dual Mode RFC presents a novel idea about how to allow developers to choose which mode they'd like to use, and use different modes in different parts of the app, it still introduces the burden of two different modes. Two different rule-sets that need to be learned, may increase the language's complexity. Further, the two sets can cause the same functions to behave differently depending on where they're being called, and potentially a new class of bugs stemming from developers not realizing which mode they're in in a particular file. This RFC is unaffected by these issues, as it presents a single, composite rule set.	+	interface UserGateway {
-	- Too strict may lead to too lax. In the Dual Mode RFC, when in Strict mode, in many cases, functions would reject values that, semantically, are acceptable. For example, a "32" (string) value coming back from an integer column in a database table, would not be accepted as valid input for a function expecting an integer. Since semantically the developer is interested in this argument-passing succeeding, they would have the choice of either removing the integer STH altogether, or, more likely, explicitly casting the value into an integer. This would have the opposite of the desired outcome of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed, and would happily convert "100 dogs", "Apples" and even arrays and booleans into an integer. Further, since already today, internal functions employ coercion rules that are more restrictive than PHP's explicit casting, pushing people towards explicit casting will actually make things worse in case developers opt for explicit casting as they pass values in an internal function call.	+	function find($id): User;
-	- Smooth integration with Data Sources. PHP uses strings extensively across the language, and in most cases, data sources always feed data into PHP as strings. PHP applications rely extensively on internal type juggling to convert that string-based data according to the needed context. Strict zval.type based STH effectively eliminates this behavior, moving the burden of worrying about type conversion to the user. The solution proposed in this RFC allows code that relies on type coercion to Just Work when the values are sensible, but fail (and appropriately warn the developer) otherwise.	+	}

		+	class UserGateway_MySql implements UserGateway {
		+	// must return User or subtype of User
		+	function find($id) {
		+	return new User();
		+	}
		+	}
		+	</PHP>
		+	''Fatal error: Declaration of UserGateway_MySql::find() must be compatible with UserGateway::find($id): User in %s on line %d''

-	In addition, there appear to be numerous misconception about benefits of strict type hinting, that to the best of our (deep) understanding of the associated technologies, aren't really there:	+	----

-	- Performance. There's complete consensus that there are no tangible performance differences between the strict and coercive typing. The difference is that strict typing would block scenarios that coercive typing would allow; But that's a difference in behavior, not performance.	+	<PHP>
-	- AOT/JIT implications. It is our position that there is no difference at all between strict and coercive typing in terms of potential future AOT/JIT development - none at all. In both the case of strict and coercive STH, we can have full confidence that the value inside the callee is of the requested type; And in both the case of strict and coercive STH, we can't make any assumptions about what is the type of value that the caller is passing as an argument. Again, the difference is only that strict typing may reject values that coercive typing may accept; But the very same checks need to be conducted in both cases; The very same type inference can be used in both cases to potentially optimize these checks away; Etc.	+	// Generator return types can only be declared as Generator, Iterator or Traversable (compile time check)
-	- Static Analysis. It is the position of several Strict STH proponents that Strict STH can help static analysis in certain cases. For the same reasons mentioned above about JIT, we don't believe that is the case - although it's possible that Strict Typing may be able to help static analysis in certain edge cases. However, it is our belief that even if that is true, Static Analyzers need to be designed for Languages, rather than Languages being designed for Static Analyzers.	+

		+	function foo(): array {
		+	yield [];
		+	}
		+	</PHP>
		+	''Fatal error: Generators may only declare a return type of Generator, Iterator or Traversable, %s is not permitted in %s on line %d''

-	===== Backward Incompatible Changes =====	+
-	Given the change to the acceptable values into a wide range of internal functions, this RFC is likely to result in a substantial number of newly introduced E_DEPRECATED warnings in internal function invocations, although those can be easily suppressed. When E_DEPRECATED is replaced with E_RECOVERABLE_ERROR in a future PHP version, users will be forced to update their code and 'clean it up' before they can upgrade.	+	==== Multiple Return Types ====
-	Also, the newly-introduced type hints (int, float, string and bool) will no longer permitted as class/interface/trait names (including with use and class_alias)	+	This proposal specifically does not allow declaring multiple return types; this is out of the scope of this RFC and would require a separate RFC if desired.
		+
		+	If you want to use multiple return types in the meantime, simply omit a return type declaration and rely on PHP's excellent dynamic nature.
		+
		+	==== Reflection ====
		+
		+	This RFC purposefully omits reflection support as there is an open RFC about improving type information in reflection: https://wiki.php.net/rfc/reflectionparameter.typehint
		+
		+	==== Differences from Past RFCs ====
		+	This proposal differs from past RFCs in several key ways:
		+
		+	* The return type is positioned after the parameter list. See [[#position_of_type_declaration\|Position of Type Declaration]] for more information about this decision.
		+	* We keep the current type options. Past proposals have suggested new types such as ''void'', ''int'', ''string'' or ''scalar''; this RFC does not include any new types. Note that it does allow ''self'' and ''parent'' to be used as return types.
		+	* We keep the current search patterns. You can still search for <php>function foo</php> to find <php>foo</php>'s definition; all previous RFCs broke this common workflow.
		+	* We allow return type declarations on all function types. Will Fitch's proposal suggested that we allow it for methods only.
		+	* We do not modify or add keywords. Past RFCs have proposed new keywords such as ''nullable'' and more. We still require the <php>function</php> keyword.
		+
		+	===== Other Impact =====
		+
		+	==== On Backward Compatiblity ====
		+	This RFC is backwards compatible with previous PHP releases.
		+
		+	==== On SAPIs ====
		+	There is no impact on any SAPI.
		+
		+	==== On Existing Extensions =====
		+	The structs ''zend_function'' and ''zend_op_array'' have been changed; extensions that work directly with these structs may be impacted.
		+
		+	==== On Performance ====
		+	An informal test indicates that performance has not seriously degraded. More formal performance testing can be done before voting phase.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
-	7.0	+	This RFC targets PHP 7.
		+
		+	===== Vote =====
		+	This RFC modifies the PHP language syntax and therefore requires a two-third majority of votes.
		+
		+	Should return types as outlined in this RFC be added to the PHP language? Voting will end on January 23, 2015.
		+	<doodle title="Typed Returns" auth="levim" voteType="single" closed="true">
		+	* Yes
		+	* No
		+	</doodle>
		+
		+	===== Patches and Tests =====
		+
		+	Dmitry and I have updated the implementation to a more current master branch here: https://github.com/php/php-src/pull/997
		+
		+	This RFC was merged into the master branch (PHP 7) in commit [[https://git.php.net/?p=php-src.git;a=commit;h=638d0cb7531525201e00577d5a77f1da3f84811e\|638d0cb7531525201e00577d5a77f1da3f84811e]].
		+
		+	===== Future Work =====
		+	Ideas for future work which are out of the scope of this RFC include:
		+
		+	* Allow functions to declare that they do not return anything at all (''void'' in Java and C)
		+	* Allow nullable types (such as <php>?DateTime</php>). This is discussed in the [[rfc:nullable_types\|Nullable Types]] RFC.
		+	* Improve parameter variance. Currently parameter types are invariant while they could be contravariant. Change the E_STRICT on mismatching parameter types to E_COMPILE_ERROR.
		+	* Improve runtime performance by doing type analysis.
		+	* Update documentation to use the new return type syntax.
		+
		+	===== References =====
		+	* [[rfc:returntypehint2\|Method Return Type-hints]] by Will Fitch; 2011. [[http://marc.info/?t=132443368800001&r=1&w=2\|Mail Archive]].
		+	* [[rfc:returntypehint\|Return Type-hint]] by Felipe; 2010. [[http://marc.info/?l=php-internals&m=128036818909738&w=2\|Mail Archive]]
		+	* [[rfc:typehint\|Return value and parameter type hint]] by Felipe; 2008. [[http://marc.info/?l=php-internals&m=120753976214848&w=2\|Mail Archive]].
		+	* [[http://derickrethans.nl/files/meeting-notes.html#type-hinted-properties-and-return-values\|Type-hinted properties and return values]] from meeting notes in Paris; Nov 2005.
		+
		+	In the meeting in Paris on November 2005 it was decided that PHP should have return type declarations and some suggestions were made for syntax. Suggestion 5 is nearly compatible with this RFC; however, it requires the addition of a new token ''T_RETURNS''. This RFC opted for a syntax that does not require additional tokens so ''returns'' was replaced by a colon.
		+
		+	The following (tiny) patch would allow the syntax in suggestion 5 to be used alongside the current syntax. This RFC does not propose that both versions of syntax should be used; the patch just shows how similar this RFC is to that suggestion from 2005.

-	===== Glossary =====	+	https://gist.github.com/krakjoe/f54f6ba37e3eeab5f705

-	* STH - Scalar Type Hints. Code structures designed to provide information to PHP regarding the nature of an argument that a function expects.	+	===== Changelog =====
-	* JIT - Just In Time (Compilation). In the context of PHP - selective translation of PHP opcodes into machine code while the code is already running, while potentially taking advantage of information known only at runtime.	+
-	* AOT - Ahead Of Time (Compilation). Compiling PHP opcodes into machine code before it executes it.	+
-	* Static Analysis - Analyzing code without running it, attempting to derive conclusions about security, performance, etc.	+

-	===== Proposed Voting Choices =====	+	* v1.1: Target PHP 7 instead of PHP 5.7
-	The voting choices would be yes/no.	+	* v1.2: Disallow return types for constructors, destructors and clone methods.
-	The RFC proposes a very substantial change to PHP's coercion rules, which may evolve to affect implicit typing in the future.	+	* v1.3: Rework Reflection support to use new ''ReflectionType'' class
-	It absolutely requires a 2/3 majority, with the hope of reaching as close as possible to consensus.	+	* v1.3.1: Rename ''ReflectionType::IS_''* constants to ''TYPE_'', rename ''->getKind()''* to ''->getTypeConstant()''
		+	* v2.0: Change to invariant return types and omit reflection support

rfc:returntypehint

2011-04-06T12:59:26+02:00

1280364285		current
Line 116:		Line 116:

	$func = new ReflectionMethod('foo::test');		$func = new ReflectionMethod('foo::test');
-	var_dump($func->getReturnType()); // "Test"	+	var_dump($func->getReturnTypeHint()); // "Test"
-	var_dump($func->returnsObject()); // true	+	var_dump($func->returnsObject()); // true
-	var_dump($func->getReturnClass()); // "Test"	+
	</code>		</code>

Line 131:		Line 130:

	$func = new ReflectionFunction('abc');		$func = new ReflectionFunction('abc');
-	var_dump($func->getReturnType()); // scalar	+	var_dump($func->getReturnTypeHint()); // scalar
-	var_dump($func->returnsScalar()); // true	+	var_dump($func->returnsScalar()); // true
	</code>		</code>

		+	=== Using "self" as type ===
		+
		+	<code php>
		+	<?php
		+
		+	class foo {
		+	function self bar() {
		+	return new foo;
		+	}
		+	}
		+
		+	$func = new ReflectionMethod('foo::bar');
		+	var_dump($func->getReturnTypeHint()); // foo
		+	var_dump($func->returnsObject()); // true
		+	</code>

	===== Patch =====		===== Patch =====

rfc:returntypehint2

2013-02-13T22:13:53+02:00

1355868279		current
Line 3:		Line 3:
	* Date: 2011-12-13		* Date: 2011-12-13
	* Author: Will Fitch <will.fitch@gmail.com>		* Author: Will Fitch <will.fitch@gmail.com>
-	* Status: Under Discussion	+	* Status: Withdrawn

rfc:returntypehinting

2015-01-14T01:14:23+02:00

1421193638		current
Line 1:		Line 1:
-		+	This RFC has moved to [[https://wiki.php.net/rfc/return_types]].
-	====== PHP RFC: Return Type Declarations ======	+
-	* Version: 1.4	+
-	* Date: 2014-03-20	+
-	* Author: Levi Morrison <levim@php.net>	+
-	* Status: Under Discussion	+
-	* First Published at: https://wiki.php.net/rfc/returntypehinting	+
-		+
-	===== Introduction =====	+
-	Many developers would like to be able to declare the return type of a function. The basic idea of declaring a return type has been included in at least three RFCs and has been discussed in a few other places (see [[#references]]). This RFC proposes a different approach from previous RFC's to accomplish this goal in a simple way.	+
-		+
-	Declaring return types has several motivators and use-cases:	+
-	* Prevent sub-types from breaking the expected return type of the super-type((See [[#variance_and_signature_validation\|Variance and Signature Validation]] and [[#examples]] for more details on how this works)), especially in interfaces	+
-	* Prevent unintended return types	+
-	* Document return type information in a way that is not easily invalidated (unlike comments)	+
-		+
-	===== Proposal =====	+
-	This proposal adds an optional return type declaration to function declarations including closures, functions, generators, interface method declarations and class declarations. This RFC does not change the existing type declarations nor does it add new ones (see [[#differences_from_past_rfcs\|differences from past RFCs]]).	+
-		+
-	Here is a brief example of the syntax in action:	+
-	<PHP>	+
-	function foo(): array {	+
-	return [];	+
-	}	+
-	</PHP>	+
-	More examples can be found in the [[#examples\|Examples]] section.	+
-		+
-	//Code which does not declare a return type will continue to work// exactly as it currently does. This RFC requires a return type to be declared only when a method inherits from a parent method that declares a return type; in all other cases it may be omitted.	+
-		+
-	==== Variance and Signature Validation ====	+
-	The enforcement of the declared return type during inheritance is invariant; this means that when a sub-type overrides a parent method then the return type of the child must exactly match the parent and may not be omitted. If the parent does not declare a return type then the child is allowed to declare one.	+
-		+
-	If a mismatch is detected during compile time (e.g. a class improperly overriding a return type) then ''E_COMPILE_ERROR'' will be issued. If a type mismatch is detected when the function returns then ''E_RECOVERABLE_ERROR'' will be issued.	+
-		+
-	Covariant return types are considered to be type sound and are used in many other languages((C++, Java and others use covariant return types.)). This RFC originally proposed covariant return types but was changed to invariant because of a few issues. It is possible to add covariant return types at some point in the future.	+
-		+
-	Note that this topic of variance is about the declared return type of the function; this means that the following would be valid for either invariant or covariant return types:	+
-		+
-	<PHP>	+
-	interface A {	+
-	static function make(): A;	+
-	}	+
-	class B implements A {	+
-	static function make(): A {	+
-	return new B();	+
-	}	+
-	}	+
-	</PHP>	+
-		+
-	The class ''B'' implements ''A'' so it is therefore valid. Variance is about the allowed types when overriding the declared types:	+
-		+
-	<PHP>	+
-	interface A {	+
-	static function make(): A;	+
-	}	+
-	class B implements A {	+
-	static function make(): B { // must exactly match parent; this will error	+
-	return new B();	+
-	}	+
-	}	+
-	</PHP>	+
-		+
-	The above sample does not work because this RFC proposes only invariant return types; this could be extended in the future to be allowed.	+
-		+
-	==== Position of Type Declaration ====	+
-	The two major conventions in other programming languages for placing return type information are:	+
-		+
-	* Before the function name	+
-	* After the parameter list's closing parenthesis	+
-		+
-	The former position has been proposed in the past and the RFCs were either declined or withdrawn. One cited issue is that many developers wanted to preserve the ability to search for <php>function foo</php> to be able to find the definition for ''foo''. A recent discussion about [[http://marc.info/?t=141235344900003&r=1&w=2\|removing the function keyword]] has several comments that re-emphasized the value in preserving this.	+
-		+
-	The latter position is used in several languages(([[http://hacklang.org/\|Hack]], [[http://www.haskell.org\|Haskell]], [[https://golang.org/\|Go]], [[http://www.erlang.org/\|Erlang]], [[http://www.adobe.com/devnet/actionscript.html\|ActionScript]], [[http://www.typescriptlang.org/\|TypeScript]] and more all put the return type after the parameter list)); notably C++11 also places the return type after the parameter lists for certain constructs such as lambdas and auto-deducing return types.	+
-		+
-	Declaring the return type after the parameter list had no shift/reduce conflicts in the parser.	+
-		+
-	==== Returning by Reference ====	+
-		+
-	This RFC does not change the location of ''&'' when returning by reference. The following examples are valid:	+
-	<PHP>	+
-	function &array_sort(array &$data) {	+
-	return $data;	+
-	}	+
-		+
-	function &array_sort(array &$data): array {	+
-	return $data;	+
-	}	+
-	</PHP>	+
-		+
-	==== Disallowing NULL on Return Types ====	+
-	Consider the following function:	+
-		+
-	<PHP>	+
-	function foo(): DateTime {	+
-	return null; // invalid	+
-	}	+
-	</PHP>	+
-		+
-	It declares that it will return ''DateTime'' but returns ''null''; this type of situation is common in many languages including PHP. By design this RFC does not allow ''null'' to be returned in this situation for two reasons:	+
-		+
-	- This aligns with current parameter type behavior. When parameters have a type declared, a value of ''null'' is not allowed ((Except when the parameter has a ''null'' default)).	+
-	- Allowing ''null'' by default works against the purpose of type declarations. Type declarations make it easier to reason about the surrounding code. If ''null'' was allowed the programmer would always have to worry about the ''null'' case.	+
-		+
-	The [[rfc:nullable_typehints\|Nullable Types RFC]] addresses this shortcoming and more.	+
-		+
-	==== Methods which cannot declare return types ====	+
-		+
-	Class constructors, destructors and clone methods may not declare return types. Their respective error messages are:	+
-		+
-	* ''<nowiki>Fatal error: Constructor %s::%s() cannot declare a return type in %s on line %s</nowiki>''	+
-	* ''<nowiki>Fatal error: Destructor %s::__destruct() cannot declare a return type in %s on line %s</nowiki>''	+
-	* ''<nowiki>Fatal error: %s::__clone() cannot declare a return type in %s on line %s</nowiki>''	+
-		+
-	==== Examples ====	+
-	Here are some snippets of both valid and invalid usage.	+
-		+
-	=== Examples of Valid Use ===	+
-	<PHP>	+
-	// Overriding a method that did not have a return type:	+
-	interface Comment {}	+
-	interface CommentsIterator extends Iterator {	+
-	function current(): Comment;	+
-	}	+
-	</PHP>	+
-	<PHP>	+
-	// Using a generator:	+
-		+
-	interface Collection extends IteratorAggregate {	+
-	function getIterator(): Iterator;	+
-	}	+
-		+
-	class SomeCollection implements Collection {	+
-	function getIterator(): Iterator {	+
-	foreach ($this->data as $key => $value) {	+
-	yield $key => $value;	+
-	}	+
-	}	+
-	}	+
-	</PHP>	+
-		+
-	=== Examples of Invalid Use ===	+
-		+
-	The error messages are taken from the current patch.	+
-	----	+
-		+
-	<PHP>	+
-	// Covariant return-type:	+
-		+
-	interface Collection {	+
-	function map(callable $fn): Collection;	+
-	}	+
-		+
-	interface Set extends Collection {	+
-	function map(callable $fn): Set;	+
-	}	+
-	</PHP>	+
-	''Fatal error: Declaration of Set::map() must be compatible with Collection::map(callable $fn): Collection in %s on line %d''	+
-	----	+
-	<PHP>	+
-	// Returned type does not match the type declaration	+
-		+
-	function get_config(): array {	+
-	return 42;	+
-	}	+
-	get_config();	+
-	</PHP>	+
-	''Catchable fatal error: The function get_config was expected to return an array and returned an integer in %s on line %d''	+
-		+
-	----	+
-		+
-	<PHP>	+
-	// Int is not a valid type declaration	+
-		+
-	function answer(): int {	+
-	return 42;	+
-	}	+
-	answer();	+
-	</PHP>	+
-	''Catchable fatal error: The function answer was expected to return an object of class int and returned an integer in %s on line %d''	+
-		+
-	----	+
-		+
-	<PHP>	+
-	// Cannot return null with a return type declaration	+
-		+
-	function foo(): DateTime {	+
-	return null;	+
-	}	+
-	foo();	+
-	</PHP>	+
-	''Catchable fatal error: The function foo was expected to return an object of class DateTime and returned null in %s on line %d''	+
-		+
-	----	+
-		+
-	<PHP>	+
-	// Missing return type on override	+
-		+
-	class User {}	+
-		+
-	interface UserGateway {	+
-	function find($id): User;	+
-	}	+
-		+
-	class UserGateway_MySql implements UserGateway {	+
-	// must return User or subtype of User	+
-	function find($id) {	+
-	return new User();	+
-	}	+
-	}	+
-	</PHP>	+
-	''Fatal error: Declaration of UserGateway_MySql::find should be compatible with UserGateway::find($id): User, return type missing in %s on line %d''	+
-		+
-	----	+
-		+
-	<PHP>	+
-	// Generator return types can only be declared as Generator, Iterator or Traversable (compile time check)	+
-		+
-	function foo(): array {	+
-	yield [];	+
-	}	+
-	</PHP>	+
-	''Fatal error: Generators may only declare a return type of Generator, Iterator or Traversable, %s is not permitted in %s on line %d''	+
-		+
-		+
-	==== Multiple Return Types ====	+
-	This proposal specifically does not allow declaring multiple return types; this is out of the scope of this RFC and would require a separate RFC if desired.	+
-		+
-	If you want to use multiple return types, simply omit a return type declaration and rely on PHP's excellent dynamic nature.	+
-		+
-	==== Reflection ====	+
-		+
-	This RFC purposefully omits reflection support as there is an open RFC about improving type information in reflection: https://wiki.php.net/rfc/reflectionparameter.typehint	+
-		+
-	==== Differences from Past RFCs ====	+
-	This proposal differs from past RFCs in several key ways:	+
-		+
-	* The return type is positioned after the parameter list. See [[#position_of_type_declaration\|Position of Type Declaration]] for more information about this decision.	+
-	* We keep the current type options. Past proposals have suggested new types such as ''void'', ''int'', ''string'' or ''scalar''; this RFC does not include any new types. Note that it does allow ''self'' and ''parent'' to be used as return types.	+
-	* We keep the current search patterns. You can still search for <php>function foo</php> to find <php>foo</php>'s definition; all previous RFCs broke this common workflow.	+
-	* We allow return type declarations on all function types. Will Fitch's proposal suggested that we allow it for methods only.	+
-	* We do not modify or add keywords. Past RFCs have proposed new keywords such as ''nullable'' and more. We still require the <php>function</php> keyword.	+
-		+
-	===== Other Impact =====	+
-		+
-	==== On Backward Compatiblity ====	+
-	This RFC is backwards compatible with previous PHP releases.	+
-		+
-	==== On SAPIs ====	+
-	There is no impact on any SAPI.	+
-		+
-	==== On Existing Extensions =====	+
-	The structs ''zend_function'' and ''zend_op_array'' have been changed; extensions that work directly with these structs may be impacted.	+
-		+
-	==== On Performance ====	+
-	An informal test indicates that performance has not seriously degraded. More formal performance testing can be done before voting phase.	+
-		+
-	===== Proposed PHP Version(s) =====	+
-	This RFC targets PHP 7.	+
-		+
-	===== Vote =====	+
-	This RFC modifies the PHP language syntax and therefore requires a two-third majority of votes.	+
-		+
-	<del>Should return types as outlined in this RFC be added to the PHP language? Voting will end on November 14th, 2014.</del>	+
-	A bug was found during the voting period that will require enough changes to how the RFC works that voting has been cancelled.	+
-	<doodle title="Return Types" auth="levim" voteType="single" closed="true">	+
-	* Yes	+
-	* No	+
-	</doodle>	+
-		+
-	===== Patches and Tests =====	+
-		+
-	Dmitry and I have updated the implementation to a more current master branch here: https://github.com/php/php-src/pull/997	+
-		+
-	===== Future Work =====	+
-	Ideas for future work which are out of the scope of this RFC include:	+
-		+
-	* Allowing functions to declare that they do not return anything at all (''void'')	+
-	* Allowing nullable types (such as <php>?DateTime</php>). This is discussed in a related RFC: [[rfc:nullable_typehints\|Declaring Nullable Types]]	+
-	* Improving parameter variance. Currently parameter types are invariant while they could be contravariant.	+
-	* Improving runtime performance by doing type analysis.	+
-	* Updating documentation to use the new return type syntax.	+
-		+
-	===== References =====	+
-	* [[rfc:returntypehint2\|Method Return Type-hints]] by Will Fitch; 2011. [[http://marc.info/?t=132443368800001&r=1&w=2\|Mail Archive]].	+
-	* [[rfc:returntypehint\|Return Type-hint]] by Felipe; 2010. [[http://marc.info/?l=php-internals&m=128036818909738&w=2\|Mail Archive]]	+
-	* [[rfc:typehint\|Return value and parameter type hint]] by Felipe; 2008. [[http://marc.info/?l=php-internals&m=120753976214848&w=2\|Mail Archive]].	+
-	* [[http://derickrethans.nl/files/meeting-notes.html#type-hinted-properties-and-return-values\|Type-hinted properties and return values]] from meeting notes in Paris; Nov 2005.	+
-		+
-	In the meeting in Paris on November 2005 it was decided that PHP should have return type declarations and some suggestions were made for syntax. Suggestion 5 is nearly compatible with this RFC; however, it requires the addition of a new token ''T_RETURNS''. This RFC opted for a syntax that does not require additional tokens so ''returns'' was replaced by a colon.	+
-		+
-	The following (tiny) patch would allow the syntax in suggestion 5 to be used alongside the current syntax. This RFC does not propose that both versions of syntax should be used; the patch just shows how similar this RFC is to that suggestion from 2005.	+
-		+
-	https://gist.github.com/krakjoe/f54f6ba37e3eeab5f705	+
-		+
-	===== Changelog =====	+
-		+
-	* v1.1: RFC now targets PHP 7.	+
-	* v1.2: Disallow return types for constructors, destructors and clone methods.	+
-	* v1.3: Reworked Reflection support to use new ''ReflectionType'' class	+
-	* v1.3.1: Renamed ''ReflectionType::IS_''* constants to ''TYPE_''*, renamed ''->getKind()'' to ''->getTypeConstant()''	+
-	* v1.4: Change to invariant return types and omit reflection support	+

rfc:revisit-trailing-comma-function-args

2015-11-03T20:18:42+02:00

1444275185		current
Line 3:		Line 3:
	* Date: 2015-10-07		* Date: 2015-10-07
	* Author: Sammy Kaye Powers, me@sammyk.me		* Author: Sammy Kaye Powers, me@sammyk.me
-	* Status: Draft	+	* Status: Withdrawn in favor of [[https://wiki.php.net/rfc/list-syntax-trailing-commas\|Trailing Commas In List Syntax]] RFC
	* First Published at: https://wiki.php.net/rfc/trailing-comma-function-args		* First Published at: https://wiki.php.net/rfc/trailing-comma-function-args

rfc:rfc.third-party-editing

2016-05-13T03:47:48+02:00

1463103665		current
Line 15:		Line 15:

	If taken advantage of (and it would be optional to all parties), then not only does this provide a unified and consistent place to find established arguments during the voting phase, it ensures a historical record of the discussion in a more accessible format than searching mail archives.		If taken advantage of (and it would be optional to all parties), then not only does this provide a unified and consistent place to find established arguments during the voting phase, it ensures a historical record of the discussion in a more accessible format than searching mail archives.
		+
		+	Note that point 5 of https://wiki.php.net/rfc/howto already calls for updating RFCs with arguments made on the list. This proposal seeks to extend point 5:
		+
		+	* Codify how summaries be presented into a rough format
		+	* Update the default template to encourage RFC proponents to actually DO it.
		+	* Grant implicit permission for parties other than the RFC author to make a class of edits to an RFC without explicit permission

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

rfc:ripples

2013-10-30T14:33:14+02:00

1383139975		current
Line 73:		Line 73:
	}		}

-	} catch (DataDecodeException $esex) {	+	} catch (DataDecodeException $dde) {
	/* this is exceptional */		/* this is exceptional */
	/* nothing can be done to recover execution */		/* nothing can be done to recover execution */
	}		}
-	} dam (SocketReadRipple $sex) {	+	} dam (SocketReadRipple $sr) {

	}		}
	}		}
-	} dam (SocketDisconnectRipple $se) {	+	} dam (SocketDisconnectRipple $sd) {

	}		}

rfc:rng_fixes

2016-08-08T17:37:21+02:00

1468627991		current
Line 3:		Line 3:
	* Date: 2016-05-03		* Date: 2016-05-03
	* Author: Leigh T <leigh@php.net>		* Author: Leigh T <leigh@php.net>
-	* Status: Accepted	+	* Status: Implemented (PHP 7.1)
	* First Published at: https://wiki.php.net/rfc/rng_fixes		* First Published at: https://wiki.php.net/rfc/rng_fixes

Line 120:		Line 120:
	===== Implementation =====		===== Implementation =====

		+	https://github.com/php/php-src/commit/ab834f4

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

rfc:rounding

2011-04-06T12:59:26+02:00

1219593036		current
Line 3:		Line 3:
	* Date: 2008-08-23		* Date: 2008-08-23
	* Author: Christian Seiler <chris_se@gmx.net>		* Author: Christian Seiler <chris_se@gmx.net>
-	* Status: Under Discussion	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/rounding		* First Published at: http://wiki.php.net/rfc/rounding

Line 274:		Line 274:
	in a platform-independent way. The GNU C library offers the _FPU_SETCW and		in a platform-independent way. The GNU C library offers the _FPU_SETCW and
	_FPU_GETCW macros in fpu_control.h while on Windows Systems a function named		_FPU_GETCW macros in fpu_control.h while on Windows Systems a function named
-	_controlfp is available for this job.	+	_controlfp is available for this job. FreeBSD provides fpsetprec() and other
		+	Operating Systems that run on x86 require inline assembly.

	Please note that zend_strtod() is also affected by this problem: On systems		Please note that zend_strtod() is also affected by this problem: On systems
Line 394:		Line 395:
	==== Building an abstraction layer for FP control register manipulation ====		==== Building an abstraction layer for FP control register manipulation ====

-	In a first step, my patch introduces 3 macros:	+	See http://www.christian-seiler.de/projekte/fpmath/ for further information
		+	on how to ensure double precision on different architectures, operating
		+	systems and with different compilers.

-	* _ZEND_FPU_CW_DECLARE	+	This proposal proposes to wrap the above abstraction into the following
-	* _ZEND_FPU_CW_SET	+	macros:
-	* _ZEND_FPU_CW_RESTORE	+

-	The DECLARE macro declares certain necessary variables, the SET macro modifies	+	* ZEND_FLOAT_DECLARE
-	the FPU control word so that double precision is used for calculation and	+	* ZEND_FLOAT_ENSURE()
-	RESTORE restores the previous state of the control word. The following example	+	* ZEND_FLOAT_RESTORE()
-	illustrates how these macros are to be used:	+	* ZEND_FLOAT_RETURN(val)

-	<code c>	+	These will be defined in Zend/zend_float.h.
-	double somefunction (double val)	+
-	{	+
-	_ZEND_FPU_CW_DECLARE;	+
-	double foo;	+
-		+
-	_ZEND_FPU_CW_SET;	+
-		+
-	/* some calculations... */	+
-	foo = val / 100.0;	+
-		+
-	*/ ... /*	+
-		+
-	_ZEND_FPU_CW_RESTORE;	+
-	return foo;	+
-	}	+
-	</code>	+
-		+
-	These macros expand to the correct versions for each platform or to NOPs if	+
-	the method for the corresponding platform could not be determined.	+

	==== Fix of zend_strtod ====		==== Fix of zend_strtod ====
Line 440:		Line 423:
	different results.		different results.

-	For this reason, my patch also fixes zend_strtod() by adding the _ZEND_FPU_CW	+	For this reason, my patch also fixes zend_strtod() by adding the proposed
	macros to the function. Then, C and PHP will yield the same results on all		macros to the function. Then, C and PHP will yield the same results on all
	platforms (that support IEEE 754 arithmetics anyway).		platforms (that support IEEE 754 arithmetics anyway).
Line 451:		Line 434:
	=== Usage of FP control word manipulation ===		=== Usage of FP control word manipulation ===

-	The round function uses the new _ZEND_FPU_CW macros in order to ensure double	+	The round function uses the new ZEND_FLOAT macros in order to ensure double
	precision arithmetics within the function body. This will make sure the final		precision arithmetics within the function body. This will make sure the final
	division works properly.		division works properly.
Line 525:		Line 508:
	==== Patch =====		==== Patch =====

-	The patch is available under	+	The patch was already applied to PHP_5_3 and HEAD.
-	[[http://www.christian-seiler.de/temp/php/2008-08-23-rounding/rounding-5.3-1.patch]].	+
-	It applies against the current CVS branch of 5.3, porting it to HEAD should	+
-	be extremely trivial (since this only affects math-related stuff).	+
-		+
-	I tested the patch under Linux 32 bit x86, Linux 64 bit x86_64 and Windows	+
-	32 bit x86. Please note that MinGW does not define _controlfp_s but does	+
-	define _controlfp. Thus I added a conditional ifdef to use _controlfp instead	+
-	if _controlfp_s is not present. This is not relevant now but may be relevant	+
-	when CMake is used as build system for PHP and thus PHP starts to support	+
-	MinGW.	+

-	The _ZEND_FPU_CW macros are currently defined in zend_strtod.h, but there may	+	I tested the patch under Linux 32 bit x86, Linux 64 bit x86_64, Windows
-	be a better place for that. Also, the configure checks for those makros are	+	32 bit x86 and FreeBSD 32 bit x86. Additionally, the macros themselves were
-	currently in ext/standard/config.{m4,w32} while they are probably better	+	tested on various platforms (see the above link for details).
-	located somewhere else.	+

	===== Comparison with the 2004 proposal =====		===== Comparison with the 2004 proposal =====
Line 599:		Line 571:
	===== Changelog =====		===== Changelog =====

		+	* 2008-12-02 Christian Seiler: Updated to current situation
	* 2008-08-23 Christian Seiler: Created RFC		* 2008-08-23 Christian Seiler: Created RFC

rfc:runtimecache

2013-10-29T18:27:47+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2010-05-17		* Date: 2010-05-17
	* Author: Dmitry Stogov <dmitry@zend.com>		* Author: Dmitry Stogov <dmitry@zend.com>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.4
	* First Published at: http://wiki.php.net/rfc/runtimecache		* First Published at: http://wiki.php.net/rfc/runtimecache

rfc:safe_cast

2014-11-29T22:20:06+02:00

1417295986		current
Line 110:		Line 110:
	==== Vote ====		==== Vote ====

-	Voting opened 2014-11-19 and ends 2014-11-29.	+	Voting opened 2014-11-19 and ended 2014-11-29.

	<doodle title="Should the Safe Casting Functions RFC be accepted, and the patch merged into master?" auth="ajf" voteType="single" closed="true">		<doodle title="Should the Safe Casting Functions RFC be accepted, and the patch merged into master?" auth="ajf" voteType="single" closed="true">

rfc:scalar_type_hinting_with_cast

2014-09-15T15:06:22+02:00

1410716390		current
Line 1:		Line 1:
	====== Request for Comments: Scalar Type Hinting With Casts ======		====== Request for Comments: Scalar Type Hinting With Casts ======
	* Version: 0.1.9.1		* Version: 0.1.9.1
-	* Date: 2012-07-03 (reopened 2014-07-13, latest update 2014-09-14)	+	* Date: 2012-07-03 (reopened 2014-07-13, latest update 2014-09-14, withdrawn 2014-09-15)
	* Author: Anthony Ferrara <ircmaxell@php.net> (original)		* Author: Anthony Ferrara <ircmaxell@php.net> (original)
	* Contributors: Andrea Faulds <ajf@ajf.me> (current maintainer)		* Contributors: Andrea Faulds <ajf@ajf.me> (current maintainer)
-	* Status: Under Discussion (previously Withdrawn then reopened)	+	* Status: Withdrawn (previously Withdrawn then reopened)
	* First Published at: http://wiki.php.net/rfc/scalar_type_hinting_with_casts		* First Published at: http://wiki.php.net/rfc/scalar_type_hinting_with_casts

rfc:scalar_type_hints

2015-09-30T05:08:10+02:00

1424034493		current
Line 1:		Line 1:
	====== PHP RFC: Scalar Type Hints ======		====== PHP RFC: Scalar Type Hints ======
	* Version: 0.3.1		* Version: 0.3.1
-	* Date: 2014-12-14 (initial draft; put Under Discussion 2014-12-31; version 0.2 created 2015-01-13; withdrawn 2015-01-15)	+	* Date: 2014-12-14 (initial draft; put Under Discussion 2014-12-31; version 0.2 created 2015-01-13; withdrawn 2015-02-15)
	* Author: Andrea Faulds, ajf@ajf.me		* Author: Andrea Faulds, ajf@ajf.me
	* Status: Withdrawn		* Status: Withdrawn

rfc:scalar_type_hints_v5

2015-03-20T23:28:58+02:00

1426539602		current
Line 3:		Line 3:
	* Date: 2015-02-18		* Date: 2015-02-18
	* Author: Anthony Ferrara <ircmaxell@php.net> (original Andrea Faulds, ajf@ajf.me)		* Author: Anthony Ferrara <ircmaxell@php.net> (original Andrea Faulds, ajf@ajf.me)
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/scalar_type_hints_v5		* First Published at: http://wiki.php.net/rfc/scalar_type_hints_v5
	* Forked From: http://wiki.php.net/rfc/scalar_type_hints		* Forked From: http://wiki.php.net/rfc/scalar_type_hints

rfc:scalar_type_hints_v_0_1

2015-02-06T10:24:55+02:00

1423214673		current
Line 14:		Line 14:
	> Do we like strict type hinting with declare() switch in addition?		> Do we like strict type hinting with declare() switch in addition?

-	** It's also possible to adjust standard conversion rules to make them more safe, but this is also additional question. Lets move forward by small steps.	+	It's also possible to adjust standard conversion rules to make them more safe, but this is also additional question. Lets move forward by small steps.

	Few minor voting questions were added.		Few minor voting questions were added.

rfc:script_only_include

2015-03-01T05:39:20+02:00

1424939850		current
Line 4:		Line 4:
	* Modified: 2015-02-26		* Modified: 2015-02-26
	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>		* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>
-	* Status: Voting	+	* Status: Discussion
	* First Published at: http://wiki.php.net/rfc/script_and_script_once		* First Published at: http://wiki.php.net/rfc/script_and_script_once
	* Renamed to: http://wiki.php.net/rfc/script_path		* Renamed to: http://wiki.php.net/rfc/script_path
Line 215:		Line 215:
	Requires 2/3 "yes" to pass. Vote ends 2015/3/12.		Requires 2/3 "yes" to pass. Vote ends 2015/3/12.

-	<doodle title="Introduce script inclusion protection?" auth="yohgaki" voteType="single" closed="false">	+	<doodle title="Introduce script inclusion protection?" auth="yohgaki" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:second_arg_to_preg_callback

2013-05-04T15:51:39+02:00

1367675425		current
Line 1:		Line 1:

-	====== PHP RFC: Your Title Here ======	+	====== PHP RFC: Add an Second argument to callback of preg_replace_callback ======
	* Version: 1.0		* Version: 1.0
	* Date: 2013-05-04		* Date: 2013-05-04

rfc:secure-html-escape

2014-03-06T21:23:17+02:00

1394137374		current
Line 68:		Line 68:
	VOTE: 2014/02/17 - 2014/02/24		VOTE: 2014/02/17 - 2014/02/24

-	<doodle title="Add / escape and Make ENT_QUOTES default" auth="yohgaki" voteType="single" closed="false">	+	<doodle title="Add / escape and Make ENT_QUOTES default" auth="yohgaki" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:secure-session-options-by-default

2014-05-12T09:58:51+02:00

1394681823		current
Line 1:		Line 1:

	====== PHP RFC: Secure Session Module Options/Internal by Default======		====== PHP RFC: Secure Session Module Options/Internal by Default======
-	* Version: 0.10	+	* Version: 0.11
	* Created: 2014-02-01		* Created: 2014-02-01
-	* Modified: 2014-03-13	+	* Modified: 2014-05-12
	* Author: Yasuo Ohgaki, yohgaki@ohgaki.net		* Author: Yasuo Ohgaki, yohgaki@ohgaki.net
	* Status: Under Discussion		* Status: Under Discussion
Line 24:		Line 24:
	NIST [[http://csrc.nist.gov/groups/ST/hash/policy_2006.html\|suggests]] not to use SHA-1 for "applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010." Files save handler detects session ID collision (PHP 5.5 and later). Therefore it is out of NIST requirement scope for small sites, but collision detection is up to save handlers.		NIST [[http://csrc.nist.gov/groups/ST/hash/policy_2006.html\|suggests]] not to use SHA-1 for "applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010." Files save handler detects session ID collision (PHP 5.5 and later). Therefore it is out of NIST requirement scope for small sites, but collision detection is up to save handlers.

-	"sha256" could be unavailable. Session module fallback to SHA-1 in this case. (E_WARNING error raised for this)	+	"sha256" is Hash extension function. Hash extension is built by default, but "sha256" could be unavailable. Session module raises E_ERROR if Hash extension is unavailable.

	entropy_length=64 entropy_lengh=32 is too short for SHA-256. Default to 64.		entropy_length=64 entropy_lengh=32 is too short for SHA-256. Default to 64.

-	Detect collision via PS_VALIDATE_FUNC() When session ID is generated, collision could be checked by PS_VALIDATE_FUNC() if it is available. Check collision in session module instead of save handler module. (Easier use_strict_mode adoption)


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

-	use_script_mode=on: Do not accept user provided session ID. User may send obsolete and/or attacker provided session ID. This prevents these invalid session ID. Applications that assume certain session ID for data sharing/etc would not work with strict mode. Users may turn off this by themselves.	+	use_strict_mode=on: Do not accept user provided session ID. User may send obsolete and/or attacker provided session ID. This prevents these invalid session ID. Applications that assume certain session ID for data sharing/etc would not work with strict mode. Users may turn off at their own risks.

	cookie_httponly=on: JavaScript cannot access session ID cookie. Even when web app has JavaScript injection vulnerability, session ID cannot be stolen. JavaScript injection vulnerability is the most common issue of web apps. Applications that uses session ID as CSRF protection key would be affected. However, use of session ID as CSRF key is bad practice. Session ID could be stolen by BREACH attack even with HTTPS, for example.		cookie_httponly=on: JavaScript cannot access session ID cookie. Even when web app has JavaScript injection vulnerability, session ID cannot be stolen. JavaScript injection vulnerability is the most common issue of web apps. Applications that uses session ID as CSRF protection key would be affected. However, use of session ID as CSRF key is bad practice. Session ID could be stolen by BREACH attack even with HTTPS, for example.

-	hash_function="sha256": Longer session ID string. NIST suggests to use SHA-2 or stronger hash for security related features. If session database has limited storage, session ID cannot be stored. Users should use weaker hash or modify database schema in this case.	+	hash_function="sha256": Longer session ID string. NIST suggests to use SHA-2 or stronger hash for security related features. If session database has limited storage, session ID cannot be stored. Users should use weaker hash or modify database schema in this case. Hash extension could be unavailable. If "sha256" is not usable (not compiled or compiled as DL module), E_ERROR is raised and script stops.


Line 54:		Line 53:
	* php.ini-production values		* php.ini-production values

-	use_script_mode=on, cookie_httponly=on, hash_function=sha256, entropy_length=64 for all	+	use_strict_mode=on, cookie_httponly=on, hash_function=sha256, entropy_length=64 for all


Line 63:		Line 62:

	* When use of HTTPS becomes dominant, session.cookie_secure=on should be used.		* When use of HTTPS becomes dominant, session.cookie_secure=on should be used.
-	* Build ext/hash always	+	* Build ext/hash always. If SHA-256(Hash extension which is built by default) is not available, session raises E_ERROR for it.
		+	* Detect collision via PS_VALIDATE_FUNC() When session ID is generated, collision could be checked by PS_VALIDATE_FUNC() if it is available. Check collision in session module instead of save handler module. (Easier use_strict_mode adoption)

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

rfc:secure_serialization

2015-12-30T21:46:55+02:00

1451507983		current
Line 20:		Line 20:
	===== Proposal =====		===== Proposal =====

-	* Add secure_serialize() and secure_unserialize() supports message authentication code generation/validation and expiration.	+	* Add serialize_mhac() and unserialize_mhac() supports message authentication code generation/validation and expiration.

	<code php>		<code php>
-	string secure_serialize(mixed $data_to_be_serialized , string $secret_key [, int $ttl=1800 [,bool $session_only=TRUE]])	+	string serialize_mhac(mixed $data_to_be_serialized , string $secret_key [, int $ttl=1800 [,bool $session_only=TRUE]])
-	mixed secure_unserialize(mixed $data_to_be_unserialized , mixed $secret_keys)	+	mixed unserialize_mhac(mixed $data_to_be_unserialized , mixed $secret_keys)
	</code>		</code>


-	==== How secure_serialize() works ====	+	==== How serialize_mhac() works ====

	Pseudo code		Pseudo code
Line 69:		Line 69:


-	==== How secure_unserialize() works ====	+	==== How unserialize_mhac() works ====

	Pseudo code		Pseudo code
	<code php>		<code php>
-	function secure_unserialize(string $data_to_be_unserialized, mixed $secret_key) : mixed {	+	function unserialize_mhac(string $data_to_be_unserialized, mixed $secret_key) : mixed {
	if (strlen($secret_key) < 32) {		if (strlen($secret_key) < 32) {
	trigger_error('Too short secret key');		trigger_error('Too short secret key');
Line 158:		Line 158:
	If session module stores old session ID, automatic fallback to old session ID may be supported.		If session module stores old session ID, automatic fallback to old session ID may be supported.

-	Compatibility functions for older releases may be implemented as PHP script.	+	Encryption is more secure than authentication code. Implement serialize_crypt/unserialize_crypt when standard encryption module is introduced.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

rfc:secure_unserialize

2015-04-06T22:57:04+02:00

1416723513		current
Line 3:		Line 3:
	* Date: 2013-03-29		* Date: 2013-03-29
	* Author: Stas Malyshev, stas@php.net		* Author: Stas Malyshev, stas@php.net
-	* Status: Voting	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/secure_unserialize		* First Published at: http://wiki.php.net/rfc/secure_unserialize
	* Patch: https://github.com/php/php-src/pull/315		* Patch: https://github.com/php/php-src/pull/315

rfc:sendrecvmsg

2013-06-25T05:31:54+02:00

1361434654		current
Line 3:		Line 3:
	* Date: 2013-01-22		* Date: 2013-01-22
	* Author: Gustavo Lopes <cataphract@php.net>		* Author: Gustavo Lopes <cataphract@php.net>
-	* Status: Implemented	+	* Status: Implemented, PHP 5.5.0
	* First Published at: http://wiki.php.net/rfc/sendrecvmsg		* First Published at: http://wiki.php.net/rfc/sendrecvmsg

rfc:session-create-id

2016-08-15T22:44:34+02:00

1471215809		current
Line 8:		Line 8:

	===== Introduction =====		===== Introduction =====
-	Session ID is created by session internal bin_to_reabable() function. bin_to_readable() creates readable string from binary data depending. New session_create_id() uses bin_to_readable() to create user defined session ID string. Session ID may use 'a'-'z', 'A'-'Z', ',', '-'. Without session_create_id(), user has to implement their own bin_to_readable() in user land.	+	Session ID is created by session internal bin_to_readable() function. bin_to_readable() creates readable string from binary data depending. New session_create_id() uses bin_to_readable() to create user defined session ID string. Session ID may use 'a'-'z', 'A'-'Z', ',', '-'. Without session_create_id(), user has to implement their own bin_to_readable() in user land.

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

rfc:session-gc

2016-08-10T11:35:29+02:00

1470821499		current
Line 43:		Line 43:
	Vote starts: 2016/08/10 - Vote ends: 2016/08/17 23:59:59 UTC		Vote starts: 2016/08/10 - Vote ends: 2016/08/17 23:59:59 UTC

-	<doodle title="Add session_gc() function" auth="yohgaki" voteType="single" closed="false">	+	<doodle title="Add session_gc() function" auth="Yasuo Ohgaki" voteType="single" closed="false">
-	* Yes	+	* Yes
-	* No	+	* No
	</doodle>		</doodle>

rfc:session-id-without-hashing

2016-08-12T05:37:29+02:00

1470735126		current
Line 131:		Line 131:
	This matches session.hash_func=0 and session.hash_bits_per_character=5 used since PHP 5.3.		This matches session.hash_func=0 and session.hash_bits_per_character=5 used since PHP 5.3.

-	- the version(s) it was merged to	+	- the version(s) it was merged to PHP 7.1
	- a link to the git commit(s)		- a link to the git commit(s)
		+	- http://git.php.net/?p=php-src.git;a=commitdiff;h=3467526a65bfb15eaf9ec49a0b5673b84e26bca4
	- a link to the PHP manual entry:		- a link to the PHP manual entry:
	- http://svn.php.net/viewvc?view=revision&revision=339678		- http://svn.php.net/viewvc?view=revision&revision=339678

rfc:session-lock-ini

2014-03-18T11:49:22+02:00

1394137744		current
Line 94:		Line 94:


-	===== Proposal 2 - lazy_wirte =====	+	===== Proposal 2 - lazy_write =====

	Introduce lazy_write option to session_start() that enable/disable lazy session data writing.		Introduce lazy_write option to session_start() that enable/disable lazy session data writing.

rfc:session-oo

2011-09-14T00:33:58+02:00

1314469210		current
Line 3:		Line 3:
	* Date: 2011-06-20		* Date: 2011-06-20
	* Author: Arpad Ray <arpad@php.net>		* Author: Arpad Ray <arpad@php.net>
-	* Status: Accepted, [[https://wiki.php.net/rfc/session-oo/vote\|Voting results]]	+	* Status: Implemented in PHP 5.4, [[https://wiki.php.net/rfc/session-oo/vote\|Voting results]]
	* First Published at: http://wiki.php.net/rfc/session-oo		* First Published at: http://wiki.php.net/rfc/session-oo
	* Original discussion: http://marc.info/?l=php-internals&m=125886685408121&w=2		* Original discussion: http://marc.info/?l=php-internals&m=125886685408121&w=2

rfc:session-read_only-lazy_write

2014-04-21T13:05:06+02:00

1397126892		current
Line 4:		Line 4:
	* Date: 2014-03-14		* Date: 2014-03-14
	* Author: Andrey Andreev, narf@devilix.net		* Author: Andrey Andreev, narf@devilix.net
-	* Status: Voting	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/session-read_only-lazy_write		* First Published at: http://wiki.php.net/rfc/session-read_only-lazy_write

rfc:session-use-strict-mode

2016-07-28T20:29:09+02:00

1468891356		current
Line 3:		Line 3:
	* Date: 2016-07-05		* Date: 2016-07-05
	* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>		* Author: Yasuo Ohgaki <yohgaki@ohgaki.net>
-	* Status: Voting	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/session-use-strict-mode		* First Published at: http://wiki.php.net/rfc/session-use-strict-mode

rfc:session.user.return-value

2014-06-24T19:51:52+02:00

1402420776		current
Line 46:		Line 46:
	===== Vote =====		===== Vote =====

-	<doodle title="Fix custom session save handler using the patch as written" auth="user" voteType="multi" closed="false">	+	<doodle title="Fix custom session save handler using the patch as written" auth="user" voteType="multi" closed="true">
	* Yes		* Yes
	* No		* No
Line 52:		Line 52:


-	<doodle title="Which version?" auth="user" voteType="multi" closed="false">	+	<doodle title="Which version?" auth="user" voteType="multi" closed="true">
	* 5.6 or later		* 5.6 or later
	* 5.7 or later		* 5.7 or later

rfc:session_regenerate_id

2015-03-21T02:23:31+02:00

1426894426		current
Line 7:		Line 7:
	* Status: Under Discussion		* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/session_regenerate_id		* First Published at: http://wiki.php.net/rfc/session_regenerate_id
		+	* Renamed: https://wiki.php.net/rfc/precise_session_management

	===== Introduction =====		===== Introduction =====
		+
		+	This RFC is renamed. Refer to the latest
		+
		+	https://wiki.php.net/rfc/precise_session_management
		+
		+

	Keeping HTTP session as secure as possible is what the session manager's task. Session manager can improve HTTP session security without user code modification while keeping compatibility with existing applications. Please note that this RFC is for session manager behavior.		Keeping HTTP session as secure as possible is what the session manager's task. Session manager can improve HTTP session security without user code modification while keeping compatibility with existing applications. Please note that this RFC is for session manager behavior.

rfc:session_upload_progress

2011-04-06T12:59:26+02:00

1262985105		current
Line 3:		Line 3:
	* Date: 2008-09-08		* Date: 2008-09-08
	* Author: Arnaud Le Blanc <arnaud.lb@gmail.com>		* Author: Arnaud Le Blanc <arnaud.lb@gmail.com>
-	* Status: Implemented (PHP ≥ 6.0)	+	* Status: Implemented (trunk)
	* First Published at: http://wiki.php.net/rfc/session_upload_progress		* First Published at: http://wiki.php.net/rfc/session_upload_progress
	* Patch: http://arnaud.lb.s3.amazonaws.com/session_upload_progress.patch		* Patch: http://arnaud.lb.s3.amazonaws.com/session_upload_progress.patch
Line 14:		Line 14:
	==== Upload progress in sessions ====		==== Upload progress in sessions ====

-	The patch allows to store upload progress informations in session variables. These informations can be retrieved by an other script while the upload is still in progress, allowing to provide feedback to the user.	+	The patch allows the session extension to hook into the file upload feature in order to provide upload progress information through session variables. These informations can be retrieved by a script while the upload is still in progress, allowing to provide feedback to the user.

-	Implementing this in the sessions extension makes this feature available to every one.	+	Implementing this in the sessions extension makes this feature available to every one and makes the different storage backends available for this purpose.

-	Using the session extension for this purpose also allows to use the different storage backends available.	+	The feature comes with some ini settings, working just like APC's ones:

-	The patch comes with some ini settings, working just like APC's ones:	+	* session.upload_progress.enabled[=1] : Enables/disables the feature
		+	* session.upload_progress.cleanup[=1] : Cleanup progress data from session as soon as all post data has been read (recommended)
		+	* session.upload_progress.prefix[=upload_progress_] : Progress data will be stored in _SESSION[session.upload_progress.prefix . _POST[session.upload_progress.name]]
		+	* session.upload_progress.name[=PHP_SESSION_UPLOAD_PROGRESS] : If no _POST[session.upload_progress.name] is set, the feature will not be enabled
		+	* session.upload_progress.freq[=1%] : Update session data every session.upload_progress.freq bytes uploaded. If the value is postfixed with '%', it will be interpreted as a percentage of the total post content length.
		+	* session.upload_progress.min_freq[=1.0] : Minimum delay between updates, in seconds

-	* session.upload_progress.enabled[=1]	+	When session.upload_progress.enabled is set to 1 and $_POST[session.upload_progress.name] is set and non-empty, upload informations are stored in $_SESSION[session.upload_progress.prefix . $_POST[session.upload_progress.name]]. Otherwise nothing will be done.
-	* session.upload_progress.prefix[=upload_progress_]	+
-	* session.upload_progress.name[=PHP_SESSION_UPLOAD_PROGRESS]	+
-	* session.upload_progress.freq[=1%]	+
-	* session.upload_progress.min_freq[=0.0]	+

-	When session.upload_progress.enabled is set to 1, and $_POST[session.upload_progress.name] is set and non-empty, upload informations are stored in $_SESSION[session.upload_progress.prefix . $_POST[session.upload_progress.name]].	+	The session.upload_progress.freq and session.upload_progress.min_freq settings control how often the session data is updated. freq can be given in bytes (e.g. 100) or in percentage (e.g. 1%) of the size of the POST content length. min_freq is given in seconds (e.g. 0.5) and is the minimum interval between two updates. With a reasonable amount for these two settings, the feature has mostly no overhead.
-		+
-	$_POST[session.upload_progress.name] allows to follow multiple uploading-requests on the same session at the same time. Nothing will be done if it is not set or empty, so that session.upload_progress.enabled can be left to 1 without overhead (also, the upload hook is never called on non multipart/form-data requests).	+
-		+
-	The session.upload_progress.prefix is used to avoid conflicts with existing session vars.	+
-		+
-	The session.upload_progress.freq and session.upload_progress.min_freq settings control how often the session data will be updated. freq can be given in bytes (e.g. 100) or in percentage (e.g. 1%) of the size of the POST content length. min_freq is given in seconds (e.g. 0.5) and is the minimum interval between two updates. With a reasonable amount for these two settings, the patch will have mostly no overhead.	+
-		+
-	The patch also allows to follow multiple files in the same request. Each file will have its own $_FILES-like array with name, tmp_name, error, bytes processed, etc.	+

	The data stored in the session will looks like this:		The data stored in the session will looks like this:
Line 84:		Line 77:
	The current patch also allows to cancel an upload by setting the "cancel_upload" key to true in the progress data (e.g. $_SESSION["upload_progress_123"]["cancel_upload"] = true;).		The current patch also allows to cancel an upload by setting the "cancel_upload" key to true in the progress data (e.g. $_SESSION["upload_progress_123"]["cancel_upload"] = true;).

-	Doing so will cancel the currently uploading file, bypass all remaining data (POST variables, uploads, etc). An upload canceled this way will have "error" set to [[http://www.php.net/manual/en/features.file-upload.errors.php\|UPLOAD_ERR_EXTENSION]].	+	Doing so will cancel the currently uploading file and bypass all remaining data (POST variables, uploads, etc). An upload canceled this way will have "error" set to [[http://www.php.net/manual/en/features.file-upload.errors.php\|UPLOAD_ERR_EXTENSION]].

rfc:short-syntax-for-anonymous-function

2013-02-19T16:51:44+02:00

1361279630		current
Line 62:		Line 62:

	function it($testName, callable $test) {		function it($testName, callable $test) {
-	print(" $test" . PHP_EOL);	+	print(" $testName" . PHP_EOL);
	$test();		$test();
	}		}

rfc:short-syntax-for-anonymous-functions

2013-02-19T13:45:24+02:00

1361277902		current
Line 4:		Line 4:
	* Author: Marcello Duarte <marcello.duarte@gmail.com>		* Author: Marcello Duarte <marcello.duarte@gmail.com>
	* Status: Draft		* Status: Draft
-	* First Published at: https://wiki.php.net/rfc/short-syntax-for-closures	+	* First Published at: https://wiki.php.net/rfc/short-syntax-for-anonymous-functions
	* Other formats ..		* Other formats ..

rfc:short-syntax-for-anonymus-functions

2013-02-19T14:00:06+02:00

1361277665		current
Line 1:		Line 1:
-	====== Request for Comments: Short syntax for anonymus functions ======	+	===== This topic does not exist yet =====
-	* Version: 1.0	+
-	* Date: 2008-03-06	+
-	* Author: Marcello Duarte <marcello.duarte@gmail.com>	+
-	* Status: Draft	+
-	* First Published at: https://wiki.php.net/rfc/short-syntax-for-closures	+
-	* Other formats ..	+

-	===== Introduction =====	+	You've followed a link to a topic that doesn't exist yet. If permissions allow, you may create it by using the Create this page button.
-		+
-	In some cases it is necessary that you have to pass an anonymus function to a function/method as a parameter. If your library receives uses an anonymus function, and alternatively nested anonymus functions, having the function keyword makes the code very long and unecessary unreadable. If you take a look at other languages (Ruby, Python, Groovy, Coffescript) there is a short syntax for closure using the language state block container. Maybe PHP should adopt this behaviour to make code more readable and maintainable.	+
-		+
-	===== Syntax =====	+
-		+
-	An anonymus function in php could be expressed by a typical statement block, surrounded by curly brackets.	+
-		+
-	<code php>	+
-	<?php	+
-	$sayHi = { echo "hi"; };	+
-	$sayHi(); // prints: hi	+
-		+
-	$sayHello = { $name => echo "hello, $name"; };	+
-	$sayHello("Chuck Norris"); // prints: hello, Chuck Norris	+
-		+
-	$sayHello = { $name, $mood => echo "hello, $name. It's $mood day!"; };	+
-	$sayHello("Chuck Norris", "wonderful"); // prints: hello, Chuck Norris. It's a wonderful day!	+
-	</code>	+
-		+
-	===== Passing an anonymus function to a function =====	+
-		+
-	The syntax allows for a cleaner way to pass a an anonymus function around.	+
-		+
-	<code php>	+
-	<?php	+
-		+
-	setFormattingStrategy({$string =>	+
-	return trim(strtolower($string));	+
-	});	+
-		+
-	</code>	+
-		+
-	===== What is common use cases in other language =====	+
-	==== Building domain specific languages ====	+
-		+
-	Some languages like Groovy and Ruby allows you to move the anonymus function outside of the list of arguments if it is the last argument of the function call, creating a interesting side effect.	+
-		+
-	<code php>	+
-	function describe($testedClass, callable $tests) {	+
-	print ("$testedClass" . PHP_EOL);	+
-	$tests();	+
-	}	+
-		+
-	function it($testName, callable $test) {	+
-	print(" $test" . PHP_EOL);	+
-	$test();	+
-	}	+
-		+
-	// because the last argument is a callable we can now:	+
-		+
-	describe ("BankAccount") {	+
-	it ("starts with a zero amount") {	+
-	$amount = (new BankAccount())->getAmount();	+
-	if ($amount !== 0) throw new Failure("Expected 0, got $amount");	+
-	}	+
-	}	+
-	</code>	+
-		+
-	===== Pros and Cons =====	+
-		+
-	==== Pros ====	+
-	* Good for framework development when more expressive callbacks are needed	+
-	* Good for DSLs	+
-	* Removes bloating, unnecessary syntax	+
-	* Other web languages have similar syntax	+
-	* Readable	+
-		+
-	==== Cons ====	+
-	* Yet another alias	+
-	* Would take distinctness from block statements	+
-	* Not as searchable through search engines	+
-	* Patch may be difficult to maintain in future	+
-		+
-	===== Changelog =====	+

rfc:short_closures

2015-10-03T12:45:22+02:00

1442885511		current
Line 3:		Line 3:
	* Date: 2015-05-01		* Date: 2015-05-01
	* Author: Bob Weinand, bobwei9@hotmail.com		* Author: Bob Weinand, bobwei9@hotmail.com
-	* Status: Vote	+	* Status: Declined / Withdrawn in favor of http://wiki.php.net/rfc/arrow_functions
	* First Published at: http://wiki.php.net/rfc/short_closures		* First Published at: http://wiki.php.net/rfc/short_closures

Line 300:		Line 300:
	Voting opened September 22th, 2015 and will remain open until October 2nd, 2015.		Voting opened September 22th, 2015 and will remain open until October 2nd, 2015.

-	<doodle title="Short Closures" auth="bwoebi" voteType="single" closed="false">	+	<doodle title="Short Closures" auth="bwoebi" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:short_list_syntax

2016-05-20T02:03:51+02:00

1462732133		current
Line 3:		Line 3:
	* Date: 2016-04-07		* Date: 2016-04-07
	* Authors: Andrea Faulds <ajf@ajf.me>, Bob Weinand <bwoebi@php.net>		* Authors: Andrea Faulds <ajf@ajf.me>, Bob Weinand <bwoebi@php.net>
-	* Status: Accepted (PHP 7.1)	+	* Status: Implemented (PHP 7.1)
	* First Published at: http://wiki.php.net/rfc/short_list_syntax		* First Published at: http://wiki.php.net/rfc/short_list_syntax

Line 174:		Line 174:

	===== Implementation =====		===== Implementation =====
		+	Merged into master for PHP 7.1: http://git.php.net/?p=php-src.git;a=commitdiff;h=4f077aee836ad7d8335cf62629a8364bdf939db9
		+
		+	Not yet in the language specification.
		+
	After the project is implemented, this section should contain		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 PHP manual entry for the feature

rfc:short_ternary_equal_operator

2016-03-25T04:41:55+02:00

1458843220		current
Line 3:		Line 3:
	* Date: 2016-03-10		* Date: 2016-03-10
	* Author: Sara Golemon <pollita@php.net> (Heavily cribbed from Midori Kocak <mtkocak@gmail.com>)		* Author: Sara Golemon <pollita@php.net> (Heavily cribbed from Midori Kocak <mtkocak@gmail.com>)
-	* Status: Voting	+	* Status: Under Discussion
	* First Published at: http://wiki.php.net/rfc/short_ternary_equal_operator		* First Published at: http://wiki.php.net/rfc/short_ternary_equal_operator

Line 25:		Line 25:

	This proposed for the next PHP 7.x.		This proposed for the next PHP 7.x.
		+
		+	===== Patches and Tests ====
		+
		+	https://github.com/php/php-src/compare/master...sgolemon:short-ternary.coalesce

	===== Vote =====		===== Vote =====
Line 30:		Line 34:
	As this is a language change, a 2/3 majority is required. A straight Yes/No vote is being held.		As this is a language change, a 2/3 majority is required. A straight Yes/No vote is being held.

-	<doodle title="Approve Short Ternary Assignment Operator RFC?" auth="pollita" voteType="single" closed="true">	+	<doodle title="Approve Short Ternary Assignment Operator RFC and merge oatch into master?" auth="pollita" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

-	Vote was closed a few hours after opening (at 9:3 in favor) due to issues with the proposed implementation. It will be reopened at a later time (with a fresh vote).	+	On 2016-03-24 vote was closed a few hours after opening (at 9:3 in favor) due to issues with the proposed implementation. It will be reopened at a later time (with a fresh vote).

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

	This is essentially the same proposal as https://wiki.php.net/rfc/null_coalesce_equal_operator with a focus on the short ternary operator, rather than the null coalesce operator.		This is essentially the same proposal as https://wiki.php.net/rfc/null_coalesce_equal_operator with a focus on the short ternary operator, rather than the null coalesce operator.

rfc:shortags

2013-10-29T18:26:18+02:00

1383067568		current
Line 3:		Line 3:
	* Date: 2008-04-03		* Date: 2008-04-03
	* Author: Stas Malyshev <stas@php.net>		* Author: Stas Malyshev <stas@php.net>
-	* Status: Implemented in PHP 5.4 (Always available <?=)	+	* Status: Implemented in PHP 5.4 (Always available ''<?='')

rfc:shortsyntaxforarrays

2011-11-10T14:54:58+02:00

1312658904		current
Line 75:		Line 75:
	===== Conclusion =====		===== Conclusion =====

-	This patch will not be accepted because slight majority of the core developers voted against. Though if you take a accumulated mean between core developers and userland votes seems to show the opposite it would be irresponsible to submit a patch witch is not supported or maintained in the long run.	+	This patch has been merged in PHP 5.4.0 and trunk.
	===== Discussion on the List =====		===== Discussion on the List =====

rfc:shortsyntaxforfunctions

2011-06-01T18:20:06+02:00

1306940834		current
Line 41:		Line 41:

	No patch is available yet. I'm working on it, though.		No patch is available yet. I'm working on it, though.
-
-	This functionality is already available with Prep: https://github.com/andreiz/prep/tree/master/examples/whitespace

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

rfc:simple-annotations

2016-06-27T19:45:59+02:00

1463254681		current
Line 104:		Line 104:
	The optional ''$filter'' argument, if given, filters the returned list of annotations as follows:		The optional ''$filter'' argument, if given, filters the returned list of annotations as follows:

-	* If one of ''string'', ''int'', ''float'', ''bool'' are given, filters annotations using ''is_*()''	+	* If one of ''string'', ''int'', ''float'', ''bool'' are given, filters annotations using ''is_int()'', ''is_string()'', etc.
-	* If a fully-qualified class-name is given, filters annotations using ''instanceof''	+	* If a fully-qualified class-name is given, filters annotations using ''instanceof''

	If ''null'' is given (default) all annotations are returned.		If ''null'' is given (default) all annotations are returned.
Line 141:		Line 141:
	Annotations are a new feature - it does not affect any existing functionality.		Annotations are a new feature - it does not affect any existing functionality.

-	===== Future Scope =====	+	===== Out of Scope =====

-	A future RFC might include certain system annotations containing directives for the language interpreter itself. This might include a memoization-annotation that instructs the interpreter to memoize a function result on first call, such as is [[https://docs.hhvm.com/hack/attributes/special\|supported by Hack]].	+	It has been suggested that this RFC should reserve certain names for compiler directives, such as (for instance) the memoization-directive [[https://docs.hhvm.com/hack/attributes/special\|supported by Hack]]. This proposal does not reserve any such names, because (as others pointed out during that discussion) these are not meta-data, but rather directives for the compiler, and such features ought to be supported directly by keywords or syntax rather than by magical meta-data.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

rfc:simplified_named_params

2016-01-21T22:02:58+02:00

1453156696		current
Line 1:		Line 1:
	====== PHP RFC: Simplified Named Arguments ======		====== PHP RFC: Simplified Named Arguments ======
-	* Version: 0.1	+	* Version: 0.2
	* Date: 2016-01-18		* Date: 2016-01-18
	* Author: Rasmus Schultz <rasmus@mindplay.dk>		* Author: Rasmus Schultz <rasmus@mindplay.dk>
Line 94:		Line 94:
	Instead, upon encountering an unmatched named argument, a useful error message will be generated by scanning upwards through any parent class/interface declarations to find and report any possible inconsistencies - in the example above, the addition to the error message would be e.g. ''parameter names of method Counter::count() do not match those of CounterInterface::count()''.		Instead, upon encountering an unmatched named argument, a useful error message will be generated by scanning upwards through any parent class/interface declarations to find and report any possible inconsistencies - in the example above, the addition to the error message would be e.g. ''parameter names of method Counter::count() do not match those of CounterInterface::count()''.

-	Although this causes potential problems with named arguments applied to existing code, the problem is considered minor, since most existing code does not use long argument lists intended to be called using named arguments - most existing code with many options, for lack of better, likely uses a ''$options'' array argument, and uses code to explicitly unpack and apply the options. (The "Non-Features" section discusses this further.)	+	Although this causes potential problems with named arguments applied to existing code, the problem is considered minor, since most existing code does not use long argument lists intended to be called using named arguments - most existing code with many options, for lack of better, likely uses a ''$options'' array argument, and uses code to explicitly unpack and apply the options. (This is discussed further in the section "Differences from Previous Proposal", below.)
		+
		+	==== Magic Methods ====
		+
		+	Named arguments, are not applicable to magic methods implemented via ''__call()'' or ''__callStatic()'' - per this proposal, named arguments can only be matched to parameters that actually have names; parameters passed dynamically via these magic methods have only numeric indices.
		+
		+	As for implementations of ''__invoke()'', these have actual argument lists, and therefore can be invoked using named arguments.

	==== Impact on Reflection ====		==== Impact on Reflection ====
Line 100:		Line 106:
	This proposal has no impact on reflection.		This proposal has no impact on reflection.

-	===== Differences from Existing Proposal =====	+	===== Differences from Previous Proposal =====

	Since this is a simplified proposal, compared to the one previously proposed by Nikita Popov, the following section will cover non-features and differences of this proposal as compared to that.		Since this is a simplified proposal, compared to the one previously proposed by Nikita Popov, the following section will cover non-features and differences of this proposal as compared to that.
Line 185:		Line 191:

	Dealing with these issues when using open sets of options, passed via arrays, is an issue you deliberately elect to deal with - the principle behind this RFC, is that named arguments must map strictly to declared parameters, otherwise you might as well be using a single array of options as the only argument.		Dealing with these issues when using open sets of options, passed via arrays, is an issue you deliberately elect to deal with - the principle behind this RFC, is that named arguments must map strictly to declared parameters, otherwise you might as well be using a single array of options as the only argument.
		+
		+	===== Notes on Syntax =====
		+
		+	The proposed syntax resembles that of object literals in JS, and conflicts with an [[https://wiki.php.net/rfc/objectarrayliterals\|inactive RFC]] written in 2011. It does not appear to conflict with another [[https://wiki.php.net/rfc/bare_name_array_literal\|declined RFC]] written in 2014, which proposed something similar for arrays rather than ''stdClass'' objects.
		+
		+	Regarding potential confusion over similarity to object literals in JS, curly braces are widely used in various languages to delimit the start and end of functions, conditional blocks, object literals, etc. - and arrays in PHP are probably closer in nature to JS objects than ''stdClass'' is, for example ''$o['k'] = 'v';'' does not work on ''stdClass'' in PHP, but does work on arrays, which have a different syntax from JS object literals, as observed by the 2014 array literals proposal mentioned above, which proposes to build on PHP arrays, and array syntax, not on JS object literal syntax, although it makes clear the intended end is something similar to JS object literals.
		+
		+	If implemented, this RFC would stand in the way of adopting a JS-like syntax for object literals, but does not stand in the way of something else providing the same utility for arrays, which generally see more use and have greater utility than ''stdClass'', due to the greater number of array functions, operators, and other features.

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

rfc:site_voting_poll

2013-02-23T15:42:20+02:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Site voting poll ======
	+	* Version: 0.1
	+	* Date: 2013-02-23
	+	* Author: Florin Patan <florinpatan@gmail.com>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/site_voting_poll
	+
	+	===== Introduction =====
	+
	+	This RFC talks about integration of voting polls into PHP.net in order to get a feedback from PHP users on RFCs or other topics from things like expectations from futher PHP versions to anything else that needs feedback from the community.
	+
	+	===== Why do we need this? =====
	+
	+	This is needed in order to get a feedback from the community when the community would help shedding light on a certain topic such as a RFC, a discussion proposing various changes on the internals ML, upcoming PHP features and so on. Basically anything that would help determining the value of something for the community.
	+
	+	===== Patch =====
	+
	+	There's no patch available at this time.
	+	If there's a need to have it before allowing this RFC to be voted, it will be added.
	+
	+	===== ML discussion =====
	+
	+	The ML discussion for this RFC can be followed via this subject line: [PHP-DEV] PHP User Survey
	+
	+	===== Changelog =====
	+
	+	0.1 - initial draft
	+

rfc:size_t_and_int64

2014-02-03T21:28:23+02:00

1391459256		current
Line 4:		Line 4:
	* Date: 2013-12-05		* Date: 2013-12-05
	* Authors: Anatol Belski <ab@php.net>, Matt Ficken <mattficken@php.net>, Stephen A. Zarkos <szarkos@php.net>		* Authors: Anatol Belski <ab@php.net>, Matt Ficken <mattficken@php.net>, Stephen A. Zarkos <szarkos@php.net>
-	* Status: Voting	+	* Status: Rejected

rfc:size_t_and_int64_next

2014-08-18T10:03:45+02:00

1400519599		current
Line 4:		Line 4:
	* Date: 2014-05-06		* Date: 2014-05-06
	* Authors: Anatol Belski <ab@php.net>, Matt Ficken <mattficken@php.net>, Stephen A. Zarkos <szarkos@php.net>		* Authors: Anatol Belski <ab@php.net>, Matt Ficken <mattficken@php.net>, Stephen A. Zarkos <szarkos@php.net>
-	* Status: Voting	+	* Status: Accepted
	* First published at: https://wiki.php.net/rfc/size_t_and_int64		* First published at: https://wiki.php.net/rfc/size_t_and_int64

Line 289:		Line 289:


-	<doodle title="Accept this RFC for PHP6 (or whatever next major is called)" auth="user" voteType="single" closed="false">	+	<doodle title="Accept this RFC for PHP6 (or whatever next major is called)" auth="user" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>
	\\		\\
-	<doodle title="Merge strategy" auth="user" voteType="multi" closed="false">	+	<doodle title="Merge strategy" auth="user" voteType="multi" closed="true">
	* after the vote, master		* after the vote, master
	* phpng		* phpng

rfc:skipparams

2015-02-22T21:53:05+02:00

1424638369		current
Line 3:		Line 3:
	* Date: 2015-01-01		* Date: 2015-01-01
	* Author: Stas Malyshev <stas@php.net>		* Author: Stas Malyshev <stas@php.net>
-	* Status: Vote	+	* Status: Declined
	* Implementation: https://github.com/smalyshev/php-src/tree/skip_params7		* Implementation: https://github.com/smalyshev/php-src/tree/skip_params7
	===== Introduction =====		===== Introduction =====

rfc:slim_post_data

2013-12-17T20:26:05+02:00

1386690860		current
Line 1:		Line 1:

	====== PHP RFC: Slim POST data ======		====== PHP RFC: Slim POST data ======
-	* Version: 1.2	+	* Version: 1.3
-	* Date: 2013-12-02	+	* Date: 2013-12-17
	* Author: Michael Wallner <mike@php.net>		* Author: Michael Wallner <mike@php.net>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/slim_post_data		* First Published at: https://wiki.php.net/rfc/slim_post_data

Line 101:		Line 101:
	* 1.2		* 1.2
	* Re-ordered the RFC and reworded some sections.		* Re-ordered the RFC and reworded some sections.
		+	* 1.3
		+	* Accepted.

	===== Vote =====		===== Vote =====
-	<doodle title="RFC/slim_post_data" auth="mike" voteType="single" closed="false">	+	<doodle title="RFC/slim_post_data" auth="mike" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>

rfc:small_features

2015-04-06T12:00:45+02:00

1428314427		current
Line 1:		Line 1:
-	====== PHP RFC: Your Title Here ======	+	====== PHP RFC: Small features ======
	* Version: 0.1		* Version: 0.1
	* Date: 2015-04-06		* Date: 2015-04-06

rfc:socket_getaddrinfo

2016-08-12T19:32:39+02:00

1470952781		current
Line 9:		Line 9:
	This RFC targets a reported feature request in [[https://bugs.php.net/bug.php?id=72733\|#72733]]. The request is that PHP expose the C level function getaddrinfo(). This is a missing nice piece to the current socket library. When dealing with variable networks it would be beneficial to allow libc to tell us what methods of connecting/listening would be most appropriate given a set of hints.		This RFC targets a reported feature request in [[https://bugs.php.net/bug.php?id=72733\|#72733]]. The request is that PHP expose the C level function getaddrinfo(). This is a missing nice piece to the current socket library. When dealing with variable networks it would be beneficial to allow libc to tell us what methods of connecting/listening would be most appropriate given a set of hints.

-	===== Proposals =====	+	===== Proposal =====
-	I'm starting this RFC with 2 proposed solutions, which are very similar, but I'm not sure which is preferable for implementation.	+	The implementation[[https://wiki.php.net/rfc/socket_getaddrinfo#references\|[1]]] I'm proposing implements 4 new functions. ''socket_addrinfo_lookup()'' will return an array of resources, with each resource corresponding to each returned addrinfo. The next two implemented methods ''socket_addrinfo_bind()'', and ''socket_addrinfo_connect()'', would be used to bind, or connect, to a given resource rather than make the user go through the process of creating the socket and connect/binding themselves. The last is to convert the resource to an array for examination.
-	==== Proposal 1 ====	+
-	The implementation[[https://wiki.php.net/rfc/socket_getaddrinfo#references\|[1]]] I'm proposing implements 5 new socket_* functions. ''socket_getaddrinfo()'' will return an array of resources, with each resource corresponding to each returned addrinfo. The next two implemented methods ''socket_addrinfo_bind()'', and ''socket_addrinfo_connect()'', would be used to bind, or connect, to a given resource rather than make the user go through the process of creating the socket and connect/binding themselves. The fourth function is a free'r if you'd want to free the resources before end of script. And the last to pull info from the addrinfo resource.	+
	<file php>		<file php>
-	socket_getaddrinfo(string node[, mixed service, array hints]) : array	+	socket_addrinfo_lookup(string node[, mixed service, array hints]) : array
	socket_addrinfo_connect(resource $addrinfo) : resource		socket_addrinfo_connect(resource $addrinfo) : resource
	socket_addrinfo_bind(resource $addrinfo) : resource		socket_addrinfo_bind(resource $addrinfo) : resource
-	socket_addrinfo(resource $addrinfo) : array	+	socket_addrinfo_explain(resource $addrinfo) : array
-	socket_addrinfo_close(sockaddrresource sockaddr) : null	+
	</file>		</file>

	<file php>		<file php>
	<?php		<?php
-	$addrinfo = socket_getaddrinfo('127.0.0.1', 2000, array('ai_family' => AI_INET, 'ai_socktype' => SOCK_STREAM));	+	$addrinfo = socket_addrinfo_lookup('127.0.0.1', 2000, array('ai_family' => AI_INET, 'ai_socktype' => SOCK_STREAM));
	$sockaddr = reset($addrinfo);		$sockaddr = reset($addrinfo);
	if (!$sockaddr) die ("No Valid Socket Types");		if (!$sockaddr) die ("No Valid Socket Types");
	$sock = socket_addrinfo_bind($sockaddr);		$sock = socket_addrinfo_bind($sockaddr);
	// ^^ $sock is a socket resource that is bound to 127.0.0.1:2000 using TCP/IP ready for reading		// ^^ $sock is a socket resource that is bound to 127.0.0.1:2000 using TCP/IP ready for reading
-	foreach ($addrinfo as $sockaddr) {
-	socket_addrinfo_close($sockaddr);
-	}
	</file>		</file>
-
-	Pro
-	* Doesn't change current functions
-	Con
-	* Adds duplicative functions
-	* Isn't very 'C' like in how it's used
-
-	==== Proposal 2 ====
-	This attempt [[https://wiki.php.net/rfc/socket_getaddrinfo#references\|[2]]] is similar to the first, and tries to be a hybrid approach. It alters the default signature of socket_(connect\|bind) to change the second argument to mixed. This method is the most C-like of the 3. After playing with all three, this is my preferred, but changing default signatures is not always the best idea.
-
-	<file php>
-	socket_getaddrinfo(string $node[, mixed $service, array $hints]) : array
-	socket_connect(resource $sock, mixed $address_or_addrinfo[, int $port = 0]) : bool
-	socket_bind(resource $sock, string $address_or_addrinfo[, int port = 0]) : bool
-	socket_addrinfo_close(resourece $addrinfo) : null
-	</file>
-
-	<file php>
-	<?php
-	$addrinfo = socket_getaddrinfo('127.0.0.1', 2000, array('ai_family' => AI_INET, 'ai_socktype' => SOCK_STREAM));
-	$sockaddr = reset($addrinfo);
-	if (!$sockaddr) die ("No Valid Socket Types");
-	$sock = socket_create($sockaddr['ai_family'], $sockaddr['ai_socktype'], $sockaddr['ai_protocol']);
-	$sock = socket_bind($sock, $sockaddr);
-	// ^^ $sock is a socket resource that is bound to 127.0.0.1:2000 using TCP/IP ready for reading
-	foreach ($addrinfo as $sockaddr) {
-	socket_addrinfo_close($sockaddr);
-	}
-	</file>
-
-	Pro
-	* Used much more like how C implements socket()/bind()/connect()
-	Con
-	* Changes default signatures of socket_bind()/socket_connect()

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====
-	New functionality; BC problems in changing default socket function signatures for Proposal 2. Although code that exists today ought not to have BC issues.	+	New functionality; no BC issues.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
Line 94:		Line 54:

	===== References =====		===== References =====
-	* [1] - [[https://github.com/php/php-src/compare/master...bp1222:fix-72733\|Proposed #1 Implementation]]	+	* [1] - [[https://github.com/php/php-src/pull/2078\|Proposed #1 Implementation]]
-	* [2] - [[https://github.com/php/php-src/compare/master...bp1222:fix3-72733\|Proposed #2 Implementation]]	+

rfc:socketactivation

2014-04-09T00:52:28+02:00

1352497637		current
Line 3:		Line 3:
	* Date: 2012-10-17		* Date: 2012-10-17
	* Author: David Strauss <david@davidstrauss.net>, Jerry Blakley <jerry@getpantheon.com>		* Author: David Strauss <david@davidstrauss.net>, Jerry Blakley <jerry@getpantheon.com>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/socketactivation		* First Published at: http://wiki.php.net/rfc/socketactivation
	* Patches: [[rfc/socketactivation/build.patch\|build.patch]] (needs to be made optional), [[rfc/socketactivation/activate.patch\|activate.patch]]		* Patches: [[rfc/socketactivation/build.patch\|build.patch]] (needs to be made optional), [[rfc/socketactivation/activate.patch\|activate.patch]]

rfc:source_files_without_opening_tag

2012-05-07T03:17:20+02:00

1334611812		current
Line 1:		Line 1:
		+	====== ABANDONED ======
		+
		+	I have abandoned this proposal. I have come to feel it changes the spirit of PHP too much, offering too little gain for the degree of unhappiness it inspires and the potential for confusion it creates. I am leaving it here for historical purposes. -Tom Boutell
		+
	====== Request for Comments: Source Files Without Opening Tag ======		====== Request for Comments: Source Files Without Opening Tag ======
	* Version: 1.1.1		* Version: 1.1.1
Line 119:		Line 123:
	===== Changelog =====		===== Changelog =====

		+	* 2012-05-06 Thomas Boutell: formally abandoned by original proponent.
	* 2012-04-09 Yasuo Ohgaki: Added related RFC.		* 2012-04-09 Yasuo Ohgaki: Added related RFC.
	* 2012-04-10 Thomas Boutell: removed misleading word "Option" from parts 1 and 2, which are not meant to be mutually exclusive (see the original text).		* 2012-04-10 Thomas Boutell: removed misleading word "Option" from parts 1 and 2, which are not meant to be mutually exclusive (see the original text).

rfc:sourcemaps

2016-04-06T22:53:45+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Add support for Sourcemaps ======
	+
	+	* Version: 0.1
	+	* Date: 2016-04-06
	+	* Author: Rasmus Schultz <rasmus@mindplay.dk>
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/sourcemaps
	+
	+	===== Introduction =====
	+
	+	This RFC proposes adding support for [[https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k\|Source Map Revision 3]].
	+
	+	Source maps are an essential and familiar feature for developers using other web-specific technologies, most notably Javascript, SASS and LESS, and it is widely supported by major browsers, Node.js, various IDE families and many different tools.
	+
	+	Support for source maps under PHP on the server-side would benefit maintainers and consumers of many different PHP libraries that rely on some form of code generation, including template engines such as [[http://twig.sensiolabs.org/\|Twig]], aspect-oriented programming frameworks such as [[https://github.com/goaop/framework\|GO-AOP]], pre-processors such as [[https://github.com/marcioAlmada/yay\|YAY]], source-code transformation tools such as [[https://github.com/grom358/pharborist\|Pharborist]] and more.
	+
	+	One could envision support for source maps enabling more people to experiment with alterations to the language, such as prototyping and proofing RFCs before attempting a "real" implementation, and the ability to implement polyfills could mean that more developers are able and willing to adopt modern PHP features before they're widely available on hosted servers, and so forth.
	+
	+	===== Proposal =====
	+
	+	A generated ''.php'' file may ''declare'' the path to a matching source map file, relative to the location of the file itself - for example:
	+
	+	<code php>
	+	<?php
	+	declare(sourcemap_url='../../src/views/layout.twig.map');
	+	</code>
	+
	+	Alternatively, the source map data may be embedded directly within the file:
	+
	+	<code php>
	+	<?php
	+	declare(sourcemap_data='eyJ2ZXJzaW9uIjozLCJmaWxlIjoibGlzdC5qcyIsInNvdX.......');
	+	</code>
	+
	+	The latter may be preferable for security reasons, while the former may be preferable e.g. for remote debugging.
	+
	+	====== Error Messages ======
	+
	+	Error messages, when referencing file-names, will take into account a source map, when present - for example, where a warning would otherwise display as follows:
	+
	+	<code>
	+	Warning: Division by zero in /foo/layout.php on line 7
	+	</code>
	+
	+	The same error message would now display as follows:
	+
	+	<code>
	+	Warning: Division by zero in /foo/src/view/layout.twig on line 3 (/foo/layout.php on line 7)
	+	</code>
	+
	+	E.g. displaying both the resolved source file-name and line number, as well as the PHP source file/line.
	+
	+	====== Stack Traces ======
	+
	+	The stack-trace from an uncaught Exception will display as follows:
	+
	+	<code>
	+	Fatal error: Uncaught exception 'Exception' with message 'Division by zero' in /foo/src/bar.twig:71 ~ /foo/bar.php:56
	+	Stack trace:
	+	#0 /foo/src/bar.twig(9) ~ /foo/bar.php(17): require()
	+	#1 {main}
	+	thrown in /foo/src/bar.twig on line 71 (/foo/bar.php on line 56)
	+	</code>
	+
	+	====== Exceptions ======
	+
	+	Uncaught Exceptions will cause an error-message and stack-trace print-out with file/line-references resolved and displayed, similarly to unhandled errors, as explained above.
	+
	+	The ''Exception'' class will have the following new properties and methods:
	+
	+	<code>
	+	Exception {
	+	/* Properties */
	+	protected string\|null $sourceFile ;
	+	protected int\|null $sourceLine ;
	+
	+	/* Methods */
	+	final public string\|null getSourceFile ( void )
	+	final public int\|null getSourceLine ( void )
	+	}
	+	</code>
	+
	+	Note that these methods and properties return ''null'' when no source map is available.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	None.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	Next PHP 7.x.
	+
	+	===== RFC Impact =====
	+
	+	==== To SAPIs ====
	+
	+	TODO: Investigate and describe any impact to CLI, Development web server, embedded PHP etc.
	+
	+	==== To Existing Extensions ====
	+
	+	TODO: Will existing extensions be affected?
	+
	+	==== To Opcache ====
	+
	+	TODO: determine how this affects opcache. (most likely source maps need to be cached?)
	+
	+	==== php.ini Defaults ====
	+
	+	A new ''enable_source_maps'' setting will be added to ''php.ini'' - when set to ''0'', disabling the source map feature in favor of security, privacy and performance, since this is a developer feature.
	+
	+	This will be set to ''0'' by default, as well as in ''php.ini-production'' - it will be set to ''1'' in ''php.ini-development''.
	+
	+	Note that this setting disables automatic source map resolution in error-messages and stack-traces only. This setting does not affect the behavior of the ''Exception'' class methods and properties, which are always capable of reporting the source file/line if a source map is available - this enables developers to implement error logging/reporting facilities that make use of this information on-demand.
	+
	+	===== Open Issues =====
	+
	+	TODO
	+
	+	===== Unaffected PHP Functionality =====
	+
	+	TODO
	+
	+	===== Future Scope =====
	+
	+	Perhaps in conjunction with this RFC, file and line-number references in error-message and stack-traces could be made consistent - a standard PHP stack-trace presently uses 3 (three!) different file/line-number formats.
	+
	+	===== Proposed Voting Choices =====
	+
	+	TODO
	+
	+	===== Patches and Tests =====
	+
	+	No patch exists at this time - the proposal is a draft, and as such is not ready for implementation.
	+
	+	===== 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
	+
	+	===== References =====
	+	Links to external references, discussions or RFCs
	+
	+	===== Rejected Features =====
	+	Keep this updated with features that were discussed on the mail lists.

rfc:spl-improvements

2013-10-17T17:21:39+02:00

1326003041		current
Line 36:		Line 36:
	Some problems that need to be talked about and resolved:		Some problems that need to be talked about and resolved:
	* Exceptions		* Exceptions
-	* Each extension in the SPL should be well defined and documented. This includes using an example of when the exception could be used. Note: The examples of exceptions being used could be showing an SPL class throwing the given exception. It would help promote understanding of the SPL structures while clarifying the use of the exception.	+	* Each exception in the SPL should be well defined and documented. This includes using an example of when the exception could be used. Note: The examples of exceptions being used could be showing an SPL class throwing the given exception. It would help promote understanding of the SPL structures while clarifying the use of the exception.
	* All of the SPL classes should be refactored to align their behavior with the exception clarifications.		* All of the SPL classes should be refactored to align their behavior with the exception clarifications.
	* Should the SPL be namespaced?		* Should the SPL be namespaced?
	* If large-scale backwards compatibility is broken, it could be detrimental to do so all at once. However, doing it in pieces is not really reasonable. Namespacing the SPL while keeping the old SPL in place could allow all of the changes to happen without breaking backwards compatibility because the current SPL is not namespaced.		* If large-scale backwards compatibility is broken, it could be detrimental to do so all at once. However, doing it in pieces is not really reasonable. Namespacing the SPL while keeping the old SPL in place could allow all of the changes to happen without breaking backwards compatibility because the current SPL is not namespaced.
	* This could be the beginning of migrating existing PHP extensions and functions to namespaces. If this works well, then there is a viable way to safely break backwards compatibility and could be used in many other areas where breaking backwards compatibility is undesirable.		* This could be the beginning of migrating existing PHP extensions and functions to namespaces. If this works well, then there is a viable way to safely break backwards compatibility and could be used in many other areas where breaking backwards compatibility is undesirable.

rfc:spl-namespace

2011-04-06T12:59:26+02:00

1216716622		current
Line 2:		Line 2:
	* Version: 1.0		* Version: 1.0
	* Date: 2008-07-19		* Date: 2008-07-19
-	* Author: Baptiste Autin <fjas.at.free.fr>	+	* Author: Baptiste <fjas.at.free.fr>
-	* Status: Under Discussion	+	* Status: Abandonned
	* First Published at: http://wiki.php.net/rfc/spl-namespace		* First Published at: http://wiki.php.net/rfc/spl-namespace
	* Other formats ..		* Other formats ..

rfc:splclassloader

2012-11-19T07:42:51+02:00

1340952794		current
Line 3:		Line 3:
	* Date: 2010-03-22		* Date: 2010-03-22
	* Author: Guilherme Blanco <guilhermeblanco@hotmail.com>		* Author: Guilherme Blanco <guilhermeblanco@hotmail.com>
-	* Status: Voting at https://wiki.php.net/rfc/splclassloader/vote	+	* Status: Declined
		+	* Voting results at https://wiki.php.net/rfc/splclassloader/vote
	* First Published at: http://wiki.php.net/rfc/splclassloader		* First Published at: http://wiki.php.net/rfc/splclassloader

rfc:splweaktypehintingwithautoboxing

2011-04-06T12:59:26+02:00

1275329698		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: SPL weak type hinting ======
	* Version: 1.0		* Version: 1.0
	* Date: 2010-05-31		* Date: 2010-05-31

rfc:sql_injection_protection

2015-07-28T20:09:13+02:00

1438103240		current
Line 3:		Line 3:
	* Date: 2015-07-22		* Date: 2015-07-22
	* Author: Matt Tait, matttait#at#google.com		* Author: Matt Tait, matttait#at#google.com
-	* Status: Draft	+	* Status: Under discussion
	* First Published at: http://wiki.php.net/rfc/sql_injection_protection		* First Published at: http://wiki.php.net/rfc/sql_injection_protection
	* You can [[http://phpoops.cloudapp.net/oops.php\|\|try it online]] ([[http://phpoops.cloudapp.net/oops.php?action=main&dbg_sql&limit=4%20ohdear\|spoiler]])		* You can [[http://phpoops.cloudapp.net/oops.php\|\|try it online]] ([[http://phpoops.cloudapp.net/oops.php?action=main&dbg_sql&limit=4%20ohdear\|spoiler]])

rfc:stackable_error_handler

2013-04-18T08:23:53+02:00

1363736881		current
Line 45:		Line 45:
	===== SAPIs Impacted =====		===== SAPIs Impacted =====

-	Describe the impact to CLI, Development web server, embedded PHP etc.	+	TODO

	===== New Constants =====		===== New Constants =====

-	Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation.	+	TODO

	===== php.ini Defaults =====		===== php.ini Defaults =====

-	If there are any php.ini settings then list:	+	TODO
-	* hardcoded default values	+
-	* php.ini-development values	+
-	* php.ini-production values	+

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

-	Make sure there are no open issues when the vote starts!	+	TODO

	===== Unaffected PHP Functionality =====		===== Unaffected PHP Functionality =====

-	List existing areas/features of PHP that will not be changed by the RFC.	+	TODO
-		+
-	This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.	+

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

-	This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.	+	TODO

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

-	Include these so readers know where you are heading and can discuss the proposed voting options.	+	TODO

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

-	Links to any external patches and tests go here.	+	TODO
-		+
-	If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.	+
-		+
-	Make it clear if the patch is intended to be the final patch, or is just a prototype.	+

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

-	Links to external references, discussions or RFCs	+	TODO

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

-	Keep this updated with features that were discussed on the mail lists.	+	TODO

rfc:static-classes

2011-04-06T12:59:26+02:00

1210418193		current
Line 40:		Line 40:
	AbstractStaticClass2::staticMethod(); // Throws error, not allowed. Must be extended first		AbstractStaticClass2::staticMethod(); // Throws error, not allowed. Must be extended first
	</code>		</code>
		+


Line 53:		Line 54:
	* The current behaviour of abstract classes/non-static classes with static members would not change. This is important for backwards compatibility		* The current behaviour of abstract classes/non-static classes with static members would not change. This is important for backwards compatibility
	* ''%%__setStatic()%%'' and ''%%__getStatic()%%'' will provide functionality similiar to ''%%__get()%%'' and ''%%__set()%%''		* ''%%__setStatic()%%'' and ''%%__getStatic()%%'' will provide functionality similiar to ''%%__get()%%'' and ''%%__set()%%''
-	* It **will not be possible to create instances of static** classes	+	* Static classes **cannot be instantiated**
		+	* Static classes can implement interfaces containing only static methods

	===== Code =====		===== Code =====

rfc:static_class_constructor

2015-04-13T18:38:13+02:00

1428933033		current
Line 1:		Line 1:
	====== PHP RFC: Static Class Constructor ======		====== PHP RFC: Static Class Constructor ======
-	* Version: 0.1	+	* Version: 0.2
	* Date: 2015-04-13		* Date: 2015-04-13
	* Author: Johannes Ott <mail@deroetzi.de>		* Author: Johannes Ott <mail@deroetzi.de>
Line 284:		Line 284:
	In this section I will try to summarize all discussion points and will try to figure out how in my personal opinion they really touch the proposal or not.		In this section I will try to summarize all discussion points and will try to figure out how in my personal opinion they really touch the proposal or not.

-	1. An argument I read several times is that within being inside the static context there could be some "crucial" things be done, for example opening and storing some resource handles to static properties, which means they couldn't be done explicit closed.	+	==== 1. Crucial code and complexitiy argument ====
		+
		+	An argument I read several times is that within being inside the static context there could be some "crucial" things be done, for example opening and storing some resource handles to static properties, which means they couldn't be done explicit closed.

	- First of all I used words like "crucial" or "horrific" during discussion as well, this was just to polarize inside the discussion. In my opinion there is no crucial code at all, beside the code which is not doing what programmer expected to do. There is only code, which is not as suitable for a special use case as another one would be for different reasons (less dependencies, performance, better readable code, side-effects, etc.). But this mainly depends on the special use case and should always be inside the decision of each programmer or a software architect analyzing the special use case.		- First of all I used words like "crucial" or "horrific" during discussion as well, this was just to polarize inside the discussion. In my opinion there is no crucial code at all, beside the code which is not doing what programmer expected to do. There is only code, which is not as suitable for a special use case as another one would be for different reasons (less dependencies, performance, better readable code, side-effects, etc.). But this mainly depends on the special use case and should always be inside the decision of each programmer or a software architect analyzing the special use case.
Line 292:		Line 294:
	- But as I am an instructor for beginners for several years I agree to the fact that the concept of static-context is one of the concepts in oop-programming which seems to be really hard to understand with all its side-effects to beginners. A suggestion, which may help is to create an extra documentation page about static context with a DOs and DONTs list on it to help everyone to get familiar with this concept. But as being a common problem of static-context I think that should not be part of this proposal. The documentation of the static class constructor can then although refer to this page.		- But as I am an instructor for beginners for several years I agree to the fact that the concept of static-context is one of the concepts in oop-programming which seems to be really hard to understand with all its side-effects to beginners. A suggestion, which may help is to create an extra documentation page about static context with a DOs and DONTs list on it to help everyone to get familiar with this concept. But as being a common problem of static-context I think that should not be part of this proposal. The documentation of the static class constructor can then although refer to this page.

-	2. Possibility of inheritance of the class constructor.	+	==== 2. Inheritance of the class constructor ====

	A class should have as less dependencies to another as possible. To give the possibility to inherit the class constructor will produce a huge amount of relationships not only between the superclass and it's subclasses but although between each subclass. For that reason this is no suitable feature of a static class constructor in my point of view.		A class should have as less dependencies to another as possible. To give the possibility to inherit the class constructor will produce a huge amount of relationships not only between the superclass and it's subclasses but although between each subclass. For that reason this is no suitable feature of a static class constructor in my point of view.
Line 331:		Line 333:
	</code>		</code>

-	3. How the error and exception handling should work?	+	==== 3. Error and Exception handling ====

	See open issues section for this topic.		See open issues section for this topic.

-	4. Need of a class destructor as well to handle unload order dependencies between classes.	+	==== 4. Need of a class destructor to handle unload order dependencies ====

	- The only order dependency between class A and class B should be an usage dependency either class B extends A or A is used static or non-static inside class B. In both cases as I can see for now, the language itself should do already everything correct by not unloading class A before class B, for doing unload by reverse creation time.		- The only order dependency between class A and class B should be an usage dependency either class B extends A or A is used static or non-static inside class B. In both cases as I can see for now, the language itself should do already everything correct by not unloading class A before class B, for doing unload by reverse creation time.
Line 343:		Line 345:
	- If someone can give me a suitable other example, I will think about this again. Until then this is just a possible future scope feature for me.		- If someone can give me a suitable other example, I will think about this again. Until then this is just a possible future scope feature for me.

-	5. Using explicit close feature on an example ResourcesPool class to close all opened resources (like ExamplePool::cleanupResources()) will break lazy-unloading, if class was not used before by calling the static constructor as well.	+	==== 5. Close method of unused ResourcesPool ====
		+
		+	Using explicit close feature on an example ResourcesPool class to close all opened resources (like ExamplePool::cleanupResources()) will break lazy-unloading, if class was not used before by calling the static constructor as well.

	- That is partly true, if called on a never used before Pool it will make an "unnecessary" call to static constructor. But on the one hand that is why I would use this feature only on pool-classes I surely know that they are used mostly on each page for example DatabaseConnectionPool. On the other hand it may be even necessary to call the static constructor to initialize some static properties necessary for the unload.		- That is partly true, if called on a never used before Pool it will make an "unnecessary" call to static constructor. But on the one hand that is why I would use this feature only on pool-classes I surely know that they are used mostly on each page for example DatabaseConnectionPool. On the other hand it may be even necessary to call the static constructor to initialize some static properties necessary for the unload.
Line 349:		Line 353:
	- And for still being inside the user-code phase and not in the shutdown phase of the run nothing will break, by this "unnecessary" call.		- And for still being inside the user-code phase and not in the shutdown phase of the run nothing will break, by this "unnecessary" call.

-	6. Everywhere you have to store a state of something you should use an instance instead of a class, by using for example a singleton pattern.	+	==== 6. Stateful things should be handled in instance not in class ====
		+
		+	Everywhere you have to store a state of something you should use an instance instead of a class, by using for example a singleton pattern.

	- As I already tried to explain in introduction section the static properties are the state of the class. If the explained pattern always would be true the static context would be obsolete.		- As I already tried to explain in introduction section the static properties are the state of the class. If the explained pattern always would be true the static context would be obsolete.

rfc:streamline-phar-api

2011-04-06T12:59:26+02:00

1206718969		current
Line 28:		Line 28:
	=== Adding isWritable() method ===		=== Adding isWritable() method ===
	== Proposal ==		== Proposal ==
-	Add an isWritable() method to determine whether an archive can be written or not. Not being able to write an archive either means it is disabled in the php.ini (see Phar::canWrite()) or that PHP can't write to the requested location of the phar archive.	+	Add an isWritable() method to determine whether an archive can be written or not. Not being able to write an archive either means it is disabled in the php.ini (see Phar::canWrite()) or that PHP can't write to the requested location of the phar archive. PharFileInfo must overload the method in order to accomplish that.
	== Code ==		== Code ==
	<code php>		<code php>

rfc:streammetadata

2011-08-06T21:28:13+02:00

1305144640		current
Line 3:		Line 3:
	* Date: 2011-03-13		* Date: 2011-03-13
	* Author: Stas Malyshev <stas@php.net>		* Author: Stas Malyshev <stas@php.net>
-	* Status: Draft	+	* Status: Implemented in 5.4
	* First Published at: http://wiki.php.net/rfc/streammetadata		* First Published at: http://wiki.php.net/rfc/streammetadata
	* Patch: http://random-bits-of.info/stream_meta.diff		* Patch: http://random-bits-of.info/stream_meta.diff

rfc:streams-is-cacheable

2015-02-02T18:34:13+02:00

1422893062		current
Line 1:		Line 1:
	====== PHP RFC: Add is_cacheable() stream-wrapper operation ======		====== PHP RFC: Add is_cacheable() stream-wrapper operation ======
-	* Version: 1.1	+	* Version: 1.2
	* Date: 2015-01-04		* Date: 2015-01-04
	* Author: François Laupretre, francois@tekwire.net		* Author: François Laupretre, francois@tekwire.net
-	* Status: Voting (starting 02/02/2015)	+	* Status: Under discussion
	* First Published at: http://wiki.php.net/rfc/streams-is-cacheable		* First Published at: http://wiki.php.net/rfc/streams-is-cacheable

Line 83:		Line 83:
	===== Open Issues =====		===== Open Issues =====

-	None	+	Discussion is under way to define how the cache can compute the key
		+	corresponding to a stream-wrapped path.

	===== Unaffected PHP Functionality =====		===== Unaffected PHP Functionality =====
Line 111:		Line 112:

	===== Rejected Features =====		===== Rejected Features =====
-
-	===== Vote =====
-
-	<doodle title="streams-is-cacheable" auth="francois" voteType="single" closed="false">
-	* Yes
-	* No
-	</doodle>

rfc:streamwrapper-factory

2011-09-11T21:26:04+02:00

1315768659		current
Line 1:		Line 1:
-	====== Request for Comments: Factory for stream wrappers ======	+	====== Request for Comments: Factory for Stream Wrappers ======

	* Version: 1		* Version: 1
Line 6:		Line 6:
	* Author: Benjamin Eberlei <kontakt@beberlei.de>		* Author: Benjamin Eberlei <kontakt@beberlei.de>
	* Author: Arne Blankers <theseer@php.net>		* Author: Arne Blankers <theseer@php.net>
		+	* Author: Stefan Priebsch <spriebsch@php.net>
	* Author: Sebastian Bergmann <sebastian@php.net>		* Author: Sebastian Bergmann <sebastian@php.net>
	* Status: Discussion		* Status: Discussion

rfc:strict_argcount

2015-03-16T18:06:00+02:00

1426483066		current
Line 3:		Line 3:
	* Date: 2015-02-20		* Date: 2015-02-20
	* Author: Márcio Almada		* Author: Márcio Almada
-	* Status: Voting	+	* Status: Withdraw
	* First Published at: http://wiki.php.net/rfc/strict_argcount		* First Published at: http://wiki.php.net/rfc/strict_argcount
		+
		+	=> The RFC was withdraw due to many controversial points and overall rejection and won't be proposed again by the RFC author. The RFC author advises to not revive this RFC as it was already rejected. Even if you think you have a much better idea, think twice.

	===== Introduction =====		===== Introduction =====
Line 438:		Line 440:
	As this is a language change, the main voting requires a 2/3 majority to pass.		As this is a language change, the main voting requires a 2/3 majority to pass.

-	<doodle title="Should PHP7 warn about exceeding argument count on function calls?" auth="marcio" voteType="single" closed="false">	+	<doodle title="Should PHP7 warn about exceeding argument count on function calls?" auth="marcio" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 448:		Line 450:
	A ''50% + 1'' majority is required. In the event of a tie the RFC author will take the final decision.		A ''50% + 1'' majority is required. In the event of a tie the RFC author will take the final decision.

-	<doodle title="What's the error level that should be emitted?" auth="marcio" voteType="single" closed="false">	+	<doodle title="What's the error level that should be emitted?" auth="marcio" voteType="single" closed="true">
	* E_WARNING		* E_WARNING
	* E_NOTICE		* E_NOTICE

rfc:strict_return_types

2016-03-03T04:40:06+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Strict return types ======
	+	* Version: 0.9
	+	* Date: 2016-03-03 (use today's date here)
	+	* Author: Bob Weinand bobwei9@hotmail.com
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/strict_return_types

	+	===== Introduction =====
	+	Weak return types were added alongside with weak scalar parameter types. But that violates the principle of "weak in, strict out". Return types should always be strictly checked. I know what I want to return, thus the return type should check whether I really returned what I wanted instead of trying to cast.
	+
	+	===== Proposal =====
	+	This RFC proposes always strict checking of return types - regardless of any declare(strict_types) instruction.
	+
	+	Scalar return types were introduced in a way to be consistent with parameter types: any passed (to a function) or returned variables (from a function) would be type checked equally strictly or weakly inside a file depending on the strict_types declaration.
	+
	+	But that wasn't a wise choice. You always want to have strict return types, but possibly have weak types when calling a function. While you may not have full control over a called function, you have full control over a function you defined yourself - and may just explicitly add a type cast when returning. Return types really should be able to prove correctness of the returned value instead of silently casting.
	+
	+	===== Backward Incompatible Changes =====
	+	Current weak return types will break. This shouldn't be too much of an issue though, as a) the share of weak return types intentionally used for casting should be very, very low and b) return types only officially are available since exactly three months (as of initial writing of this RFC), so not much PHP 7-only code will exist.
	+
	+	===== Proposed PHP Version(s) =====
	+	PHP 7.1.
	+
	+	And we additionally should soft-deprecate this in documentation as soon as this RFC passes to avoid more people relying on that behavior.
	+
	+	===== Unaffected PHP Functionality =====
	+	Function parameter scalar types are not changed.
	+
	+	===== Future Scope =====
	+	This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
	+
	+	===== Proposed Voting Choices =====
	+	Yes/no vote with 2/3 majority required.
	+
	+	===== Patches and Tests =====
	+	No patch yet, but implementation is trivial - will be added later.
	+
	+	===== References =====
	+	Original scalar return types: https://wiki.php.net/rfc/scalar_type_hints_v5#return_type_declarations

rfc:strict_sessions

2014-04-14T01:32:24+02:00

1397431453		current
Line 165:		Line 165:
	* First cookie(C=%2Fwww%2Fdefault%2Fpublic) is cookie set without domain and the default path '/'.		* First cookie(C=%2Fwww%2Fdefault%2Fpublic) is cookie set without domain and the default path '/'.
	* Second cookie(C=test.co.jp) is cookie set with domain.		* Second cookie(C=test.co.jp) is cookie set with domain.
-	* In this case, PHP initialize $_COOKIE['C'] == 'test.co.jp'. Session is also initializes with second cookie regardless of cookie set for path.	+	* In this case, PHP initialize $_COOKIE['C'] == 'test.co.jp'. Session is also initialized with second cookie regardless of cookie set for path.
	* Cookies are set for all combinations with different values (domain name and full path dir). (i.e. all domain and path)		* Cookies are set for all combinations with different values (domain name and full path dir). (i.e. all domain and path)
-	* To make this happen, it seems order of setting cookies were significant. Set path first, then domain.	+	* To make this happen, it seems order of setting cookies was significant. Set path first, then domain.


Line 181:		Line 181:
	Cookie: C=co.jp		Cookie: C=co.jp

-	* This is an test case for invalid domain. co.jp is ccTLD so browser should not set cookie for it. However, browser seems set cookie if it has IP.	+	* This is a test case for invalid domain. co.jp is ccTLD so browser should not set cookie for it. However, browser seems set cookie if it has IP.
	* This is very handy if someone wants to steal him/her colleague session. Just edit hosts and set long life cookie for the domain. It will remain unless cookie is expired or explicitly deleted.		* This is very handy if someone wants to steal him/her colleague session. Just edit hosts and set long life cookie for the domain. It will remain unless cookie is expired or explicitly deleted.

rfc:string-bitwise-shifts

2014-04-17T13:53:13+02:00

1397735541		current
Line 10:		Line 10:

	===== Proposal =====		===== Proposal =====
-	Currently, bitwise shift operations on strings are performed by converting the string to an integer and performing the operation on the result and returning an integer.	+	Currently, bitwise shift operations on strings are performed by converting the string to an integer and returning an integer. This behaviour does not match that of the other bitwise operators when they are used with string operands, as these perform the operation on a byte-by-byte basis, and return a string.
-		+
-	This behaviour does not match that of the other bitwise operators when they are used with string operands, as these perform the operation on a byte-by-byte basis, and return a string.	+

	This RFC proposes that the behaviour of the bitwise shift operators be altered, such that when the left operand is a string the shift operation is performed on the byte values of the string's characters, carrying bits between bytes as necessary. The will effectively treat the string as an arbitrarily large integer.		This RFC proposes that the behaviour of the bitwise shift operators be altered, such that when the left operand is a string the shift operation is performed on the byte values of the string's characters, carrying bits between bytes as necessary. The will effectively treat the string as an arbitrarily large integer.

rfc:strncmpnegativelen

2013-05-28T08:23:42+02:00

1323757042		current
Line 3:		Line 3:
	* Date: 2011-07-28		* Date: 2011-07-28
	* Author: Xinchen Hui <laruence@php.net>		* Author: Xinchen Hui <laruence@php.net>
-	* Status: Vote	+	* Status: Withdrawn
	* First Published at: http://wiki.php.net/rfc/strncmpnegativelen/		* First Published at: http://wiki.php.net/rfc/strncmpnegativelen/

rfc:structured_object_notation

2016-07-31T10:58:51+02:00

1469955227		current
Line 118:		Line 118:

	Instead of instantiating objects on the fly, here I propose a structured definition of an object using this syntax:		Instead of instantiating objects on the fly, here I propose a structured definition of an object using this syntax:
-	<code>	+	<code php>
-		+	object $app instanceof B{
-	Object $app instanceof B{	+
	$world = "midori";		$world = "midori";
	// allowed methods comes after method definition		// allowed methods comes after method definition
Line 140:		Line 139:
	};		};
	}		}
-		+	</code>
-	<code>	+

	An object can be instance of a class, if it's not defined, is instance of an anonymous class.		An object can be instance of a class, if it's not defined, is instance of an anonymous class.

rfc:svnexternals

2013-02-21T04:07:47+02:00

1302087566		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: SVN externals ======
	* Version: 1.0		* Version: 1.0
	* Date: 2008-07-01		* Date: 2008-07-01

rfc:switch.default.multiple

2014-09-16T16:48:59+02:00

1410876709		current
Line 32:		Line 32:

	* PHP 5.7: https://github.com/php/php-src/pull/807		* PHP 5.7: https://github.com/php/php-src/pull/807
-	* PHP 7.0: https://github.com/php/php-src/pull/808	+	* PHP 7.0: https://github.com/php/php-src/pull/808 (commit [[http://git.php.net/?p=php-src.git;a=commit;h=6967f78cc95ef6166f82dcb7e4395f594ce5ad0b\|6967f78cc95ef6166f82dcb7e4395f594ce5ad0b]])

	Already landed in HHVM:		Already landed in HHVM:

rfc:sync

2014-09-30T20:01:47+02:00

1412100087		current
Line 17:		Line 17:

	Currently, PHP only offers basic locking concept through the following possibilities:		Currently, PHP only offers basic locking concept through the following possibilities:
-	- File locking emulation	+	* File locking emulation
-	- Semaphore through System V compliant: sem_*	+	* Semaphore through System V compliant: sem_*
-	- Relying on pthreads extension	+	* Relying on pthreads extension

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

rfc:taint

2014-04-09T00:51:25+02:00

1343977925		current
Line 7:		Line 7:
	* Mailing list: [[http://marc.info/?l=php-internals\|PHP internals]]		* Mailing list: [[http://marc.info/?l=php-internals\|PHP internals]]
	* Miscellaneous: [[ftp://ftp.porcupine.org/pub/php/CHANGELOG\|Change log]] [[ftp://ftp.porcupine.org/pub/php/LICENSE\|License]] [[ftp://ftp.porcupine.org/pub/php/wietse-public-key.pgp\|pgp public key]]		* Miscellaneous: [[ftp://ftp.porcupine.org/pub/php/CHANGELOG\|Change log]] [[ftp://ftp.porcupine.org/pub/php/LICENSE\|License]] [[ftp://ftp.porcupine.org/pub/php/wietse-public-key.pgp\|pgp public key]]
-	* Status: In the works	+	* Status: Draft(Inactive)
	* Update: A pecl extension implemented: http://pecl.php.net/package/taint		* Update: A pecl extension implemented: http://pecl.php.net/package/taint

rfc:template

2015-12-07T15:37:49+02:00

1401467806		current
Line 37:		Line 37:

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
-	List the proposed PHP versions that the feature will be included in. Use relative versions such as "next PHP 5.x" or "next PHP 5.x.y".	+	List the proposed PHP versions that the feature will be included in. Use relative versions such as "next PHP 7.x" or "next PHP 7.x.y".

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

rfc:tempnam-suffix

2014-01-30T23:26:53+02:00

1391120517		current
Line 46:		Line 46:
	Changelog:		Changelog:
	5.6.0 The suffix parameter was added		5.6.0 The suffix parameter was added
		+

	Example #2 tempnam() example		Example #2 tempnam() example
-	<?php	+
		+	<code>
	$tmpfname = tempnam("/tmp", "FOO", ".png");		$tmpfname = tempnam("/tmp", "FOO", ".png");
	echo $tmpfname; // will be "/tmp/FOO<something>.png"		echo $tmpfname; // will be "/tmp/FOO<something>.png"
		+	</code>

rfc:this_var

2016-06-16T07:52:08+02:00

1465208127		current
Line 3:		Line 3:
	* Date: 2016-05-23		* Date: 2016-05-23
	* Author: Dmitry Stogov, dmitry@zend.com		* Author: Dmitry Stogov, dmitry@zend.com
-	* Status: Voting	+	* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/this_var		* First Published at: https://wiki.php.net/rfc/this_var

Line 183:		Line 183:
	The vote is a straight Yes/No vote, that requires a 2/3 majority.		The vote is a straight Yes/No vote, that requires a 2/3 majority.
	The voting began on Jun 6 and will close on Jun 16.		The voting began on Jun 6 and will close on Jun 16.
-	<doodle title="Fix inconsistent behavior of $this variable?" auth="dmitry" voteType="single" closed="false">	+	<doodle title="Fix inconsistent behavior of $this variable?" auth="dmitry" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 194:		Line 194:
	After the project is implemented, this section should contain		After the project is implemented, this section should contain
	- the version(s) it was merged to		- the version(s) it was merged to
-	- a link to the git commit(s)	+	- a link to the git commit [[ http://git.php.net/?p=php-src.git;a=commitdiff;h=a9512af8109e889eb2c6042c57797184930667cd\|a9512af8109e889eb2c6042c57797184930667cd]]
	- a link to the PHP manual entry for the feature		- a link to the PHP manual entry for the feature
-
-	===== Rejected Features =====
-	Keep this updated with features that were discussed on the mail lists.

rfc:throw_error_in_extensions

2016-07-05T08:53:51+02:00

1467316833		current
Line 3:		Line 3:
	* Date: 2016-06-14		* Date: 2016-06-14
	* Author: Aaron Piotrowski <aaron@trowski.com>		* Author: Aaron Piotrowski <aaron@trowski.com>
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/throw_error_in_extensions		* First Published at: http://wiki.php.net/rfc/throw_error_in_extensions

Line 82:		Line 82:
	Voting opened on 2016-06-27 at 4:00 pm GMT and will remain open until 2016-07-04 at 11:59 pm GMT		Voting opened on 2016-06-27 at 4:00 pm GMT and will remain open until 2016-07-04 at 11:59 pm GMT

-	<doodle title="Merge patch for PHP 7.1" auth="trowski" voteType="single" closed="false">	+	<doodle title="Merge patch for PHP 7.1" auth="trowski" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:throwable-interface

2015-06-17T07:03:17+02:00

1434515841		current
Line 120:		Line 120:
	Please remember that this vote is not about creating separate exception branches, as that decision was made in the [[https://wiki.php.net/rfc/engine_exceptions_for_php7\|Exceptions in the Engine RFC]]. This vote is about having short, concise, more intuitive names that clarify the separation rather than obfuscating it. ''Throwable'' and ''Error'' make stacked catch blocks cleaner with more obvious behavior. Voting no means keeping ''BaseException'', ''EngineException'', etc. that do not extend ''Exception'', but are named as though they do.		Please remember that this vote is not about creating separate exception branches, as that decision was made in the [[https://wiki.php.net/rfc/engine_exceptions_for_php7\|Exceptions in the Engine RFC]]. This vote is about having short, concise, more intuitive names that clarify the separation rather than obfuscating it. ''Throwable'' and ''Error'' make stacked catch blocks cleaner with more obvious behavior. Voting no means keeping ''BaseException'', ''EngineException'', etc. that do not extend ''Exception'', but are named as though they do.

-	Voting opened June 10th, 2015 and will remain open through June 16th, 2015.	+	Voting opened June 10th, 2015 and remained open until June 17th, 2015.

	<doodle title="Throwable Interface" auth="trowski" voteType="single" closed="true">		<doodle title="Throwable Interface" auth="trowski" voteType="single" closed="true">

rfc:throwable

2015-03-15T12:38:45+02:00

1426419338		current
Line 15:		Line 15:
	* Let ''Exception'' implement the ''Throwable'' interface		* Let ''Exception'' implement the ''Throwable'' interface
	* Remove ''BaseException''		* Remove ''BaseException''
-	* Let ''EngineException'' implement the ''Throwable'' interface	+	* Let ''EngineException'' and ''ParseException'' implement the ''Throwable'' interface
-	* Let ''ParseException'' extend the ''EngineException'' class	+

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

rfc:timing_attack

2014-06-25T15:35:06+02:00

1397424816		current
Line 61:		Line 61:
	* 0.2 Renamed to hash_compare, added link to Zend Framework 2, removed information leak when knownString is empty (Thank you Tjerk)		* 0.2 Renamed to hash_compare, added link to Zend Framework 2, removed information leak when knownString is empty (Thank you Tjerk)
	* 1.0 Moved function to ext/hash. Started voting.		* 1.0 Moved function to ext/hash. Started voting.
		+	* 1.1 Added section about differences between RFC and implementation
		+
		+	===== Differences between this RFC and the implementation ====
		+	* The function is now called hash_equals
		+	* Both arguments passed to the function have to be strings, otherwise an E_WARNING is raised.

rfc:timing_safe_encoding

2015-03-13T19:29:40+02:00

1426270916		current
Line 1:		Line 1:
-	====== PHP RFC: Your Title Here ======	+	====== PHP RFC: Timing Safe Encoding Functions ======
	* Version: 0.1		* Version: 0.1
	* Date: 2015-03-13		* Date: 2015-03-13

rfc:tls-peer-verification

2014-02-21T01:55:57+02:00

1390943893		current
Line 177:		Line 177:
	* Should secure-by-default client peer verification be implemented for 5.6?		* Should secure-by-default client peer verification be implemented for 5.6?

-	===== Patches and Tests =====	+	===== Implementation =====
-		+
-	The patch linked below is intended as final (subject to any changes instigated during the RFC process):	+

	* https://github.com/php/php-src/pull/494		* https://github.com/php/php-src/pull/494
-	* (update 2013-12-17) https://github.com/rdlowrey/php-src/commit/ae1a0479d562b2baed191a28ccd1b044db0c9d40
-	===== Implementation =====
-
-	* https://github.com/php/php-src/commit/6edc84fcdfc8e76507bc73122310fff4b6170b88

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

rfc:tls

2011-04-06T12:59:26+02:00

1262985105		current
Line 5:		Line 5:
	* Status: Under Discussion		* Status: Under Discussion
	* First Published at: http://marc.info/?l=php-internals&m=121893972814818&w=2		* First Published at: http://marc.info/?l=php-internals&m=121893972814818&w=2
-	* Initial patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch	+	* Initial patch: http://gist.github.com/659731
-	* Current patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls-2.patch	+	* Current patch: http://gist.github.com/659724

	Currently ZTS builds are slower than non-ZTS builds. This RFC is about avoiding some of the major overhead of ZTS builds by using native thread local storage.		Currently ZTS builds are slower than non-ZTS builds. This RFC is about avoiding some of the major overhead of ZTS builds by using native thread local storage.
Line 165:		Line 165:
	As the patch avoids passing tsrm_ls across function calls, #ifdef ZTS is not anymore relevant to check that.		As the patch avoids passing tsrm_ls across function calls, #ifdef ZTS is not anymore relevant to check that.
	The new PASS_TSRMLS macro is now defined when tsrm_ls needs to be passed across function calls. For instance this is needed by ZEND_ATTRIBUTE_FORMAT and some other places.		The new PASS_TSRMLS macro is now defined when tsrm_ls needs to be passed across function calls. For instance this is needed by ZEND_ATTRIBUTE_FORMAT and some other places.
-

rfc:token-get-always-tokens

2016-01-06T20:03:27+02:00

1451966408		current
Line 1:		Line 1:
	====== PHP RFC: token_get_all() flag to return consistent elements ======		====== PHP RFC: token_get_all() flag to return consistent elements ======
-	* Version: 1.0	+	* Version: 1.1
	* Date: 2016-01-04		* Date: 2016-01-04
	* Author: Sara Golemon <pollita@php.net>		* Author: Sara Golemon <pollita@php.net>
Line 21:		Line 21:

	===== Proposal =====		===== Proposal =====
-	This proposal aims to normalize the output of token_get_all (when requested) by always using associative arrays as the sub-elements in the output. For example, token_get_all("<?php ;", TOKEN_FULL) would output:	+	This proposal aims to normalize the output of token_get_all (when requested) by always using associative arrays as the sub-elements in the output. For example, token_get_all("<?php ;", TOKEN_ASSOC) would output:

	Array (		Array (
	[0] => Array (		[0] => Array (
-	[token] => int(374)	+	[id] => int(374)
	[text] => string(6)"<?php "		[text] => string(6)"<?php "
	[line] => int(1)		[line] => int(1)
	)		)
	[1] => Array (		[1] => Array (
-	[token] => int(59) // 59 == ord(';')	+	[id] => int(59) // 59 == ord(';')
	[text] => string(1) ";"		[text] => string(1) ";"
	[line] => int(1)		[line] => int(1)
Line 36:		Line 36:
	)		)

-	Note the use of a new constant TOKEN_FULL to be used with the flags parameter introduced in PHP 7.0	+	Note the use of a new constant TOKEN_ASSOC to be used with the flags parameter introduced in PHP 7.0

	==== Additional changes ====		==== Additional changes ====
Line 51:		Line 51:

	==== New Constants ====		==== New Constants ====
-	TOKEN_FULL - When present, token_get_all() will use the new format	+	TOKEN_ASSOC - When present, token_get_all() will use the new format

	===== Future Scope =====		===== Future Scope =====
Line 57:		Line 57:

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====
-	Introduce TOKEN_FULL and new scanner output format? 50% majority required	+	Introduce TOKEN_ASSOC and new scanner output format? 50% majority required

rfc:too_few_args

2016-06-16T07:55:03+02:00

1465196832		current
Line 3:		Line 3:
	* Date: 2016-06-01		* Date: 2016-06-01
	* Author: Dmitry Stogov, dmitry@zend.com		* Author: Dmitry Stogov, dmitry@zend.com
-	* Status: Voting	+	* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/too_few_args		* First Published at: https://wiki.php.net/rfc/too_few_args

Line 47:		Line 47:
	The vote is a straight Yes/No vote, that requires a 2/3 majority.		The vote is a straight Yes/No vote, that requires a 2/3 majority.
	The voting began on Jun 6 and will close on Jun 16.		The voting began on Jun 6 and will close on Jun 16.
-	<doodle title="Replace "Missing argument" warning with "Too few arguments" exception?" auth="dmitry" voteType="single" closed="false">	+	<doodle title="Replace "Missing argument" warning with "Too few arguments" exception?" auth="dmitry" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 58:		Line 58:
	After the project is implemented, this section should contain		After the project is implemented, this section should contain
	- the version(s) it was merged to		- the version(s) it was merged to
-	- a link to the git commit(s)	+	- a link to the git commit [[http://git.php.net/?p=php-src.git;a=commitdiff;h=ff363e2e7c58353b7e2751d1ca4d7bf616862aae\|ff363e2e7c58353b7e2751d1ca4d7bf616862aae]]
	- a link to the PHP manual entry for the feature		- a link to the PHP manual entry for the feature

rfc:trailing-comma-function-args

2013-03-25T19:28:43+02:00

1364236109		current
Line 3:		Line 3:
	* Date: 2013-02-19		* Date: 2013-02-19
	* Author: Sara Golemon <pollita@php.net>		* Author: Sara Golemon <pollita@php.net>
-	* Status: Voting Open	+	* Status: Rejected
	* First Published at: http://wiki.php.net/rfc/trailing-comma-function-args		* First Published at: http://wiki.php.net/rfc/trailing-comma-function-args

rfc:traits-with-interfaces

2016-02-22T21:17:10+02:00

1456171601		current
Line 269:		Line 269:
	Language spec patch, covering Proposal 1: https://github.com/php/php-langspec/compare/master...kevingessner:traits-with-interfaces		Language spec patch, covering Proposal 1: https://github.com/php/php-langspec/compare/master...kevingessner:traits-with-interfaces

-	Other patches TBD.	+	php-src patch implementing Proposal 1: https://github.com/php/php-src/pull/1773

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

rfc:traits

2012-01-30T09:27:06+02:00

1327063706		current
Line 1:		Line 1:
	====== Request for Comments: Traits for PHP (Superseded by Horizontal Reuse for PHP) ======		====== Request for Comments: Traits for PHP (Superseded by Horizontal Reuse for PHP) ======
-	This RFC is outdated and replaced by [[rfc:HorizontalReuse\|RFC: Horizontal Reuse for PHP]].

	* Version: 1.5		* Version: 1.5
	* Date: 2008-03-06		* Date: 2008-03-06
	* Author: Stefan Marr <php.at.stefan-marr.de>		* Author: Stefan Marr <php.at.stefan-marr.de>
-	* Status: Patch available, Superseded by [[rfc:HorizontalReuse\|Horizontal Reuse for PHP]]	+	* Status: Superseded by [[rfc:HorizontalReuse\|Horizontal Reuse for PHP]]
	* Patch: http://www.stefan-marr.de/archives/20-New-Traits-Patch-Ready-for-Testing.html		* Patch: http://www.stefan-marr.de/archives/20-New-Traits-Patch-Ready-for-Testing.html
	* First Published at: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html		* First Published at: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
Line 16:		Line 15:
	additional resources about Traits are given.		additional resources about Traits are given.

		+	This RFC is outdated and replaced by [[rfc:HorizontalReuse\|RFC: Horizontal Reuse for PHP]].
	===== Introduction =====		===== Introduction =====

rfc:traitsmodifications

2014-04-09T00:54:07+02:00

1302087566		current
Line 3:		Line 3:
	* Date: 2011-02-11		* Date: 2011-02-11
	* Author: Ben Schmidt <mail_ben_schmidt.at.yahoo.com.au>		* Author: Ben Schmidt <mail_ben_schmidt.at.yahoo.com.au>
-	* Status: Under Discussion	+	* Status: Inactive
	* First Published at: http://wiki.php.net/rfc/traitsmodifications		* First Published at: http://wiki.php.net/rfc/traitsmodifications
	* Other formats: None		* Other formats: None

rfc:travis_ci

2014-05-06T00:34:00+02:00

1398450252		current
Line 54:		Line 54:
	Proposed votes are as follows:		Proposed votes are as follows:

-	<doodle title="Accept the description in this RFC as an official policy of the PHP project with regard to the tests" auth="user" voteType="single">	+	<doodle title="Accept the description in this RFC as an official policy of the PHP project with regard to the tests" auth="user" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
Line 61:		Line 61:
	Choose one or more of the four options above of handling bad commits, keeping in mind that choosing particular option would be the decision of the RM.		Choose one or more of the four options above of handling bad commits, keeping in mind that choosing particular option would be the decision of the RM.

-	<doodle title="Choose one or more of the four options above of handling bad commits" auth="user" voteType="multi">	+	<doodle title="Choose one or more of the four options above of handling bad commits" auth="user" voteType="multi" closed="true">
	* Revert ASAP		* Revert ASAP
	* Revert after 1 week		* Revert after 1 week

rfc:true-nested-function-support

2013-02-21T04:04:52+02:00

1310992454		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: True nested function support ======
	* Version: 1.0		* Version: 1.0
	* Date: 2011-06-18		* Date: 2011-06-18

rfc:tsrmls-fetch-reduction

2011-04-06T12:59:26+02:00

1284215127		current
Line 2:		Line 2:
	* Version: 1.0		* Version: 1.0
	* Date: 2010-09-09		* Date: 2010-09-09
-	* Author: Felipe Pena <felipe@php.net>	+	* Author: Felipe Pena <felipe@php.net>, Pierre Alain Joye <pajoye@php.net>
-	* Status: Under Discussion	+	* Status: Under implementation

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

-	The purpose of RFC is to show a way to reduce several function call by avoiding useless TSRMLS_FETCH() usage on ZTS.	+	The purpose of RFC is to show a way to reduce several function call by avoiding useless TSRMLS_FETCH() usage on ZTS. Adding TSRMLS_CC to the memory allocation macros/function, hash api, zend_llist and streams.

	===== Changes ======		===== Changes ======
-
-	The main goal was to create a new version of each memory allocation function/macro where TSRMLS_FETCH() is not used, thus using these new functions/macros only when suitable avoiding to call the function that does thread id fetch.

	See below some macros/functions will be added by the patch.		See below some macros/functions will be added by the patch.

	^ Current function/macro ^ New function/macro ^		^ Current function/macro ^ New function/macro ^
-	\| emalloc \| emallocts \|	+	\| emalloc \| emalloc2 \|
-	\| ecalloc \| ecallocts \|	+	\| ecalloc \| ecalloc2 \|
-	\| pemalloc \| pemallocts \|	+	\| pemalloc \| pemalloc2 \|
-	\| erealloc \| ereallocts \|	+	\| erealloc \| erealloc2 \|
-	\| efree \| efreets \|	+	\| efree \| efree2 \|
-	\| estrdup \| estrdupts \|	+	\| estrdup \| estrdup2 \|
-	\| estrndup \| estrndupts \|	+	\| estrndup \| estrndup2 \|
-	\| ALLOC_INIT_ZVAL \| ALLOC_INIT_ZVAL_TS \|	+
-	\| SEPARATE_ZVAL \| SEPARATE_ZVAL_TS \|	+
-	\| SEPARATE_ZVAL_IF_NOT_REF \| SEPARATE_ZVAL_IF_NOT_REF_TS \|	+
-	\| SEPARATE_ZVAL_TO_MAKE_IS_REF \| SEPARATE_ZVAL_TO_MAKE_IS_REF_TS \|	+

	===== Profiler =====		===== Profiler =====

rfc:typechecking

2013-02-13T22:15:03+02:00

1332768713		current
Line 7:		Line 7:

	* [[rfc:returntypehint\|Return value type hint]] by Felipe		* [[rfc:returntypehint\|Return value type hint]] by Felipe
-	* [[rfc:returntypehint2\|Return value type hint]] by Will Fitch
	* [[rfc:typehint\|Return value and parameter type hint]] by Felipe		* [[rfc:typehint\|Return value and parameter type hint]] by Felipe
	* [[rfc:typecheckingstrictandweak\|Strict and weak parameter type checking]] by Lukas and Zeev		* [[rfc:typecheckingstrictandweak\|Strict and weak parameter type checking]] by Lukas and Zeev

rfc:typecheckingparseronly

2015-11-25T08:42:52+02:00

1302087566		current
Line 3:		Line 3:
	* Date: October 19, 2010		* Date: October 19, 2010
	* Author: Derick Rethans		* Author: Derick Rethans
-	* Status: Implemented	+	* Status: Previously Implemented
	* Based on: http://wiki.php.net/rfc/typecheckingstrictonly		* Based on: http://wiki.php.net/rfc/typecheckingstrictonly

rfc:typecheckingstrictandweak

2012-03-26T15:33:37+02:00

1302087566		current
Line 5:		Line 5:
	* Status: In discussion		* Status: In discussion
	* First Published at: http://wiki.php.net/rfc/typechecking		* First Published at: http://wiki.php.net/rfc/typechecking
		+	* Discussion: http://thread.gmane.org/gmane.comp.php.devel/61324

	This RFC provides a proposal for auto-converting parameter type checking for function/method parameters and the disadvantages of introducing strict scalar type hinting to PHP.		This RFC provides a proposal for auto-converting parameter type checking for function/method parameters and the disadvantages of introducing strict scalar type hinting to PHP.

rfc:typecheckingstrictonly

2011-04-06T12:59:26+02:00

1274392030		current
Line 3:		Line 3:
	* Date: October 22, 2009		* Date: October 22, 2009
	* Author: Ilia Alshanetsky		* Author: Ilia Alshanetsky
-	* Status: Implemented	+	* Status: Previously Implemented
	* First Published at: http://wiki.php.net/rfc/typecheckingstrictonly		* First Published at: http://wiki.php.net/rfc/typecheckingstrictonly

rfc:typecheckingweak

2011-04-06T12:59:26+02:00

1247469824		current
Line 116:		Line 116:
	The main 'contender' to this RFC is the Strict Typing RFC. Unlike Type Enforcement, Strict Typing is based on a strict comparison of the zval.type value. As such, it introduces an entirely new semantics to PHP, especially around parameter passing. Today, the zval.type is used only by a handful of functions (is_int() et al, gettype()), and the identity operator. These functions are much more rarely used than their more 'lax' siblings (is_numeric()) which are typically more appropriate; While the identity operator is typically used for specialized cases, e.g. when dealing with a function returning an integer, and having to tell boolean false apart. It is therefore argued that extending a zval.type-based checks into parameter passing - a center-piece of the language - will inadvertently change the theme of the language, and the expected 'lax' type checking behavior expected from it today.		The main 'contender' to this RFC is the Strict Typing RFC. Unlike Type Enforcement, Strict Typing is based on a strict comparison of the zval.type value. As such, it introduces an entirely new semantics to PHP, especially around parameter passing. Today, the zval.type is used only by a handful of functions (is_int() et al, gettype()), and the identity operator. These functions are much more rarely used than their more 'lax' siblings (is_numeric()) which are typically more appropriate; While the identity operator is typically used for specialized cases, e.g. when dealing with a function returning an integer, and having to tell boolean false apart. It is therefore argued that extending a zval.type-based checks into parameter passing - a center-piece of the language - will inadvertently change the theme of the language, and the expected 'lax' type checking behavior expected from it today.

-	In that context, it's important to mention that the two most common sources for data going into PHP - input data (_GET, _POST, etc.) and data coming from the database - are almost exclusively typed as strings. While some do type conversion during the input sanitizing phase - that is not always the case, especially with data coming from the database. Strict Typing is inherently incompatible with this concept, in the sense that it assumes the underlying data type (zval.type) is identical to the semantics of the value. It does not come to say that the two cannot be used together - but they are a pretty bad fit.	+	In that context, it's important to mention that the two most common sources for data going into PHP - input data (_GET, _POST, etc.) and data coming from external resources (e.g. databases, config files, memcached, etc.) - are almost exclusively typed as strings. While some do type conversion during the input sanitizing phase - that is not always the case, especially with data coming from the database. Strict Typing is inherently incompatible with this concept, in the sense that it assumes the underlying data type (zval.type) is identical to the semantics of the value. It does not come to say that the two cannot be used together - but they are a pretty bad fit.

	Furthermore - it is important to notice that the sole difference between Strict Typing and this proposed solution has to do with what happens outside the scope of the type-argumented function. In other words - all the benefits for the function code itself (readability, code reduction, optimization, etc.) is 100.0% identical. The semantics of what happens during the parameter-passing stage is what's different.		Furthermore - it is important to notice that the sole difference between Strict Typing and this proposed solution has to do with what happens outside the scope of the type-argumented function. In other words - all the benefits for the function code itself (readability, code reduction, optimization, etc.) is 100.0% identical. The semantics of what happens during the parameter-passing stage is what's different.

rfc:typed-properties

2016-06-27T12:05:40+02:00

1465882805		current
Line 3:		Line 3:
	* Date: 2016-03-16		* Date: 2016-03-16
	* Author: Joe Watkins <krakjoe@php.net>, Phil Sturgeon <philstu@php.net>		* Author: Joe Watkins <krakjoe@php.net>, Phil Sturgeon <philstu@php.net>
-	* Status: Voting	+	* Status: Declined
	* First Published at: http://wiki.php.net/rfc/typed-properties		* First Published at: http://wiki.php.net/rfc/typed-properties

Line 456:		Line 456:
	Voting started 10th June, ends 24th June 2016.		Voting started 10th June, ends 24th June 2016.

-	<doodle title="Merge typed properties ?" auth="krakjoe" voteType="single" closed="false">	+	<doodle title="Merge typed properties ?" auth="krakjoe" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:typehint

2011-04-06T12:59:26+02:00

1208443259		current
Line 4:		Line 4:
	* Author: Felipe Pena <felipensp@gmail.com>		* Author: Felipe Pena <felipensp@gmail.com>
	* Status: [[http://news.php.net/php.internals/37049\|Under Discussion]]		* Status: [[http://news.php.net/php.internals/37049\|Under Discussion]]
		+

	====== Details of implementation ======		====== Details of implementation ======
	Parameter type hint:		Parameter type hint:
-	- The behavior when the default parameter value is ''NULL'' was keeped.	+	- The behavior when the default parameter value is ''NULL'' was kept.
	Both:		Both:
	- Binary and unicode string are specified by ''string''.		- Binary and unicode string are specified by ''string''.

rfc:typesafe-callable

2016-04-05T21:38:22+02:00

1459807766		current
Line 9:		Line 9:
	Currently, when you typehint against "callable" in your method signatures, you can never be certain whether it accepts the parameters you are giving it or if the return type is what you'd expect. You can of course validate the return type, and catch exceptions about the invalid parameters and such when calling the callable, but that is not ideal.		Currently, when you typehint against "callable" in your method signatures, you can never be certain whether it accepts the parameters you are giving it or if the return type is what you'd expect. You can of course validate the return type, and catch exceptions about the invalid parameters and such when calling the callable, but that is not ideal.

-	This RFC tries to solve this problem by introducing implicit interface for callables.	+	This RFC tries to solve this problem by introducing user-defined callables.

	===== Proposal =====		===== Proposal =====
-	This RFC proposes to allow creating special interfaces which extend the "callable" type. A simple example could look like this:	+	This RFC proposes the definition of user-defined callables. Since "callable" is already a reserved keyword, this should not be a BC break. User-defined callables should be be both allowed to be namespaced like functions and classes, but also invoke the autoloader if they are not found in the current scope. A simple callable definition could look like this:

	<code php>		<code php>
-	interface MyCallable extends callable	+	callable FilterCallable(string $input) : string;
-	{	+
-	public function __invoke(string $foo) : int;	+
-	}	+
	</code>		</code>

-	Now any function or method could typehint against MyCallable instead of callable and be certain that the parameters are accepted and the correct type is returned:	+	With such a callable in place, the user can now typehint against it, like they would against any other property, and be certain that it will accept the parameters they pass in, as well as guarantee the return type they expect:

	<code php>		<code php>
-	function foo(MyCallable $foo) : int	+	function foo(FilterCallable $filter) : string
	{		{
-	return $foo('bar');	+	return $filter('bar');
	}		}

-	foo(function (string $foo) { return strlen($foo) });	+	foo(function (string $foo) : string { return trim($foo); });
	</code>		</code>

-	Of course, this works with any other kind of callable as well, be it a string, an array or an object. Even with the object, it would not have to implement the interface, since it is considered a special one due to the extension of the "callable" type.	+	Of course, this works with any other kind of callable as well, be it a string, an array or an object.
-		+
-	Since we do have an interface though, which technically represents a class, any callable would have to allow to be also invoked by calling $callable->__invoke().	+

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

rfc:uconverter

2012-12-06T01:03:33+02:00

1354752182		current
Line 10:		Line 10:

	<doodle		<doodle
-	title="Should the current UConverter implementation be merged" auth="cataphract" voteType="single" closed="False">	+	title="Should the current UConverter implementation be merged" auth="cataphract" voteType="single" closed="True">
	* Yes		* Yes
	* No		* No

rfc:umaintained_extensions

2016-08-18T09:06:10+02:00

1471503409		current
Line 29:		Line 29:
	^ Extension ^ Bugs in DB (minus reqs) ^ Oldest open bug ^ Newest bug ^ Most recent bugfix ^		^ Extension ^ Bugs in DB (minus reqs) ^ Oldest open bug ^ Newest bug ^ Most recent bugfix ^
	\| enchant \| 4 \| 2008-02-21 \| 2009-10-28 \| 2008-02-23 \|		\| enchant \| 4 \| 2008-02-21 \| 2009-10-28 \| 2008-02-23 \|
		+	\| ftp \| 26 \| 2010-05-10 \| 2016-06-06 \| 2016-08-16 \|
	\| gettext \| 6 \| 2007-12-11 \| 2015-09-24 \| 2015-08-31 \|		\| gettext \| 6 \| 2007-12-11 \| 2015-09-24 \| 2015-08-31 \|
	\| pdo_dblib \| 19 \| 2007-04-17 \| 2016-07-15 \| 2016-04-01 \|		\| pdo_dblib \| 19 \| 2007-04-17 \| 2016-07-15 \| 2016-04-01 \|

rfc:undeterministic_exceptions

2015-02-13T20:52:41+02:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Recoverably fatal exceptions in undeterministic contexts ======
	+	* Version: 0.1
	+	* Date: 2015-02-13
	+	* Author: Bob Weinand, bobwei9@hotmail.com
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/undeterministic_exceptions

	+	===== Introduction =====
	+	Exceptions thrown from undeterministic contexts, like destructors, signal handlers, tick handlers etc. shouldn't throw exceptions into the scope from which they were called.
	+
	+	That may lead to weird behavior, like unexpected types of exceptions. (For example a catch all handler for one specific task receives an exception thrown from a destructor due to garbage collection occurring. It will handle the error in an inappropriate way.)
	+
	+	===== Proposal =====
	+	Make uncaught exceptions, thrown from functions called from these undeterministic contexts, call the exception handler, and, if not handled, throw an E_RECOVERABLE_ERROR.
	+
	+	As undeterministic context counts everything which is not explicitly or implicitly called by direct use of an operator or function. (No, unset() only decrements the refcount, the calling of the destructor is a side-effect)
	+
	+	===== Backward Incompatible Changes =====
	+	That would break code relying on destructors to be called in a specific context. Which shouldn't be relied on. It only works in special cases like no cyclic references.
	+
	+	===== Proposed PHP Version(s) =====
	+	Next minor PHP version to come (7.0 in this case).
	+
	+	===== Proposed Voting Choices =====
	+	This vote doesn't affect the language itself, so it requires a 50%+1 majority.
	+
	+	===== Implementation =====
	+	// @TODO

rfc:unicode_escape

2016-03-13T03:05:39+02:00

1418950321		current
Line 127:		Line 127:

	Keep this updated with features that were discussed on the mail lists.		Keep this updated with features that were discussed on the mail lists.
		+
		+	===== Errata =====
		+
		+	The name of this RFC [[https://blog.ajf.me/2015-12-07-poorly-named-rfcs\|ought to have been "unicode codepoint escape sequence", not "unicode codepoint escape syntax"]].

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

		+	* (2016-03-13) Added Errata
	* v0.1.3 - ''\u'' without a following opening ''{'' passes through verbatim		* v0.1.3 - ''\u'' without a following opening ''{'' passes through verbatim
	* v0.1.2 - Ruby support		* v0.1.2 - Ruby support
	* v0.1.1 - Added Future Scope note on named literals		* v0.1.1 - Added Future Scope note on named literals
	* v0.1 - Initial version		* v0.1 - Initial version

rfc:unified-crypto-source

2014-02-13T11:06:05+02:00

1392285384		current
Line 13:		Line 13:
	===== Proposal =====		===== Proposal =====

-	Introduce 2 new INIs for UNIX like OSes.	+	Introduce 2 new INIs for all platforms.

-	Pseudo RNG - non-blocking. INI_PER_DIR	+	Pseudo RNG - non-blocking. INI_PERDIR
-	random.entropy_strong_source= (/dev/(u\|a)random etc. Default: /dev/urandom)	+	random.entropy_strong_source= (/dev/(u\|a)random etc. Default: depends on platform)

-	RNG - may block. INI_PER_DIR	+	RNG - may block. INI_PERDIR
-	random.entropy_crypto_source= (/dev/random etc. Default: /dev/random)	+	random.entropy_crypto_source= (/dev/random etc. Default: depends on platform)

-	Under windows, different values may be set.	+	Appropriate default for the platform is detected during build time.

	session.entropy_file uses /dev/*random. It share the random.entropy_strong_source if it is empty. (Like default_charset with Default Char Encoding RFC)		session.entropy_file uses /dev/*random. It share the random.entropy_strong_source if it is empty. (Like default_charset with Default Char Encoding RFC)
Line 46:		Line 46:
	* hardcoded default values		* hardcoded default values

-	None	+	None, but appropriate values will bet set for the platform.

	* php.ini-development values		* php.ini-development values
	* php.ini-production values		* php.ini-production values

-	random.entropy_strong_source=/dev/urandom (INI_PER_DIR)	+	;random.entropy_strong_source="/dev/urandom" (INI_PERDIR)
-	random.entropy_crypto_source=/dev/random (INI_PER_DIR)	+	;random.entropy_crypto_source="/dev/random" (INI_PERDIR)
		+
		+	Note: INI lines are commented out.

	Under Windows, different values may be set.		Under Windows, different values may be set.

rfc:uniform_variable_syntax

2014-08-27T20:06:57+02:00

1406678613		current
Line 2:		Line 2:
	* Date: 2014-05-31		* Date: 2014-05-31
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted (for PHP 7)	+	* Status: Implemented (in PHP 7)
	* Discussion: http://markmail.org/message/mr4ihbubfbdxygci		* Discussion: http://markmail.org/message/mr4ihbubfbdxygci

Line 276:		Line 276:
	</code>		</code>

-	This change is backwards incompatible (with low practical impact), which is the reason why this RFC targets PHP 6.	+	This change is backwards incompatible (with low practical impact), which is the reason why this RFC targets PHP 7.
	However it is always possible to recreate the old behavior by explicitly using braces:		However it is always possible to recreate the old behavior by explicitly using braces:

Line 285:		Line 285:
	</code>		</code>

-	This syntax will have guaranteed same behavior in both PHP 5 and PHP 6.	+	This syntax will have guaranteed same behavior in both PHP 5 and PHP 7.

	==== Newly added and generalized syntax ====		==== Newly added and generalized syntax ====
Line 357:		Line 357:
	occurrence of ''%%$loader[0]::$loader[1]($className)%%'' in the Doctrine class loader will be affected by this change.		occurrence of ''%%$loader[0]::$loader[1]($className)%%'' in the Doctrine class loader will be affected by this change.
	This occurrence must be replaced with ''%%$loader[0]::{$loader[1]}($className)%%'' to achieve compatibility with both		This occurrence must be replaced with ''%%$loader[0]::{$loader[1]}($className)%%'' to achieve compatibility with both
-	PHP 5 and PHP 6.	+	PHP 5 and PHP 7.

	The latter change turns currently valid syntax into a parse error. Expressions like ''%%global $$foo->bar%%'' are no		The latter change turns currently valid syntax into a parse error. Expressions like ''%%global $$foo->bar%%'' are no
	longer valid and ''%%global ${$foo->bar}%%'' must be used instead.		longer valid and ''%%global ${$foo->bar}%%'' must be used instead.

-	As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6.	+	As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 7.

	===== Open issues =====		===== Open issues =====

rfc:union_types

2016-06-25T17:13:28+02:00

1466867583		current
Line 166:		Line 166:
	This RFC requires that two-thirds of voters vote in favor of the RFC to pass.		This RFC requires that two-thirds of voters vote in favor of the RFC to pass.

-	<doodle title="Merge union types" auth="bwoebi" voteType="single" closed="false">	+	<doodle title="Merge union types" auth="bwoebi" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:unset_bool

2013-03-07T20:59:34+02:00

1362658103		current
Line 1:		Line 1:
	====== PHP RFC: unset(): return bool if the variable has existed ======		====== PHP RFC: unset(): return bool if the variable has existed ======
-	* Version: 0.6	+	* Version: 0.61
	* Date: 2013-03-06		* Date: 2013-03-06
	* Author: Bob Weinand, bobwei9@hotmail.com		* Author: Bob Weinand, bobwei9@hotmail.com
Line 17:		Line 17:
	Change unset()'s behaviour to:		Change unset()'s behaviour to:
	* return true if deletion was successful		* return true if deletion was successful
-	* return false if deletion failed	+	* return false if deletion failed (e.g. there was nothing to delete or the deleting function has failed)

	The feature could be useful in if's like:		The feature could be useful in if's like:
Line 158:		Line 158:
	* Version 0.52: echo may be also considered as a function...		* Version 0.52: echo may be also considered as a function...
	* Version 0.53: Added microbenchmark		* Version 0.53: Added microbenchmark
-	* Version 0.54: Added example real world use case	+	* Version 0.6: Added example real world use case
		+	* Version 0.61: Little clarification about failures

rfc:url_dots

2011-04-06T12:59:26+02:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: PHP 6 should maintain non-variable-name characters in GET/POST/COOKIE keys ======
	+	* Version: 1.0
	+	* Date: 2010-01-30
	+	* Author: Richard Lynch <lynch@php.net>
	+	* Status: Under Discussion
	+
	+	===== Introduction =====
	+
	+	This is an attempt to summarize a thread on the php-internals mailing list. Apologies for any lost content. And for my failure to do wiki markup well.
	+
	+	Historically, PHP replaced '.' and other characters not fitting the pattern ^[a-z][a-z_]+$ using '_' instead in requests, in order to be able to import variables with register_globals.
	+
	+	To be consistent $HTTP_GET_VARS and friends also replaced these characters with '_'
	+
	+	Later $_GET and friends also replaced these characters with '_'
	+
	+	In PHP 6, there will be no register_globals, and no real reason to change 'a.b' into 'a_b'
	+
	+	For example, ?a.b=2 could now safely turn into $_GET['a.b'] = '2'; rather than $_GET['a_b'] = '2';
	+
	+	==== Issues ====
	+	===== BC =====
	+	Given that PHP 6 is a major release, do we need BC, perhaps populating both 'a.b' and 'a_b'?
	+
	+	Are there any apps that detect 'a_b' and then blindly assume 'a.b' was the original, when it could just as well be 'a^b' or 'a\|b' or ...
	+
	+	And, if they do, are they not likely to be using the "original" character, whatever it is, and thus probably not break?
	+
	+	It seems likely that few apps would be broken by simply dropping the changes.
	+
	+	===== extract =====
	+	Currently, extract simply ignores 'a.b' or other invalid variable names found in keys.
	+	This should then cause no issues/problems.
	+
	+	===== ramifications =====
	+	Are there any characters valid in a URL that can NOT be used as keys in a hash?
	+
	+	These characters would still need to be addressed if they exist.
	+
	+	===== Proposal and Patch =====
	+
	+	PHP 6 should use the exact input from GET/POST/COOKIE as the key in $_GET/$_POST/$_COOKIE and not alter it to fit a variable name, since the cause of that behaviour is no longer extant.

1306889169		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.

1471390432		current
Line 213:		Line 213:
	===== Discussions =====		===== Discussions =====

-	== Why it should be in core? ==	+	==== Why it should be in core? ====

	There are users who misuse current filter module for "secure coding" input validations.		There are users who misuse current filter module for "secure coding" input validations.
Line 221:		Line 221:
	This proposal reduces filter module misuse which is built always by default.		This proposal reduces filter module misuse which is built always by default.

-	== Why not compare filter_var_array() result? ==	+	==== Why not compare filter_var_array() result? ====
	Following code may seem to work, but it would not.		Following code may seem to work, but it would not.

Line 238:		Line 238:
	For these reasons, comparing original and return(filtered) value is not suitable for strict input validation.		For these reasons, comparing original and return(filtered) value is not suitable for strict input validation.

-	== Framework should do this task ==	+	==== Framework should do this task ====

	There are several reasons doing this by PHP itself.		There are several reasons doing this by PHP itself.
Line 253:		Line 253:
	PHP is a first choice for Web development __because PHP can write simple web apps by simple codes__. PHP should try to keep this aspect as much as possible, and try to provide mandatory and/or best practice features. //Otherwise, PHP would not make much difference to other languages that require Web application frameworks even for a simple web apps.//		PHP is a first choice for Web development __because PHP can write simple web apps by simple codes__. PHP should try to keep this aspect as much as possible, and try to provide mandatory and/or best practice features. //Otherwise, PHP would not make much difference to other languages that require Web application frameworks even for a simple web apps.//

-	== Input validation and User input mistake handling difference ==	+	==== Input validation and User input mistake handling difference ====

	Although following reply is long, but it's worthwhile mentioning here.		Although following reply is long, but it's worthwhile mentioning here.

1444071811		current
Line 228:		Line 228:
	This removes the ability to define a callable as a single string composing a class-name and a method name separated by double-colons. The reasons for this are that:		This removes the ability to define a callable as a single string composing a class-name and a method name separated by double-colons. The reasons for this are that:

-	* It is duplication of ii. The duplication of code is not just in PHP core, but for all userland code and libraries that analyze callables must duplicate the handling.	+	* It is duplication of ii. The duplication of code is not just in PHP core, but for all userland code and libraries that analyze callables must duplicate the handling.

-	* For things like routing libraries it is useful for users to be able to specify not a valid callable, but instead a class that needs to be instantiated and the method that should be called on the instantiated object. Having 'classname::methodname' also be a valid callable makes this ambiguous as to whether the user meant to specify a static method of the class, or an instance method.	+	* For things like routing libraries it is useful for users to be able to specify not a valid callable, but instead a class that needs to be instantiated and the method that should be called on the instantiated object. Having 'classname::methodname' also be a valid callable makes this ambiguous as to whether the user meant to specify a static method of the class, or an instance method.

-	* It was introduced without much discussion to address a problem in the SPL iterator.	+	* It was introduced without much discussion to address a problem in the SPL iterator.
	https://github.com/php/php-src/commit/071eaf857633f36fb2b8748b3b08b3cac41f05bc There is no fundamental need for it in PHP.		https://github.com/php/php-src/commit/071eaf857633f36fb2b8748b3b08b3cac41f05bc There is no fundamental need for it in PHP.

-	* It is easier (in the sense of fewer CPU operations) to validate ['className', 'methodName'] as a valid callable than it is to validate 'className::methodName'. Currently each place inside the engine that requires to validate something like 'className::methodName' as a valid callable needs to i) Search for '::', ii) Check that the '::' isn't at the start of a string iii) allocate a string each to hold the classname and method name. By holding the className and methodName separately, those steps can be skipped, as the className and methodName can be used directly.	+	* It is easier (in the sense of fewer CPU operations) to validate ['className', 'methodName'] as a valid callable than it is to validate 'className::methodName'. Currently each place inside the engine that requires to validate something like 'className::methodName' as a valid callable needs to i) Search for '::', ii) Check that the '::' isn't at the start of a string iii) allocate a string each to hold the classname and method name. By holding the className and methodName separately, those steps can be skipped, as the className and methodName can be used directly.


Line 265:		Line 265:
	To allow users to resolve class-names in the compile stage of running a PHP script, the scope resolution operator will support `self` and `parent`.		To allow users to resolve class-names in the compile stage of running a PHP script, the scope resolution operator will support `self` and `parent`.

-	* self::class - represents the current class name. Gives a compilation error if used outside of either a class or abstract class context.	+	* self::class - the current class name. Gives a compilation error if used outside of either a class or abstract class context.

-	* parent::class - represent the class-name of the immediate parent of the current class. Gives a compilation error if used outside of a class or abstract context, or if the current class does not have a parent class.	+	* parent::class - the class-name of the immediate parent of the current class. Gives a compile error if used outside of a class or abstract context, or if the current class does not have a parent class.
-		+
-	Question are there any other cases where it should be allowed or forbidden?	+

	<code php>		<code php>
Line 297:		Line 295:

	</code>		</code>
-