On Mon, May 17, 2021, at 3:58 AM, G. P. B. wrote: > Hello internals, > > As we are getting closer to feature freeze I want to move this proposal > forward. > The RFC is now also on the wiki: > https://wiki.php.net/rfc/pure-intersection-types > > Composite types are left out of scope as it seems they should be handled > with grouping (e.g. (A&B) | C ) and not relying on the precedence of the > union operator. > > It should also be noted that to get this working there is some parser > hackery done to circumvent the fact the it cannot resolve the ambiguity > between & for an intersection type and & for by-ref arguments.
I am very much a fan. On the reflection front, am I correct that we'd end up with: abstract ReflectionType -- ReflectionNamedType (single type) -- ReflectionUnionType (basically an array of named types) -- ReflectionIntersectionType (basically an array of named types) Where ReflectionUnionType and ReflectionIntersectionType are basically the same API to decompose further. And should combined intersection/union types be added in the future, the impact would be that their getTypes() methods would return an array of some combination of ReflectionTypes, whereas right now you could rely on them being ReflectioNamedType. (But that also means one could build ahead for that already with a little recursion.) Am I following that correctly? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
