Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112202
User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623
Mime-Version: 1.0
Message-ID: <c59d6402-7bf9-4ce6-b494-e92c939e656a@www.fastmail.com>
In-Reply-To: 
 <CAESVnVrpD_E51_REHHAG8nWbhL48SMvuQ+LaDhn0eqO=JpWFkA@mail.gmail.com>
References: 
 <CAM0CcxjEWfbnsbxYV=bp=spqg-1X0MAzBZ-RLG0WQejMvoZUTA@mail.gmail.com>
 <CAJpLVh29eDnJV=bQz97xdpbRsUqJAkrnkArkymC0EFqJpeaMxg@mail.gmail.com>
 <CAESVnVrpD_E51_REHHAG8nWbhL48SMvuQ+LaDhn0eqO=JpWFkA@mail.gmail.com>
Date: Sat, 07 Nov 2020 20:06:05 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Union `&` operator
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Nov 7, 2020, at 2:47 PM, Sara Golemon wrote:
> On Sat, Nov 7, 2020 at 9:33 AM Olle H=C3=A4rstedt <olleharstedt@gmail.=
com> wrote:
>=20
> > 2020-11-07 15:12 GMT, Eugene Sidelnyk <zsidelnik@gmail.com>:
> > > function foo(A & B & E $object) {
> > >   // some work
> > >   var_dump($object);
> > > }
> > >
> >
> > You mean intersections? Psalm supports this notation.
> >
> >
> IIRC we discussed intersection data types when union types were on the=

> table and we settled on a "take it slow" position.  That said, union t=
ypes
> are... **checks notes**... oh, wow.  Actually still pretty new (introd=
uced
> in 8.0).
>=20
> My conservative side wants to wait and see what the community does wit=
h
> unions, but if static analyzers are already providing this functionali=
ty,
> then maybe the community has already made its position known.

I would be very in favor of intersection types.  It's not really useful =
for primitives, but with interfaces it becomes quite handy.

> Questions to answer in any RFC on this topic:
> 1. Do we support complex types combining unions with intersections?
> e.g. function foo(((countable&traversable) | (stringable|jsonserializa=
ble))
> $obj) { ... }
> Pros: Super descriptive
> Cons: Super ugly
> My opinion: Maybe, but not immediately.  Let simple unions/intersectio=
ns
> bake for a version or two.

I'd favor a type being exclusively unions or intersections.  No mixing, =
with the possible exception of allowing the type to be nullable.  So Foo=
 & Bar is OK, Bar | Baz is OK, but Foo & Bar | Baz is just more complex =
than any reasonable person should be doing.

> 2. Do we also bring in type alliasing?
> e.g.
> type CountableTraversable =3D Countable & Traversable;
> type AllTheSerializations =3D Stringable & JSONSerializable;
> function foo(CountableTraversable | AllTheSerializations $obj) { ... }=

> Pros: Can make a given code base more readable once you know the types=

> Cons: Can make figuring out types in a new codebase harder.
> My opinion: Yes.  Sooner the better.

This is a separate RFC from intersection types and should be submitted s=
eparately.  That said, yes please!

> 3. How does this intersect (pun!) with coersion when strict_types=3D0 =
?
> Initial thoughts: Probably very poorly.

I'm unclear how/why it would?  Please explain?

> 4. Should we be considering other bloat^W features?
> a. Exclusive Union:   type SingleSerialization =3D Stringable ^
> JSONSerializable;  // XOR: Must be one, but not both
> b. Blacklist:   type AnythingButDOM =3D !DOMElement;
> My opinion: Hell no.  Just spitballin'.
>=20
> -Sara

Hard pass.  At that point, make separate methods.

--Larry Garfield