rfc:typed_properties_v2
Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
rfc:typed_properties_v2 [2018/07/16 19:06] nikic remove todo for alias checks |
rfc:typed_properties_v2 [2019/01/11 16:16] (current) nikic Implemented |
||
---|---|---|---|
Line 5: | Line 5: | ||
* Proposed PHP version: PHP 7.4 | * Proposed PHP version: PHP 7.4 | ||
* Implementation: | * Implementation: | ||
- | * Status: | + | |
+ | | ||
===== Introduction ===== | ===== Introduction ===== | ||
Line 72: | Line 73: | ||
// All types with the exception of " | // All types with the exception of " | ||
public int $scalarType; | public int $scalarType; | ||
- | protected | + | protected |
- | private ?Type $nullableType; | + | private ?ClassName |
| | ||
// Types are also legal on static properties | // Types are also legal on static properties | ||
Line 95: | Line 96: | ||
For a discussion of the syntax choice, see the Alternatives section. | For a discussion of the syntax choice, see the Alternatives section. | ||
- | The fundamental invariant that is maintained by property type hints, is that a property read will always either return a value that satisfies the typehint, or throw a TypeError. While this sounds straightforward, | + | The fundamental invariant that is maintained by property type declaration, is that a property read will always either return a value that satisfies the declared type, or throw. While this sounds straightforward, |
In the following, the semantics of property type declarations are laid out in detail. | In the following, the semantics of property type declarations are laid out in detail. | ||
Line 134: | Line 135: | ||
iterable | iterable | ||
self, parent | self, parent | ||
- | ClassOrInterface | + | any class or interface name |
?type // where " | ?type // where " | ||
</ | </ | ||
Line 228: | Line 229: | ||
While textually the property types are the same, the resolved property types for both classes would be '' | While textually the property types are the same, the resolved property types for both classes would be '' | ||
- | If two different type hints to aliased classes are used, they are considered equal, if the alias is known at the time of inheritance checking. Depending on the usual early-binding rules, this may either be at compile-time or at run-time. The following code is legal: | + | If two different type declarations |
<code php> | <code php> | ||
Line 246: | Line 247: | ||
This is subject to the usual limitations affecting aliases during inheritance checks, such as [[https:// | This is subject to the usual limitations affecting aliases during inheritance checks, such as [[https:// | ||
+ | |||
+ | When two traits imported in the same class define the same property, then their property types must match, similar to the existing requirement that the default value must be the same. As such, the following code is invalid: | ||
+ | |||
+ | <code php> | ||
+ | trait T1 { | ||
+ | public int $prop; | ||
+ | } | ||
+ | trait T2 { | ||
+ | public string $prop; | ||
+ | } | ||
+ | class C { | ||
+ | use T1, T2; | ||
+ | } | ||
+ | </ | ||
==== Default Values ==== | ==== Default Values ==== | ||
Line 687: | Line 702: | ||
None. | None. | ||
- | |||
- | ===== Vote ===== | ||
- | |||
- | As this is a language change, a 2/3 majority is required. | ||
- | |||
- | Add support for typed properties as described in this RFC? | ||
===== Alternatives ===== | ===== Alternatives ===== | ||
Line 789: | Line 798: | ||
The third option is to take the visibility of the property into account when performing the callability check. That is, if the property is '' | The third option is to take the visibility of the property into account when performing the callability check. That is, if the property is '' | ||
- | The advantage of this solution is that it is quite ergonomic and even solves a part of the overall problem of '' | + | The advantage of this solution is that it is quite ergonomic and even solves a part of the overall problem of '' |
The fourth option is to automatically wrap assignments to '' | The fourth option is to automatically wrap assignments to '' | ||
Line 873: | Line 882: | ||
The previous RFC on typed properties did not permit acquiring references to typed properties. This has the significant disadvantage of creating an inconsistency and segregating the language. You can have typed properties, you can have references, but you can't have both. | The previous RFC on typed properties did not permit acquiring references to typed properties. This has the significant disadvantage of creating an inconsistency and segregating the language. You can have typed properties, you can have references, but you can't have both. | ||
- | Specifically, | + | Specifically, |
On the other hand, supporting references to typed properties makes the proposal significantly more complicated. A very large fraction of this proposal text is concerned with the behavior of references, and the large design space surrounding them. Additionally, | On the other hand, supporting references to typed properties makes the proposal significantly more complicated. A very large fraction of this proposal text is concerned with the behavior of references, and the large design space surrounding them. Additionally, | ||
Line 1226: | Line 1235: | ||
The different implementations need to be appropriately guarded by PHP version. | The different implementations need to be appropriately guarded by PHP version. | ||
+ | |||
+ | ===== Performance ===== | ||
+ | |||
+ | Dmitry has performed some benchmarks of the current typed properties implementation. The results are available at https:// | ||
+ | |||
+ | The main takeaway is that typed properties have an impact on performance even if they are not used. For applications, | ||
+ | |||
+ | ===== Vote ===== | ||
+ | |||
+ | As this is a language change, a 2/3 majority is required. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | ===== Errata ===== | ||
+ | |||
+ | During final implementation work after the RFC was accepted, a number of cases were encountered which weren' | ||
+ | |||
+ | ==== Automatic promotion of arrays and objects ==== | ||
+ | |||
+ | PHP automatically initializes falsy values that are used as arrays or objects to an empty array or '' | ||
+ | |||
+ | <code php> | ||
+ | class Test { | ||
+ | public ?int $prop = null; | ||
+ | } | ||
+ | |||
+ | $test = new Test; | ||
+ | $test-> | ||
+ | $test-> | ||
+ | |||
+ | $prop =& $test-> | ||
+ | $prop[] = 123; // TypeError, because we can't assign array to ?int | ||
+ | $prop-> | ||
+ | </ | ||
+ | |||
+ | ==== Strictness of runtime-evaluated default values ==== | ||
+ | |||
+ | Default values for both parameters and properties always follow the strict typing semantics, independently of the strict typing mode that applies in a particular file. However, there is one exception to this rule: If a constant expression parameter default value cannot be evaluated during compilation, | ||
+ | |||
+ | <code php> | ||
+ | function foo(int $x = FOO) { // currently allowed | ||
+ | var_dump($x); | ||
+ | } | ||
+ | define(' | ||
+ | foo(); | ||
+ | </ | ||
+ | |||
+ | For typed properties we do not make such an exception and following code will generate a TypeError: | ||
+ | |||
+ | <code php> | ||
+ | class Test { | ||
+ | public int $x = FOO; // TypeError | ||
+ | } | ||
+ | define(' | ||
+ | var_dump(new Test); | ||
+ | </ | ||
+ | |||
+ | The reason for this choice is that evaluation of constant expressions at compile-time vs run-time is an optimization choice and should not result in behavioral differences. Whether a constant expression is evaluated during compilation depends on many factors, including code order and whether or not opcache is enabled. We believe that the current behavior of parameters is a bug, not an intentional choice. | ||
+ | |||
+ | ==== Incrementing/ | ||
+ | |||
+ | When a value is incremented beyond '' | ||
+ | |||
+ | As stated, this would result in the following peculiar behavior: Incrementing an '' | ||
+ | |||
+ | As such, we would always generate an error on increment/ | ||
+ | |||
+ | To avoid this, we instead define that incrementing/ | ||
===== Changelog ===== | ===== Changelog ===== | ||
Line 1231: | Line 1311: | ||
Significant changes to the RFC are noted here. | Significant changes to the RFC are noted here. | ||
+ | * 2019-01-07: Add errata: Increment/ | ||
+ | * 2019-01-03: Add errata: Strictness of runtime-evaluated default values. | ||
+ | * 2019-01-03: Add errata: Automatic promotion of arrays and objects. | ||
+ | * 2018-07-16: Add note about compatibility requirement on properties coming from traits. | ||
* 2018-07-10: Add shim header to make porting extension easy. | * 2018-07-10: Add shim header to make porting extension easy. | ||
* 2018-07-10: Note that write_property signature has changed. | * 2018-07-10: Note that write_property signature has changed. |
rfc/typed_properties_v2.1531767997.txt.gz · Last modified: 2018/07/16 19:06 by nikic