Re: [RFC] Union Types v2

- Agree on the usefulness of a stringable meta-type. - Hack supports an explicit “: this” return type (without dollar) when returning “new static(...)”. I think I might prefer that to “: static”. - From a type perspective, I don’t understand the “int|void” idea - it might make your users’ life easier, but doesn’t accord with how PHP works (which treats void as null to consumers). - if we’re adding to some future wish list, would love to have support for “: noreturn” when a function always throws or exits On Sep 4, 2019, at 5:58 AM, Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote: >> >> >> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md > > > Thank you Nikita, this would be a hugely welcomed step forward! Can't wait > to get rid of all those docblock annotations! > > I've some additional suggestions that would greatly help remove more > docblocks and provide engine-enforced type-safety, maybe for the "future > scope" section. We use the all in Symfony: > > - we miss a stringable union type, for string|__toString. > This is > required when an API need lazyness regarding the generation of some > strings. Right now, we have no other option but using string|object. > - we use "@return $this" quite often. On the implementation side, I'd > suggest enforcing this at compile time only (enforce all return points are > explicit, and written as "return $this", similarly to what is done for > nullable/void return types.) This makes sense only for return types. > - we use "@return static" quite often too, typically when a method > returns a clone of the current instance. If anyone wonders, this is not the > same as "@return self" of methods overridden in child classes. This makes > sense only for return types. > > About union types with void in them, we do use one in Symfony: > Command::execute() has "@return int|void". The reason is that if we were to > use "?int" instead, the engine would force the community to add "return > null;" where no return statement is needed at all most of the time. Right > now, we consider that the transition cost for the community is not worth > the extra boilerplate this requires. Note that there would be only one > friendly path forward: trigger a deprecation when null is returned, asking > ppl to add "return 0;". Not sure how this should impact the proposal, but > I thought it could be worth sharing. > > Thanks again, > Nicolas