rfc:new_in_initializers

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
rfc:new_in_initializers [2021/06/16 07:46]
nikic
rfc:new_in_initializers [2021/06/30 07:51]
nikic
Line 2: Line 2:
   * Date: 2021-03-02   * Date: 2021-03-02
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
-  * Status: Under Discussion+  * Status: Voting
   * Proposed Version: PHP 8.1   * Proposed Version: PHP 8.1
-  * Implementation: https://github.com/php/php-src/pull/6746+  * Implementation: https://github.com/php/php-src/pull/7153
  
 ===== Introduction ===== ===== Introduction =====
Line 85: Line 85:
 New expressions continue to not be supported in (static and non-static) property initializers and class constant initializers. The reasons for this are twofold: New expressions continue to not be supported in (static and non-static) property initializers and class constant initializers. The reasons for this are twofold:
  
-For non-static property initializers, the initializer expression needs to be evaluated on each object creation. There are currently two places where this could happen: As part of object creation, and as part of the constructor call. Doing this as part of object creation can create issues for unserialization and any other process that is based on ''newInstanceWithoutConstructor()'' and generally does not want to implicitly execute potential side-effects.+For non-static property initializers, the initializer expression needs to be evaluated on each object creation. There are currently two places where this could happen: As part of object creation, and as part of the constructor call. Doing this as part of object creation can create issues for unserialization and any other process that is based on ''newInstanceWithoutConstructor()'' and does not want to implicitly execute potential side-effects.
  
 Performing the initialization by injecting code in the constructor avoids the issue, but requires that constructor to actually be called. In particular, this would necessitate generating constructors for classes that do not explicitly declare them, and the disciplined invocation of such constructors from potential child constructors. The third option would be to introduce an additional initialization phase between creation and construction. Performing the initialization by injecting code in the constructor avoids the issue, but requires that constructor to actually be called. In particular, this would necessitate generating constructors for classes that do not explicitly declare them, and the disciplined invocation of such constructors from potential child constructors. The third option would be to introduce an additional initialization phase between creation and construction.
  
-For static property initializers and class constant initializers a different evaluation order issue arises. Currently, these initializers are evaluated lazily the first time a class is used in a certain way. Once initializers can contain potentially side-effecting expressions, it would be preferable to have a more well-defined evaluation order. However, the straightforward approach of evaluating initilizers when the class is declared would break certain existing code patterns. In particular, referencing a class that is declared later in the same file would no longer work.+For static property initializers and class constant initializers a different evaluation order issue arises. Currently, these initializers are evaluated lazily the first time a class is used in a certain way (e.g. instantiated). Once initializers can contain potentially side-effecting expressions, it would be preferable to have a more well-defined evaluation order. However, the straightforward approach of evaluating initilizers when the class is declared would break certain existing code patterns. In particular, referencing a class that is declared later in the same file would no longer work.
  
 As such support in these contexts is delayed until such a time as a consensus on the preferred behavior can be reached. As such support in these contexts is delayed until such a time as a consensus on the preferred behavior can be reached.
Line 123: Line 123:
 ===== Future Scope ===== ===== Future Scope =====
  
-This RFC is narrow in that it only adds support for ''new'' expressionsHowever, it also lays the technical groundwork for supporting other expressions like calls.+This RFC omits support for ''new'' in property and class constant initializersThese could be supported in the future, once we have figured out the evaluation order issues. 
 + 
 +With the precedent set by ''new'', it would probably also make sense to allow other call expressions. For example, this would allow use of static factor methods.
  
 ===== Vote  ===== ===== Vote  =====
  
-Yes/No.+Voting opened on 2021-06-30 and closes on 2021-07-14. 
 + 
 +<doodle title="Support new in initializers as proposed?" auth="nikic" voteType="single" closed="false"> 
 +   Yes 
 +   No 
 +</doodle>
  
rfc/new_in_initializers.txt · Last modified: 2021/07/14 07:19 by nikic