Re: [RFC] Pure intersection types
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
Thread (13 messages)