Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117477
MIME-Version: 1.0
Date: Tue, 5 Apr 2022 12:58:14 +0100
Message-ID: <CAFPFaM+pJTUQYdiBiL134HK38eQrskE_yCrC_etrk3UXVGhoKg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000633e1f05dbe6f656"
Subject: Reflection changes due to allow null + false as standalone types RFC
From: george.banyard@gmail.com ("G. P. B.")

--000000000000633e1f05dbe6f656
Content-Type: text/plain; charset="UTF-8"

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

--000000000000633e1f05dbe6f656--