PHP Wiki

marking_return_value_as_important - Add reasoning for choosing warnings over exceptions

edorian (edorian@undisclosed.example.com) — 2025-02-05T10:49:12+00:00

2025/01/29 15:13		current
Line 59:		Line 59:

	When calling a function with the <php>#[\NoDiscard]</php> attribute, the engine shall validate whether or not the return value of the function is used and emit a <php>E_WARNING</php> (for native functions) or <php>E_USER_WARNING</php> (for userland functions) if the return value is not used.		When calling a function with the <php>#[\NoDiscard]</php> attribute, the engine shall validate whether or not the return value of the function is used and emit a <php>E_WARNING</php> (for native functions) or <php>E_USER_WARNING</php> (for userland functions) if the return value is not used.
		+
		+	A <php>E_(USER_)WARNING</php> was chosen over an exception to avoid BC concerns, as throwing would potentially break existing code that "works as implemented" and because this is only a warning in the literal sense of the word, given that the function executes successfully.

	The <php>$message</php> property of the <php>#[\NoDiscard]</php> attribute shall be part of the emitted warning, similar to the functionality of the [[rfc:deprecated_attribute\|#[\Deprecated] attribute]].		The <php>$message</php> property of the <php>#[\NoDiscard]</php> attribute shall be part of the emitted warning, similar to the functionality of the [[rfc:deprecated_attribute\|#[\Deprecated] attribute]].
Line 237:		Line 239:
	Functions having the attribute might emit a <php>E_WARNING</php> if they are used in an unsafe fashion. If a throwing error handler is used this may result in a breaking change. As the attribute shall only be applied to functions where not using the return value has a significant impact on correct functionality, we consider the benefit of pointing out the error to the user to outweigh the drawbacks, since suppressing the error by assigning to a dummy variable can be reliably performed in a way that is compatible with older PHP versions.		Functions having the attribute might emit a <php>E_WARNING</php> if they are used in an unsafe fashion. If a throwing error handler is used this may result in a breaking change. As the attribute shall only be applied to functions where not using the return value has a significant impact on correct functionality, we consider the benefit of pointing out the error to the user to outweigh the drawbacks, since suppressing the error by assigning to a dummy variable can be reliably performed in a way that is compatible with older PHP versions.

-	Using the <php>(void)</php> cast would previously result in a compile-time error, adding the <php>(void)</php> does therefore does not result in a backwards-incompatible change per se, but as it adds a new token to PHP’s tokenizer and changes the grammar of the language, it has an effect on static analysis tools and IDEs to understand the syntax.	+	<php>(void)</php> currently is a valid access to a constant named <php>void</php> with (unnecessary) parentheses. A GitHub search reveals that there is code that defines constants called <php>void</php>, both namespaced and in the global namespace, but a search for <php>(void)</php> does not reveal any hits outside of strings and comments, making this unlikely to be a problem in practice.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====
Line 286:		Line 288:
	</doodle>		</doodle>

-	50% + 1 to include the <php>(void)</php> cast.	+	2/3 to include the <php>(void)</php> cast.

	<doodle title="Implement the (void) cast to reliably suppress #[\NoDiscard]?" auth="timwolla" voteType="single" closed="true" closeon="2024-11-27T14:00:00Z">		<doodle title="Implement the (void) cast to reliably suppress #[\NoDiscard]?" auth="timwolla" voteType="single" closed="true" closeon="2024-11-27T14:00:00Z">

rfc - move consolidation to done

derick (derick@undisclosed.example.com) — 2025-02-04T11:00:18+00:00

2025/01/29 15:13		current
Line 13:		Line 13:
	This is section is for RFCs that are currently being voted on.		This is section is for RFCs that are currently being voted on.

-	* [[rfc:consolidate-coding-standard-policy-document\|Consolidate Coding Standards Policy Document]] (Until 2024-01-28)

	===== Under Discussion =====		===== Under Discussion =====
Line 118:		Line 117:
	==== Process and Policy ====		==== Process and Policy ====

-	* [[rfc:phpnet-analytics\|PHP.net Analytics]] (Created 2024-10-28, Vote opened 2024-11-20, Vote closes 2024-12-04)	+	* [[rfc:consolidate-coding-standard-policy-document\|Consolidate Coding Standards Policy Document]] (Vote closed 2024-01-28)
		+	* [[rfc:phpnet-analytics\|PHP.net Analytics]] (Created 2024-10-28, Vote opened 2024-11-20, Vote closed 2024-12-04)
	* [[rfc:third-party-code\|Policy on 3rd party code]] (Created 2024-10-02, Vote opened 2024-11-08, Vote closed 2024-11-22)		* [[rfc:third-party-code\|Policy on 3rd party code]] (Created 2024-10-02, Vote opened 2024-11-08, Vote closed 2024-11-22)
	* [[rfc:class-naming-acronyms\|Casing of acronyms in class and method names]] (Created and discussion started: 2024-04-05, Voting started 2024-02-22)		* [[rfc:class-naming-acronyms\|Casing of acronyms in class and method names]] (Created and discussion started: 2024-04-05, Voting started 2024-02-22)
Line 146:		Line 146:
	==== Pending Implementation / Landing ====		==== Pending Implementation / Landing ====

-	* [[rfc:error_backtraces_v2\|Error backtraces v2]] (Created 2024-12-5, voting started 2024-12-19, voting ended 2025-01-10 00:00:00 UTC)
	* [[rfc:attributes-on-constants\|Attributes on Constants]] (Created 2024-11-30, voting started 2024-12-16, voting ends 2025-01-06 00:00:00 UTC)		* [[rfc:attributes-on-constants\|Attributes on Constants]] (Created 2024-11-30, voting started 2024-12-16, voting ends 2025-01-06 00:00:00 UTC)
	* [[rfc:directory-opaque-object\|Change Directory class to behave like a resource object]] (Created 2024-09-14, Vote start: 2024-10-03, Vote end: 2024-10-20)		* [[rfc:directory-opaque-object\|Change Directory class to behave like a resource object]] (Created 2024-09-14, Vote start: 2024-10-03, Vote end: 2024-10-20)
Line 170:		Line 169:
	* [[rfc:closures_in_const_expr\|Support Closures in constant expressions]] (Created 2024-10-20, Vote ended 2024-11-27)		* [[rfc:closures_in_const_expr\|Support Closures in constant expressions]] (Created 2024-10-20, Vote ended 2024-11-27)
	* [[rfc:curl_share_persistence_improvement\|Persistent curl share handle improvement]] (Created 2024-11-27, Vote started 2024-12-11, Vote ended 2025-01-02 00:00:00 UTC)		* [[rfc:curl_share_persistence_improvement\|Persistent curl share handle improvement]] (Created 2024-11-27, Vote started 2024-12-11, Vote ended 2025-01-02 00:00:00 UTC)
		+	* [[rfc:error_backtraces_v2\|Error backtraces v2]] (Created 2024-12-5, Vote started 2024-12-19, Vote ended 2025-01-10 00:00:00 UTC)

	==== PHP 8.4 ====		==== PHP 8.4 ====

url_parsing_api

kocsismate (kocsismate@undisclosed.example.com) — 2025-02-04T07:40:45+00:00

2025/02/03 21:41		current
Line 343:		Line 343:
	The ''$context'' property refers to the substring where the error happened, while the ''$type'' property is a ''Uri\WhatWg\WhatWgErrorType'' enum storing the exact cause of the error. Last, the ''$failure'' field stores whether the error caused a failure, or processing could continue. Therefore, the ''true'' value refers to a hard error, while the ''false'' value means a soft error.		The ''$context'' property refers to the substring where the error happened, while the ''$type'' property is a ''Uri\WhatWg\WhatWgErrorType'' enum storing the exact cause of the error. Last, the ''$failure'' field stores whether the error caused a failure, or processing could continue. Therefore, the ''true'' value refers to a hard error, while the ''false'' value means a soft error.

-	When trying to instantiate a WHATWG ''Url'' via its constructor, a ''Uri\InvalidUriException'' is thrown, with the ''$errors'' property containing an array of ''Uri\WhatWg\WhatWgError'' instances when parsing is unsuccessful. When parsing is successful, the ''$softErrors'' by-ref parameter contains an array of ''Uri\WhatWg\WhatWgError'' instances, referring to soft errors, if any.	+	When trying to instantiate a WHATWG ''Url'' via its constructor, a ''Uri\InvalidUriException'' is thrown when parsing results in a failure. In this case, the ''Uri\InvalidUriException::$errors'' property will contain an array of ''Uri\WhatWg\WhatWgError'' instances. When parsing is successful, but soft errors were triggered, an array of ''Uri\WhatWg\WhatWgError'' will be passed by reference to the ''$softErrors'' parameter.

-	When trying to instantiate a WHATWG ''Url'' via its ''parse()'' method, a ''null'' return value indicates that parsing is unsuccessful, and the ''$errors'' by-ref parameter contains an array of ''Uri\WhatWg\WhatWgError'' instances. When parsing is successful, the ''$errors'' by-ref parameter contains an array of ''Uri\WhatWg\WhatWgError'' instances referring to only soft errors. The following example demonstrates some cases when a soft error is triggered:	+	When trying to instantiate a WHATWG ''Url'' via its ''parse()'' method, a ''null'' return value indicates that parsing results in a failure. In this case, the ''$errors'' by-ref parameter will contain an array of ''Uri\WhatWg\WhatWgError'' instances. When parsing is successful, but soft errors were triggered, the ''$errors'' by-ref parameter will contain an array of ''Uri\WhatWg\WhatWgError'' instances referring to only soft errors. The following example demonstrates how a soft error is triggered:

	<code PHP>		<code PHP>
Line 403:		Line 403:
	==== Accessors ====		==== Accessors ====

-	The individual URI components can be retrieved via getters, and immutable modification is possible via "wither" methods. While [[rfc:property-hooks\|property hooks]] and/or [[rfc:asymmetric-visibility-v2\|asymmetric visibility]] could be a modern replacement for getters, the RFC still chooses the more conservative getter-based approach because each URI component actually has be available in multiple forms in order to best serve the vastly different needs users may have. In order to best understand why this is necessary, the [[https://wiki.php.net/rfc/url_parsing_api#percent_encoding\|Percent-encoding]] and [[https://wiki.php.net/rfc/url_parsing_api#normalization\|Normalization]] sections give a good introduction.	+	The individual URI components can be retrieved via getters, and immutable modification is possible via "wither" methods. While [[rfc:property-hooks\|property hooks]] and/or [[rfc:asymmetric-visibility-v2\|asymmetric visibility]] could be a modern replacement for getters, the RFC still chooses the more conservative getter-based approach because each URI component actually has to be available in multiple forms in order to best serve the vastly different needs users may have. In order to best understand why this is necessary, the [[https://wiki.php.net/rfc/url_parsing_api#percent_encoding\|Percent-encoding]] and [[https://wiki.php.net/rfc/url_parsing_api#normalization\|Normalization]] sections give a good introduction.

	For now, let's see a very basic example for modifying and retrieving the host URI component:		For now, let's see a very basic example for modifying and retrieving the host URI component:
Line 610:		Line 610:

	For all these reasons, the topic of query parameter manipulation should be discussed as a followup to the current RFC.		For all these reasons, the topic of query parameter manipulation should be discussed as a followup to the current RFC.
		+
		+	===== How should URI modification work? =====
		+
		+	Since URIs are [[https://martinfowler.com/bliki/ValueObject.html\|value objects]] inherently, this RFC models them as immutable classes that support modification through withers. The usage of withers comes with some performance penalty - as a new instance is created for each modification -, but this is a necessity in order to hold identity constraints.
		+
		+	Alternatively, it would be possible to make URIs completely immutable by using the builder pattern to construct and modify URIs (i.e. by having a ''Uri\Rfc3986\UriBuilder'' and a ''Uri\WhatWg\UrlBuilder'' class). This way, new ''Uri'' instances would only be created once: after the very last modification. This is especially true when one wants to construct a completely new URI. That's why this solution seems more optimized than the wither based approach.
		+
		+	However, this is not always true. When one wants to modify only a single detail of a URI, then withers are not only easier to use but are more efficient as well:
		+
		+	<code php>
		+	// Redirection of HTTP traffic to HTTPS by using withers
		+
		+	$uri = new Uri\Rfc3986\Uri("http://example.com");
		+
		+	$uri = $uri->withScheme("https"); // a new URI instance is created at this point
		+	</code>
		+
		+	Whereas, the following piece of code should be used if URIs didn't support modification (given a hypothetical ''Uri\Rfc3986\UriBuilder'' class):
		+
		+	<code php>
		+	// Redirection of HTTP traffic to HTTPS by using the builder pattern
		+
		+	$uri = new Uri\Rfc3986\Uri("http://example.com/foo");
		+
		+	$builder = Uri\Rfc3986\UriBuilder::fromUri($uri);
		+	$builder->setScheme("https"); // overwrites the URI scheme
		+	$uri = $builder->build(); // a new URI instance is created at this point
		+	</code>
		+
		+	The above example makes it clear that the builder pattern mostly shines when it can save multiple instance creations, and it's especially true if a URI has to be constructed from the scratch:
		+
		+	<code php>
		+	// Redirection of HTTP traffic to HTTPS by using the builder pattern
		+
		+	$builder = Uri\Rfc3986\UriBuilder();
		+	$builder->setScheme("https")
		+	->setHost("example.com")
		+	->setPath("/foo");
		+
		+	$uri = $builder->build(); // a new URI instance is created at this point
		+	</code>
		+
		+	Builder classes are not offered by the present RFC just yet. They definitely have their use-case, as they can help write more optimized code, but they are not essential at the get go. Therefore, this feature is one of the top candidates of a followup RFC.
		+
		+	===== What about the user:password components of RFC 3986? =====
		+
		+	This has always been a source of contention. RFC 3986 states the following:
		+
		+	<blockquote>Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password)</blockquote>
		+
		+	TBD

	===== Parser Library Choice =====		===== Parser Library Choice =====
Line 655:		Line 706:
	</code>		</code>

-	However, there are other much more convenient approaches, but the current RFC still goes with the current, less ergonomic one, as going either way would need more discussion, and a scope creep. The improvement possibilities include passing URI instances to the functions in question, or converting URIs to streams based on [[https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/URL.html#openStream()\|Java's example]].	+	Even though there are other much more convenient approaches, the current RFC still goes with the current, less ergonomic one, as going either way would need more discussion, resulting in a scope creep. The improvement possibilities include passing URI instances to the functions in question, or converting URIs to streams based on [[https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/URL.html#openStream()\|Java's example]].

	===== Performance Considerations =====		===== Performance Considerations =====

return_break_continue_expressions - created

xepozz (xepozz@undisclosed.example.com) — 2025-02-02T13:32:07+00:00

2025/02/05 11:48	current
Line 1:	Line 1:
	+	<!DOCTYPE markdown>
	+	====== PHP RFC: Return, break and continue expressions ======
	+	* Version: 0.1
	+	* Date: 2025-02-02
	+	* Author: Dmitrii Derepko, xepozzd@gmail.com
	+	* Status: Draft

	+	===== Introduction =====
	+
	+	Allows to write return, break and continue with any conditions, shrinking long conditions.
	+
	+	You would be able to make such constructions as:
	+
	+	- Nullable action
	+	- `$value = $nullableValue ?? return;` or break or continue
	+	- `$element = $element->getParent() ?? return;` or break or continue
	+	- Otherwise action
	+	- `$condition ?: return;` or break or continue
	+	- `$var = $condition ? $value ? return false;` or break or continue
	+
	+	That would make these constructions be consistent with current `throws` flow, which is possible to use in any cases above.
	+
	+	===== Proposal =====
	+
	+	4 years ago there was proposal https://wiki.php.net/rfc/throw_expression about making "throws" statement as an expression,
	+	that gave users an ability to write some "guarding" constructions shortly.
	+
	+	This is another one round to make the whole PHP be more consistent:
	+	Making return, break and continue control operators be able to use as an expression.
	+
	+	## Examples
	+
	+	```php
	+	while ($condition) {
	+	$currentElement = $currentElement->getParent() ?? break; // is a new way
	+	// $currentElement = $currentElement->getParent();
	+	// if ($currentElement == null) return; // is an old way
	+	....
	+	}
	+	```
	+
	+	```php
	+	function doSmth($nullableValue) {
	+	$value = $nullableValue ?? return; // is a new way
	+	// $value = $nullableValue;
	+	// if ($value == null) return; // is an old way
	+	....
	+	}
	+	```
	+
	+	```php
	+	function doSmth($value) {
	+	guard($value) ?: return; // is a new way
	+	// if (guard($value)) return; // is an old way
	+	....
	+	}
	+	```
	+
	+	```php
	+	function doSmth(MyInterface $value) {
	+	$value instanceof MyImplementation ?: return; // is a new way
	+	// if (!$value instanceof MyImplementation) return; // is an old way
	+	....
	+	}
	+	```
	+
	+	```php
	+	function doSmth(int $value) {
	+	$value >= 0 ?: return; // is a new way
	+	// if ($value < 0) return; // is an old way
	+	....
	+	}
	+	```
	+
	+	Typical "early return" cases in some instructions with state preparations:
	+
	+	New way:
	+	```php
	+	function doSmth($id): Result {
	+	$user = $this->finder->findUserById($id) ?? return null;
	+	$account = $this->finder->findAccountByUserId($user->id) ?? return null;
	+
	+	$result = $this->doSmthInternal($user, $account) ?: return Result::internalError();
	+
	+	return $result->isOk ? Result::success($result->resultJson) : Result::error($result->errorText);
	+	}
	+	```
	+
	+	Old way:
	+	```php
	+	function doSmth($id): Result {
	+	$user = $this->finder->findUserById($id);
	+	if ($user === null) {
	+	return null;
	+	}
	+	$account = $this->finder->findAccountByUserId($user->id);
	+	if ($account === null) {
	+	return null;
	+	}
	+
	+	$result = $this->doSmthInternal($user, $account);
	+	if ($result === null) {
	+	return Result::internalError();
	+	}
	+
	+	return $result->isOk ? Result::success($result->resultJson) : Result::error($result->errorText);
	+	}
	+	```
	+
	+	One more interesting point that the most PHP codestyle variations translate one-liner `if ($cond) return;` into 3 lines.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	Fully compatible
	+
	+	===== Proposed PHP Version(s) =====
	+	next PHP 8.5 or next PHP 9.x versions
	+
	+	==== To Opcache ====
	+	It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP.
	+
	+	Please explain how you have verified your RFC's compatibility with opcache.
	+
	+	===== 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 section 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.
	+
	+	===== 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.
	+
	+	For changes affecting the core language, you should also provide a patch for the language specification.
	+
	+	===== Implementation =====
	+
	+	After the project is implemented, this section should contain
	+	- the version(s) it was merged into
	+	- a link to the git commit(s)
	+	- a link to the PHP manual entry for the feature
	+	- a link to the language specification section (if any)
	+
	+	===== References =====
	+
	+	https://news-web.php.net/php.internals/122253
	+
	+	https://github.com/php/php-src/pull/17647
	+
	+	Links to external references, discussions or RFCs
	+
	+	===== Rejected Features =====
	+
	+	Keep this updated with features that were discussed on the mail lists.

gitworkflow - Also specify atomic flag for multi-branch pushes

ilutov (ilutov@undisclosed.example.com) — 2025-01-31T13:51:41+00:00

2023/08/31 08:55		current
Line 89:		Line 89:
	$ git merge PHP-8.1		$ git merge PHP-8.1
	$ make test		$ make test
-	$ git push origin PHP-7.4 PHP-8.0 PHP-8.1 master	+	$ git push --atomic origin PHP-7.4 PHP-8.0 PHP-8.1 master

	Additionally, the history of pull requests often requires cleanup. For most pull requests, all commits can be squashed into one.		Additionally, the history of pull requests often requires cleanup. For most pull requests, all commits can be squashed into one.
Line 119:		Line 119:
	If a patch is related to a bug ticket or is worth it a mention otherwise, the NEWS file needs to be updated to reflect the change done. The NEWS entry has to be added manually in every branch, where the patch is applied. Whereby NEWS in master is being updated only for master only patches. More info is available in the corresponding section in [[http://git.php.net/?p=php-src.git;a=blob;f=README.GIT-RULES;hb=refs/heads/master\|README.GIT-RULES]].		If a patch is related to a bug ticket or is worth it a mention otherwise, the NEWS file needs to be updated to reflect the change done. The NEWS entry has to be added manually in every branch, where the patch is applied. Whereby NEWS in master is being updated only for master only patches. More info is available in the corresponding section in [[http://git.php.net/?p=php-src.git;a=blob;f=README.GIT-RULES;hb=refs/heads/master\|README.GIT-RULES]].

		+	When merging upwards, you can either commit the NEWS entry separately, or as part of the merge commit. To do that, merge using ''git merge PHP-8.2 --no-commit'', add the NEWS entry, add it to the staging area, and ''git merge --continue''.

	===== Feature Workflow for Core Developers =====		===== Feature Workflow for Core Developers =====

error_backtraces_v2 - add link to implementation

enorris (enorris@undisclosed.example.com) — 2025-01-29T15:46:54+00:00

2024/12/19 21:01		current
Line 3:		Line 3:
	* Date: 2024-12-05		* Date: 2024-12-05
	* Author: Eric Norris, erictnorris@gmail.com		* Author: Eric Norris, erictnorris@gmail.com
-	* Status: Voting	+	* Status: Implemented
	* First Published at: https://wiki.php.net/rfc/error_backtraces		* First Published at: https://wiki.php.net/rfc/error_backtraces
		+	* Implementation: https://github.com/php/php-src/commit/0a14ab18d2b3bcf1358aa9f25efc1ad72c18d000

	===== Introduction =====		===== Introduction =====
Line 102:		Line 103:
	This vote requires a ⅔ majority:		This vote requires a ⅔ majority:

-	<doodle title="Add a fatal_error_backtraces INI setting as described" auth="enorris" voteType="single" closed="false" closeon="2025-01-10T00:00:00Z">	+	<doodle title="Add a fatal_error_backtraces INI setting as described" auth="enorris" voteType="single" closed="true" closeon="2025-01-10T00:00:00Z">
	* Yes		* Yes
	* No		* No
Line 111:		Line 112:
	This vote will require a simple majority:		This vote will require a simple majority:

-	<doodle title="Default value for fatal_error_backtraces" auth="enorris" voteType="single" closed="false" closeon="2025-01-10T00:00:00Z">	+	<doodle title="Default value for fatal_error_backtraces" auth="enorris" voteType="single" closed="true" closeon="2025-01-10T00:00:00Z">
	* '1'		* '1'
	* '0'		* '0'
Line 120:		Line 121:
	This vote determines if we need to update all ''phpt'' tests in the ''php-src'' repo that feature fatal errors. It depends on the default value, and will require a simple majority:		This vote determines if we need to update all ''phpt'' tests in the ''php-src'' repo that feature fatal errors. It depends on the default value, and will require a simple majority:

-	<doodle title="If fatal_error_backtraces defaults to 1, default value in run-tests.php" auth="enorris" voteType="single" closed="false" closeon="2025-01-10T00:00:00Z">	+	<doodle title="If fatal_error_backtraces defaults to 1, default value in run-tests.php" auth="enorris" voteType="single" closed="true" closeon="2025-01-10T00:00:00Z">
	* '1'		* '1'
	* '0'		* '0'

consolidate-coding-standard-policy-document

derick (derick@undisclosed.example.com) — 2025-01-28T15:54:49+00:00

2025/01/14 15:16		current
Line 22:		Line 22:
	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

-	2/3rds majority required. The vote runs until January 28st, 16:00 UTC.	+	2/3rds majority required. The vote runs until January 28th, 16:00 UTC.

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

speed.svg - created

divinity76 (divinity76@undisclosed.example.com) — 2025-01-24T09:50:19+00:00

	current

output_5_.png - created

divinity76 (divinity76@undisclosed.example.com) — 2025-01-24T09:47:20+00:00

	current

iri_venn_diagramm.svg - created

kocsismate (kocsismate@undisclosed.example.com) — 2025-01-23T08:55:06+00:00

	current

105434d8f6ee317dfe.jpg - removed

nielsdos (nielsdos@undisclosed.example.com) — 2023-08-26T11:13:31+00:00

	current

bench.png

nielsdos (nielsdos@undisclosed.example.com) — 2023-08-24T21:45:45+00:00

1691881114	current

imagemagick-configure.gif - created

cmb (cmb@undisclosed.example.com) — 2021-11-03T13:55:20+00:00

	current

bug_report_3.png - created

nikic (nikic@undisclosed.example.com) — 2021-11-01T15:30:47+00:00

	current

bug_report_2.png - created

nikic (nikic@undisclosed.example.com) — 2021-11-01T15:29:28+00:00

	current

bug_report.png - created

nikic (nikic@undisclosed.example.com) — 2021-11-01T13:53:33+00:00

	current

bug_selection.png - created

nikic (nikic@undisclosed.example.com) — 2021-11-01T13:44:50+00:00

	current

fiber-flow.png

trowski (trowski@undisclosed.example.com) — 2021-02-12T20:41:13+00:00

1608176911	current

return-if-visual-reasoning.png - created

ralphschindler (ralphschindler@undisclosed.example.com) — 2020-05-16T19:30:29+00:00

	current

return-early-visual-reasoning.png - created

ralphschindler (ralphschindler@undisclosed.example.com) — 2020-05-16T19:27:48+00:00

	current