Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106847
MIME-Version: 1.0
References: <CAF+90c8EvfFPqjRJjJ3T-qTfLiWn7aZzCrGpk7R3yNFLT1qWjQ@mail.gmail.com>
In-Reply-To: <CAF+90c8EvfFPqjRJjJ3T-qTfLiWn7aZzCrGpk7R3yNFLT1qWjQ@mail.gmail.com>
Date: Wed, 4 Sep 2019 11:58:53 +0200
Message-ID: <CAOWwgpnX0W4vJ2MFC7SvvuSe3Ac4b7FXcozLeYRfdd39MHwzuA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000059d08e0591b741d4"
Subject: Re: [PHP-DEV] [RFC] Union Types v2
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000059d08e0591b741d4
Content-Type: text/plain; charset="UTF-8"

>
> 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

--00000000000059d08e0591b741d4--