Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115539
MIME-Version: 1.0
References: <CAOWwgpm+PPhW6A5=Oi1tpdkQh9COGw5dQLE+Ek1p0BZ6T-xQsA@mail.gmail.com>
 <CAC5V6ggeLQYygZq13-Ux0VoSDiMUhAPR3Wr9AoT_oDoqu9yxgw@mail.gmail.com>
 <CAOWwgp=UhvGD2CjspXVSmDMHL6uf12sb_yS2JDUoEgON5boNbA@mail.gmail.com>
 <CA+kxMuR0B3_J1EdEpDDSq3JeNuL_Jv_tUZZywATY32itzegEdg@mail.gmail.com>
 <CAC5V6ggSNzvzQYbn+Wi4TT0+pqWx4n3Z2vY+pXnnD6Hzi7ma9w@mail.gmail.com>
 <CAFPFaMKGRq79G6pK8G34bgij4dqiwN_Ja8kn07RabjL+8wuSNA@mail.gmail.com>
 <CAF+90c-dnOm2vj2YSFqqC-e_w5rny09D+emE3paHRidrZ=Y7Jw@mail.gmail.com> <CAOwTYAv-pWDMmUD7OK3cc0zvD7a=5Z9SkiteSxU89MUm1kqShA@mail.gmail.com>
In-Reply-To: <CAOwTYAv-pWDMmUD7OK3cc0zvD7a=5Z9SkiteSxU89MUm1kqShA@mail.gmail.com>
Date: Wed, 21 Jul 2021 09:05:06 +0200
Message-ID: <CAOWwgpnN-+VFqvMQ3QJ=1accyDnzf22vsxdtGb9OLQ8ogs8W+A@mail.gmail.com>
To: Joe Watkins <krakjoe@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001d50a805c79ccb87"
Subject: Re: [PHP-DEV] intersection types and null for defaults, properties
 and return types
From: nicolas.grekas@gmail.com (Nicolas Grekas)

--0000000000001d50a805c79ccb87
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 20 juil. 2021 =C3=A0 14:41, Joe Watkins <krakjoe@gmail.com> a =C3=
=A9crit :

> Agree, an RFC looks like the only way.
>
> This is not worth delaying a release for, nor is it worth postponing the
> feature freeze date.
>
> It seems reasonable to fix this after freeze, would prefer to reach
> consensus before RC stage.
>
> Cheers
> Joe
>
> On Tue, 20 Jul 2021 at 13:07, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Mon, Jul 19, 2021 at 8:16 PM G. P. B. <george.banyard@gmail.com>
>> wrote:
>>
>> > On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier <
>> guilliam.xavier@gmail.com>
>> > wrote:
>> >
>> > > On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas <
>> nicolas.grekas@gmail.com
>> > >
>> > > wrote:
>> > >
>> > > >
>> > > > https://github.com/php/php-src/pull/7259
>> > > >
>> > >
>> > > Great! Thanks! Interesting how it works out-of-the-box with just thi=
s
>> > > addition in Zend/zend_language_parser.y:
>> > >
>> > > ```diff
>> > >  type_expr:
>> > >   type { $$ =3D $1; }
>> > >   | '?' type { $$ =3D $2; $$->attr |=3D ZEND_TYPE_NULLABLE; }
>> > >   | union_type { $$ =3D $1; }
>> > >   | intersection_type { $$ =3D $1; }
>> > > + | '?' intersection_type { $$ =3D $2; $$->attr |=3D ZEND_TYPE_NULLA=
BLE; }
>> > >  ;
>> > > ```
>> > >
>> > > On Mon, Jul 19, 2021 at 5:09 PM Dan Ackroyd <Danack@basereality.com>
>> > > wrote:
>> > >
>> > > > nicolas-grekas wrote on the PR:
>> > > > > ?X&Y cannot be confused with
>> > > >
>> > > > It confused me. A compiler might understand it, but as a human I
>> have
>> > > > trouble understanding it.
>> > > >
>> > > > Trowski wrote:
>> > > > > The syntax should be either ?(X&Y) or (X&Y)|null
>> > > >
>> > > > Non-ambiguous syntax is much better than ambiguous syntax.
>> > > >
>> > >
>> > > Maybe it's just a matter of habit?
>> > > For instance I got used to seeing things like `!$x =3D f()` (e.g. `i=
f
>> (!$x
>> > =3D
>> > > f()) { throw /*...*/; } /* use $x */`) because some CS consider
>> explicit
>> > > parentheses in `!($x =3D f())` redundant (as PHP has a special case =
that
>> > > "overrides" the normal precedence `(!$x) =3D f()` which would be an
>> error).
>> > > If you first consider `X&Y` as a type "unit", then it makes sense to
>> make
>> > > it "nullable" by prefixing it with `?`, I think?
>> > >
>> > >
>> > > >
>> > > > But this discussion is moot for 8.1.
>> > > >
>> > > > This limitation might make intersection types not be considered
>> usable
>> > > > by some projects, but the feature freeze is today.
>> > > >
>> > >
>> > > Which can also be reversed: "The feature freeze is today, but this
>> > > limitation might make intersection types not be considered usable by
>> some
>> > > projects"? (playing devil's advocate, I don't master the process)
>> > >
>> > > Regards,
>> > >
>> > > --
>> > > Guilliam Xavier
>> > >
>> >
>> > Since when is usability for a specific project a consideration an RFC
>> needs
>> > to have?
>> > If Symfony can't use it in its current state tough luck,
>> > I'm sure plenty of other projects can, especially now that using 'new
>> > Class' is possible as a default object value.
>> >
>> > I frankly don't care about being able to have some sort of partial uni=
on
>> > possible with the usage of intersection types,
>> > because it seems the machinery in the engine which makes null work,
>> should
>> > also allow any standard PHP types as those are part of a bitflag and
>> > handling variance with them seems to work just fine...
>> >
>> > But for the love of god, this proposed syntax is horrendous, saying
>> ?X&Y is
>> > unambiguous is disingenuous.
>> > It can either mean (?X)&Y =3D (X|null)&Y or ?(X&Y) =3D (X&Y)|null, the
>> former
>> > one being bogus as null&Y is an impossible type, something which shoul=
d
>> > error out to point out a potential bug in the same way we do for
>> redundant
>> > types that we know at compile time.
>> > And if we allow this syntax then we really should be allowing ?A|B
>> which is
>> > dumb.
>> > (and no ?X&Y is NOT something I consider forward compatible when it is
>> just
>> > going to become one more edge case we need to maintain because people
>> have
>> > no patience).
>> >
>> > If ?(X&Y) is allowed then ?(A|B) should also be allowed, and that need=
s
>> an
>> > RFC for sure due to the controversy it had in the union type RFC.
>> >
>> > The only remaining sensible choice is (X&Y)|null / null|(X&Y), but as =
I
>> > said above if the machinery for null is there it must mean the machine=
ry
>> > for int/string/array/float/bool is also there, and frankly being able
>> to do
>> > something like (Traversable&Countable)|array is also extremely valuabl=
e,
>> > maybe even more than nullability, but in any case this is going to be
>> > confusing for end-users why only null (or standard PHP types) can be
>> > combined in a union with intersection types.
>> >
>> > That's one reason why it's only pure intersection types, if I had more
>> time
>> > (or for crying out loud somebody would have paid me) to work on this I
>> > would have loved to get full composite types working.
>> >
>> > And I find it frankly insulting that in the four month this RFC has be=
en
>> > published for discussion, with multiple push backs for voting due to
>> bugs
>> > and me wanting that people know what implementation is - for the most
>> part
>> > - going to land in php-src, this specific point has not been raised.
>> > It just feels like you are pissing on 6+ months of *unpaid* work I did
>> > because it doesn't suit your needs, and you just realised that and so
>> > decided to throw a wrench into a carefully crafted RFC to "fix" it by
>> using
>> > a Twitter mob to put pressure on us/me.
>> >
>> > Maybe this topic didn't come up because for nearly everyone else "Pure
>> > Intersection Types" means what it says on the can, moreso that in the
>> RFC
>> > the following line:
>> > > This means it would *not* be possible to mix intersection and union
>> types
>> > together such as A&B|C, this is left as a future scope
>> > makes it clear, and most voters also understood that '?' is not a type
>> > "flag" but is syntactic sugar for 'null|'.
>> >
>> > There are plenty of issues with the implementation, from the whack
>> parser
>> > hack, the non support for static/parent/self, to the complexity of the
>> > variance code, but I made all of those clear because they made *me*
>> > uncomfortable with the implementation.
>> > So if you are going to force this crappy syntax, then I'd rather axe
>> this
>> > feature completely (and nobody can use/play with it) then have
>> something I
>> > do not accept, nor are forced to accept because of a vote, land in cor=
e
>> > making PHP even more of an inconsistent joke.
>> >
>>
>> Hey George,
>>
>> I don't think there's been any malicious intent here -- it was obvious t=
o
>> you and I that not allowing unions implies not allowing nullability, but=
 I
>> can see how people less familiar with our type system implementation wou=
ld
>> not make that connection. After all, we do provide the separate ?T synta=
x,
>> even if it is an internal alias for T|null.
>>
>> It's an unfortunate fact of the RFC process that concerns are sometimes
>> only raised when voting starts and people start looking at the
>> implementation -- or in this case, when they test the implementation aft=
er
>> it has landed...
>>
>> In any case, I think it's pretty clear by now that there are some fairly
>> strong opinions both on what the syntax for this should be (between ?X&Y=
,
>> ?(X&Y), (X&Y)|null and X&Y|null, all of which have reasonable arguments
>> for
>> and against) and whether we should have this special case at all. I'm no=
t
>> sure we will be able to reach a sufficient consensus in this discussion.
>>
>> For that reason, I think this change should go through the RFC process. =
We
>> can grant this an exemption from the feature freeze (as a clarification =
of
>> an accepted proposal), but it should still go through the process.
>>
>

Thanks Nikita, Joe and the others for opening the possibility of a late
RFC. I'm going to write one down asap!

Nicolas

--0000000000001d50a805c79ccb87--