Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115563
MIME-Version: 1.0
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <alpine.DEB.2.23.453.2107231324200.2773@singlemalt.home.derickrethans.nl> <CADK1yXLBwEi3Op_3Wad0RCs8v0Spw2cC2XYuaqtxBfMeiXZw7g@mail.gmail.com>
In-Reply-To: <CADK1yXLBwEi3Op_3Wad0RCs8v0Spw2cC2XYuaqtxBfMeiXZw7g@mail.gmail.com>
Date: Fri, 23 Jul 2021 16:48:40 +0200
Message-ID: <CAEPJdunEPA6=LrdRC2gyeDrbAbn3OU7AjcZpF-w-TSc6hD5ChQ@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: Derick Rethans <derick@php.net>, Nicolas Grekas <nicolas.grekas@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000085000505c7cb80c8"
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: kontakt@beberlei.de (Benjamin Eberlei)

--00000000000085000505c7cb80c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 23, 2021 at 4:31 PM Deleu <deleugyn@gmail.com> wrote:

> On Fri, Jul 23, 2021 at 2:36 PM Derick Rethans <derick@php.net> wrote:
>
> > From the RFC: =C2=ABTaking all these elements into account, the prefere=
nce
> > of... and thus to use the "?X&Y" syntax=C2=BB.
> >
> > I think this would be a mistake. You touch upon operator precedence, an=
d
> > needing to know whether | or & is higher, and inventing a new precedenc=
e
> > for ?.
> >
> > I would strongly advocate for not getting into the realm with any
> > operator precendence, but instead *require* parenthesis for any
> > combination. This gives the code reader and writer an immediate clue
> > about what the code does. Most coding standards also recommend this for
> > expressions in "if" statements and the like.
> >
> > I do however agree with Sara's =C2=ABover-delivering syntax that hasn't=
 been
> > entirely thought through=C2=BB point. It will take a lot longer to come=
 up
> > with a proposal to combine intersection and union types.
> >
> > That in combination that you're proposing this RFC after feature freeze=
,
> > while you've had four months to make this arguments as part of the "Pur=
e
> > Intersection Types" RFC, I am currently not going to support this RFC
> > for inclusion into PHP 8.1.
> >
> > cheers,
> > Derick
> >
> > --
> > PHP 7.4 Release Manager
> > Host of PHP Internals News: https://phpinternals.news
> > Like Xdebug? Consider supporting me: https://xdebug.org/support
> > https://derickrethans.nl | https://xdebug.org | https://dram.io
> > twitter: @derickr and @xdebug
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
>
>
> These are precisely everything I think about this RFC. The only thing the
> RFC made clear is why it is easy to make an exception for null while stil=
l
> not providing a full mix of union and intersection.
>
> Maybe my memory is also really bad, but the RFC makes it seem like versio=
n
> 7.0 was a mistake to be learned from which isn't clear for me. I understa=
nd
> that introducing nullable intersection later will warrant a major version
> and I don't see a problem with that. Pure Intersection RFC was such a
> breeze vote precisely because it didn't involve the complexity of mixing
> with union. Part of that complexity is now being rushed after feature
> freeze.
>

As a maintainer of a large open source library, yes 7.0 was a problem due
to the nullability missing for return types and was the reason why a lot of
open source libraries jumped from minimum 5.4/5.5/5.6 directly to 7.1 to
avoid breaking BC twice for classes/interfaces when a signature of the
following kind was present:

/**
* @param string $foo
 * @return ?string
 */
function foo () { }

php 7.0: foo(string $foo) {}
php 7.1: foo(string $foo) : ?string {}


> --
> Marco Aur=C3=A9lio Deleu
>

--00000000000085000505c7cb80c8--