Re: Re: [RFC] Union Types v2

Den 2019-09-18 kl. 15:33, skrev Nikita Popov:

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

Hi internals, I'd like to start the discussion on union types again, with a new proposal: Pull Request: https://github.com/php/php-rfcs/pull/1 Rendered Proposal: https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md As an experiment, I'm submitting this RFC as a GitHub pull request, to evaluate whether this might be a better medium for RFC proposals in the future. It would be great if we could keep the discussion to the GitHub pull request for the purpose of this experiment (keep in mind that you can also create comments on specific lines in the proposal, not just the overall discussion thread!) Of course, you can also reply to this mail instead. The final vote will be held in the wiki as usual. Relatively to the previous proposal by Bob&Levi ( https://wiki.php.net/rfc/union_types), I think the main differences in this proposal are: * Updated to specify interaction with new language features, like full variance and property types. * Updated for the use of the ?Type syntax rather than the Type|null syntax. * Only supports "false" as a pseudo-type, not "true". * Slightly simplified semantics for the coercive typing mode. Regards, Nikita

Heads up, two weeks have passed, so this may now go to voting... I believe relative to my original draft the main change that has happened as a result of the discussion is the use of T1|T2|null syntax instead of ?(T1|T2) syntax for nullable types. ?T becomes an alias for T|null. People felt fairly strongly that while ?T is a nice shorthand for a common case, unions should use the T1|T2|null syntax that both reads better and is already well-established from phpdoc. I figured I should mentioned this for people who haven't been following the GitHub thread... Nikita

Hi Nikita, Planned to comment on ? vs null on Github, but here it goes. Advantage with ? syntax was in my eyes that it's clear it's not a stand-alone type or what I should call it, but rather a "change/variant" to an existing type. Having it stated as T1|T2|null lead it a bit in the direction of being a more stand-alone type. Anyway, I'm quite happy with the proposal as it is. So thanks for the excellent work! r//Björn L