rfc:dnf_types

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:dnf_types [2021/11/04 21:30] – Add note on redundant types crellrfc:dnf_types [2023/01/21 22:12] (current) – Typo in code example, brakets are not allowed for standalone intersection types girgias
Line 2: Line 2:
   * Version: 0.9   * Version: 0.9
   * Date: 2021-11-04   * Date: 2021-11-04
-  * Author: George Peter Banyard, girgias@php.net; Larry Garfield, crell@php.net +  * Author: George Peter Banyard <girgias@php.net>; Larry Garfield <crell@php.net> 
-  * Status: Draft+  * Status: Accepted
   * First Published at: http://wiki.php.net/rfc/dnf_types   * First Published at: http://wiki.php.net/rfc/dnf_types
  
Line 63: Line 63:
  
 <code> <code>
-(A&B)|(C&D|(Y&D)|null+(A&B)|(C&D)|(Y&D)|null
 (B&A)|null|(D&Y)|(C&D) (B&A)|null|(D&Y)|(C&D)
 null|(C&D)|(B&A)|(Y&D) null|(C&D)|(B&A)|(Y&D)
 </code> </code>
  
-Requiring DNF for all type declarations allows conceptually all potential combinations of intersection and union rules, but in a standard fashion that is easier for the engine and easier for humans and static analyzers to comprehend.  It also obviates the need for parentheses anywhere in the type definition.+Requiring DNF for all type declarations allows conceptually all potential combinations of intersection and union rules, but in a standard fashion that is easier for the engine and easier for humans and static analyzers to comprehend.
  
-The parentheses around each intersection portion is required.  Single-type portions do not require parentheses.  +The parentheses around each intersection segment is required.  Single-type segments do not require parentheses.  
  
 ==== Return co-variance ==== ==== Return co-variance ====
Line 83: Line 83:
 // Acceptable.  A&B is more restrictive. // Acceptable.  A&B is more restrictive.
 class TestOne implements ITest { class TestOne implements ITest {
-  public function stuff(): (A&B) {}+  public function stuff(): A&B {}
 } }
  
Line 166: Line 166:
 A type declaration of ''(A&B)|(B&A)'' is invalid.  The two ORed segments are logically equivalent, and thus superficially redundant. A type declaration of ''(A&B)|(B&A)'' is invalid.  The two ORed segments are logically equivalent, and thus superficially redundant.
  
-Note that a type declaration of ''(A&B)|C'' is not necessarily redundant, as C could include other methods beyond what it inherits, and an object could implement A, B, and D and still be accepted by the first segment and not the second.+Note that a type declaration of ''(A&B)|C'' is not necessarily redundant, as C could include other methods beyond what it inherits, and an object could implement ''A'', ''B'', and ''D'' and still be accepted by the first segment and not the second. 
 + 
 +  * Segments that are strict subsets of others are disallowed. 
 + 
 +For example, the type definition ''(A&B)|A'' is redundant, because all instances of ''A'' are already allowed, whether they also implement ''B'' or not.  That definition is redundant and thus invalid.
  
 This does not guarantee that the type is "minimal", because doing so would require loading all used class types. This does not guarantee that the type is "minimal", because doing so would require loading all used class types.
Line 174: Line 178:
 This RFC does not introduce any new reflection classes.  However, it does make one change to the Reflection API, in that ''ReflectionUnionType::getTypes()'' previously was guaranteed to always return an array of ''ReflectionNamedType'' instances.  Now it will return some combination of ''ReflectionNamedType'' and ''ReflectionIntersectionType'' instances.  The method is already typed to return ''ReflectionType'' so this is not an API change, but the previous de facto assumption is no longer valid. This RFC does not introduce any new reflection classes.  However, it does make one change to the Reflection API, in that ''ReflectionUnionType::getTypes()'' previously was guaranteed to always return an array of ''ReflectionNamedType'' instances.  Now it will return some combination of ''ReflectionNamedType'' and ''ReflectionIntersectionType'' instances.  The method is already typed to return ''ReflectionType'' so this is not an API change, but the previous de facto assumption is no longer valid.
  
-''ReflectionIntersectionType::getTypes()'' will still only return ''ReflectionNmaedType'' in practice, although its return type is similarly ''ReflectionType''.+''ReflectionIntersectionType::getTypes()'' will still only return ''ReflectionNamedType'' in practice, although its return type is similarly ''ReflectionType''.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 184: Line 188:
 8.2 8.2
  
-===== Open Issues =====+===== Vote =====
  
-Make sure there are no open issues when the vote starts!+As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.
  
-===== Unaffected PHP Functionality ===== +Voting started on 2022-06-17 and will end on 2022-07-01. 
- +<doodle title="Accept Disjunctive Normal Form Types RFC?" auth="girgias" voteType="single" closed="true"> 
-List existing areas/features of PHP that will not be changed by the RFC. +   * Yes 
- +   * No 
-This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.+</doodle>
  
 ===== Future Scope ===== ===== Future Scope =====
Line 198: Line 202:
 ==== Non-DNF types ==== ==== Non-DNF types ====
  
-In theory, supporting conjunctive normal form type definitions (and ANDed list of ORs) may be possible.  However, as DNF is able to represent all reasonable boolean expressions the authors have no intent to pursue this direction.+In theory, supporting conjunctive normal form type definitions (and ANDed list of ORs) or types which are not in a normalised form may be possible, either by supporting them directly or doing a compile time rewrite of the type expression. 
 + 
 +However, as DNF is able to represent all reasonable boolean expressions and having a normalized form simplifies both the engine implementation and user-space reflection code, the authors have no intent to pursue this direction.
  
 ==== Type aliasing ==== ==== Type aliasing ====
Line 210: Line 216:
 ===== Patches and Tests ===== ===== Patches and Tests =====
  
-Patch is available here: https://github.com/Girgias/php-src/pull/10+Patch is available here: https://github.com/php/php-src/pull/8725
  
 ===== Implementation ===== ===== Implementation =====
rfc/dnf_types.1636061449.txt.gz · Last modified: 2021/11/04 21:30 by crell

Page Tools