Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113942
Date: Sat, 03 Apr 2021 20:41:09 +0000
To: "G. P. B." <george.banyard@gmail.com>
Cc: Matthew Brown <matthewmatthew@gmail.com>, PHP internals <internals@lists.php.net>
Reply-To: Saif Eddin Gmati <azjezz@protonmail.com>
Message-ID: <LkGd_C00dJLp9757_UVVDjcIS5wIz7vdcoCiJCmiw2n82DERakIuU7w24uD2PMUIMre0Mw3CIdSj88_RzPqf8_PgX1xUezHYfkrp5_HDIg4=@protonmail.com>
In-Reply-To: <CAFPFaMJRFH1+=pqrnM6nDRLXvKU=eZsBhm33a1S6xYmf-bS5mQ@mail.gmail.com>
References: <CAFPFaMLxAaSzeDsT=Mkt2rM5KT21tvbsC02AHg8FZuEeSywZYg@mail.gmail.com> <CAKuGYLRnDNtcMiefABbX7heKe2UGBF8tsWa9UZiPP1PYvHZPOg@mail.gmail.com> <CAFPFaMJRFH1+=pqrnM6nDRLXvKU=eZsBhm33a1S6xYmf-bS5mQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Pure intersection types
From: azjezz@protonmail.com (Saif Eddin Gmati)

Personally, I am against the syntax used in the PR for composite
types( even tho i don't have voting powers ).

I would prefer a syntax similar to Hack, where you have to use parentheses =
to make things more explicit.

considering the following Hack code:


    interface A {}
    interface B {}
    interface C {}
    interface D {}
    interface E {}
    interface F {}

    function bar(
      ((A & F) | (((A & B) | (C & D)) & E)) $_foo
    ): void {}


In PHP, i would assuming i can just remove the parentheses and it would wor=
k as expected:


    <?php

    interface A {}
    interface B {}
    interface C {}
    interface D {}
    interface E {}
    interface F {}

    function bar(
      A&F|A&B|C&D&E $_foo
    ): void {}


However, this now allows `A&B`, which previous was not allowed, so the corr=
ect translation is:


    <?php

    interface A {}
    interface B {}
    interface C {}
    interface D {}
    interface E {}
    interface F {}

    function bar(
      A&F|A&B&E|C&D&E $_foo
    ): void {}


which is way much more confusing, can lead to type errors, and be more repe=
titive (  e.g: `A & ( B | C )` vs `A & B | A & C` - `A` mentioned twice )

ref: https://twitter.com/azjezz/status/1373439678045683721 / https://twitte=
r.com/azjezz/status/1373647148026322946

Regards,

Saif.


=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Saturday, April 3, 2021 1:22 PM, G. P. B. <george.banyard@gmail.com> wro=
te:

> On Tue, 23 Mar 2021 at 19:45, Matthew Brown matthewmatthew@gmail.com
> wrote:
>
> > On Tue, 23 Mar 2021 at 05:32, G. P. B. george.banyard@gmail.com wrote:
> >
> > > I'm calling this proposal pure intersection types as there would be n=
o
> > > possibility of mixing intersection and union types, I'm leaving this =
as a
> > > future scope.
> >
> > Does this miss an opportunity, though? It's useful to be able to write
> > A&B|null.
>
> Obviously this is less powerful than support for composite types where on=
e
> can use both intersections and unions.
>
> I've tried implementing composite types without grouping here:
> https://github.com/Girgias/php-src/pull/8
> But I'm hitting various issues and I'm far from confident that I'll be ab=
le
> to resolve them and add the variance check code before June so that this
> can reasonably get voted in for PHP 8.1.
>
> The end goal is support for composite types but I prefer to land a
> reasonably self contained feature in 8.1 then nothing at all.
> Internals might disagree with this and refuse the feature unless "complet=
e"
> but if that's the case there is still time to "finish" it for another RFC=
.
>
> If someone else wants to work on adding support for composite types they
> are free to work based on my PR, or collaborate with me.
>
> I've also tidied up the RFC: https://github.com/Girgias/intersection-type=
s
>
> Unless someone shows up to work on composite types, I'll probably bring
> this to a vote next week (if I don't forget about it).
>
> Best regards,
>
> George P. Banyard