Probably best with consistency?

 > - Ignore the Reflection changes of the RFC and align the union type with
the current behaviour

This one, specifically.

I'd love to see all nullable types become
`ReflectionUnionType(ReflectionNamedType($t), ReflectionNamedType(null))`,
but that would be a BC break for later on :-)

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/


On Tue, 5 Apr 2022 at 13:58, G. P. B. <george.bany...@gmail.com> wrote:

> Hello internals,
>
> During the review of the implementation of the RFC which introduces null
> and false as standalone types there has been a point raised about the
> changes made to reflection. [1]
>
> The current implementation is what follows the RFC, namely to make
> false|null return a ReflectionUnionType instead of a ReflectionNamedType.
> Because of this, I made the rendering of this type union to be false|null
> instead of ?false.
>
> Moreover, the question is if this union type should not be consistent with
> other types and produce a ReflectionNamedType, and have all of the nullable
> types move to ReflectionUnionType at the same time.
>
> I don't mind either way, but as this was voted part of the RFC I feel this
> should be discussed by internals to see if changing the Reflection
> semantics to not align with the RFC is okay.
>
> As there are currently the following options:
> - Keep as the RFC stated with some minor implementation complexity which
> will be resolved when the Reflection changes are made to all other nullable
> types.
> - Ignore the Reflection changes of the RFC and align the union type with
> the current behaviour
> - Break BC and change all nullable types to return a ReflectionUnionType
>
> (I just added the last option for the sake of completeness, but don't think
> breaking BC is the way to go here).
>
> Best regards,
>
> George P. Banyard
>
> [1] https://github.com/php/php-src/pull/7546#discussion_r837900447
>

Reply via email to