Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113719
MIME-Version: 1.0
References: <CAFPFaMLxAaSzeDsT=Mkt2rM5KT21tvbsC02AHg8FZuEeSywZYg@mail.gmail.com>
 <88f72c8f-3f4c-42d6-96aa-b8e9c9475a94@www.fastmail.com>
In-Reply-To: <88f72c8f-3f4c-42d6-96aa-b8e9c9475a94@www.fastmail.com>
Date: Tue, 23 Mar 2021 14:24:03 +0000
Message-ID: <CAFPFaM+Q2DZ94TP4R49XzJQmMTfuzBLEVDxtA7bhYNgFfD7XcQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c6198f05be34ef82"
Subject: Re: [PHP-DEV] [RFC] Pure intersection types
From: george.banyard@gmail.com ("G. P. B.")

--000000000000c6198f05be34ef82
Content-Type: text/plain; charset="UTF-8"

On Tue, 23 Mar 2021 at 13:14, Larry Garfield <larry@garfieldtech.com> wrote:

> On Tue, Mar 23, 2021, at 4:32 AM, G. P. B. wrote:
> > Greetings internals,
> >
> > I'm presenting a new RFC to add support for pure intersection types to
> PHP.
> >
> > An intersection type A&B means that the value must be of type A and of
> type
> > B at the same time.
> >
> > I'm calling this proposal pure intersection types as there would be no
> > possibility of mixing intersection and union types, I'm leaving this as a
> > future scope.
> >
> > The current draft is located on GitHub:
> > https://github.com/Girgias/intersection-types
> > And the current implementation PR is:
> > https://github.com/php/php-src/pull/6799
> >
> > Looking forward to the feedback.
> >
> > Best regards,
> >
> > George P. Banyard
>
>
> I love this!  Thanks, George!
>
> A few editorial notes:
>
> * Under "Duplicate and redundant types", the prose says "For example, if
> ''A'' and ''B'' are class aliases, then ''A&B'' remains a legal
> intersection type".  The code sample after it, however, says it's an
> error.  Please clarify.
>

Clarified to "runtime class aliases".


> * Under "Adding and removing intersection types", there appears to be some
> broken code formatting.
>

Indeed should be fixed now.

* The Reflection section still refers to "union" types.  I assume that's
> because that section is still a WIP.
>

Correct, I completely forgot about the Reflection aspect up until I started
writing the RFC by copying the union type one.
I've removed mentions of union and hopefully have something which makes a
bit more sense.


> * Under "Future Scope / Type Aliases", you refer to "number" as being an
> alias, but the code sample calls it "CountableIterator".
>

Indeed fixed.


> Design notes:
>
> * Should we be planning ahead for some future where union and intersection
> types can be mixed and design the reflection API accordingly?  I worry that
> if we have a ReflectionIntersectionType, and a ReflectionUnionType, that
> ReflectionIntersectionAndUnionType is just going to make both implementers
> and users table-flip.
>
> --Larry Garfield
>

Having looked at the current Reflection API for types I'm not sure
something like this is necessary as pointed out by someniatko, it would
provide a tree like structure by the nature of the current design.
However, it might be of interest to know if other things should be added to
this.

Best regards,

George P. Banyard

--000000000000c6198f05be34ef82--