Reflection changes due to allow null + false as standalone types RFC

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/

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