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

Hi George, > https://github.com/php/php-src/pull/7546#discussion_r837900447 Thanks for asking (even if voted). On Tue, Apr 5, 2022 at 2:01 PM Marco Pivetta <ocramius@gmail.com> wrote: > Probably best with consistency? > > > - Ignore the Reflection changes of the RFC and align the union type with > the current behaviour > > This one, specifically. > I agree with Marco (who I know works on reflection-related projects). To expand a bit: when reading the RFC, "the notable exception that null|false will produce a ReflectionUnionType instead of a ReflectionNamedType contrary to other null|T types" seemed legit because - T|false currently always produces a ReflectionUnionType - null|T producing a ReflectionNamedType (like ?T) was only decided *for backwards-compatibility reasons* [ https://wiki.php.net/rfc/union_types_v2#reflection] (moreover the initial RFC [https://wiki.php.net/rfc/null-standalone-type] only proposed standalone null, not false, so didn't allow ?false) but now looking at the implementation, I don't like the special casing. Regards, -- Guilliam Xavier