# [RFC] Intersection Types

- Thread: https://externals.io/message/92857
- Original archive: https://news-web.php.net/php.internals/92857
- Started by Levi Morrison on 2016-04-28T03:54:33+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #92857 — Levi Morrison — 2016-04-28T03:54:33+00:00

URL: https://externals.io/message/92857#92857

Internals,

As alluded to last week I have another RFC for improving the type
system: [intersection types][1].

It allows parameters to define multiple type constraints that must be
satisfied. Common combinations of our built-in types include
`ArrayAccess & Traversable & Countable` and `Countable & Iterator`.

Some people have suggest I merge this and union types into one RFC.
For now I'll just proceed with them separately to gain feedback.

  [1]: http://wiki.php.net/rfc/intersection_types

---

## #92863 — Josh Di Fabio — 2016-04-28T09:00:01+00:00

URL: https://externals.io/message/92857#92863 · In reply to: #92857

> Internals,
>
> As alluded to last week I have another RFC for improving the type
> system: [intersection types][1].
>
> It allows parameters to define multiple type constraints that must be
> satisfied. Common combinations of our built-in types include
> `ArrayAccess & Traversable & Countable` and `Countable & Iterator`.
>
> Some people have suggest I merge this and union types into one RFC.
> For now I'll just proceed with them separately to gain feedback.
>
>   [1]: http://wiki.php.net/rfc/intersection_types
>
> --
> 
> 
>

To me, it seems that intersection types are more useful than union
types (other than the obvious null|Foo and array|Traversable cases) as
they'd allow us to write smaller interfaces and better follow ISP in
userland, with interfaces becoming much more convenient for
documenting the requirements of a parameter.

At present we tend to have incomplete implementations of interfaces
(e.g. throw OperationNotSupportedException). Union types would allow
us to create more, smaller interfaces and avoid situations where the
type of a parameter doesn't accurately reflect the method's true
requirements, or where concretions are incomplete implementations of
an interface.

Thanks for your efforts, Levi, I'm excited about this one!

---

## #92867 — guilhermeblanco@gmail.com — 2016-04-28T15:11:24+00:00

URL: https://externals.io/message/92857#92867 · In reply to: #92863

Nice!

I've read the RFC and there's only one missing thing that is either
undocumented or missed during patch creation: instanceof.
I'd be amazing if we could do: $foo instanceof Foo & Bar

Cheers,

On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio <joshdifabio@gmail.com>
wrote:

> 
> > […]
>
> To me, it seems that intersection types are more useful than union
> types (other than the obvious null|Foo and array|Traversable cases) as
> they'd allow us to write smaller interfaces and better follow ISP in
> userland, with interfaces becoming much more convenient for
> documenting the requirements of a parameter.
>
> At present we tend to have incomplete implementations of interfaces
> (e.g. throw OperationNotSupportedException). Union types would allow
> us to create more, smaller interfaces and avoid situations where the
> type of a parameter doesn't accurately reflect the method's true
> requirements, or where concretions are incomplete implementations of
> an interface.
>
> Thanks for your efforts, Levi, I'm excited about this one!
>
> --
> 
> 
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

---

## #92869 — Bob Weinand — 2016-04-28T15:49:44+00:00

URL: https://externals.io/message/92857#92869 · In reply to: #92867

> Am 28.4.2016 um 17:11 schrieb guilhermeblanco@gmail.com:
> 
> Nice!
> 
> I've read the RFC and there's only one missing thing that is either
> undocumented or missed during patch creation: instanceof.
> I'd be amazing if we could do: $foo instanceof Foo & Bar
> 
> Cheers,
> 
> On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio <joshdifabio@gmail.com>
> wrote:
> 
> > […]
> 
> -- 
> Guilherme Blanco
> Lead Architect at E-Block

Who’s top-posting here? ;-)

Regarding your suggestion, $foo instanceof Foo & Bar is conflicting with bitwise and here. Anyway, you already can $foo instanceof Foo && $foo instanceof Bar. Which is IMO just as easy, not conflicting and more flexible.
Also, instanceof would not (at least not currently) work with scalar types, array or callable. (i.e. $foo instanceof string doesn’t work). And thus $foo instanceof Foo & callable doesn’t either. Which is quite a difference to intersection/union types.

Bob

---

## #92870 — Rowan Collins — 2016-04-28T16:06:01+00:00

URL: https://externals.io/message/92857#92870 · In reply to: #92869

Bob Weinand wrote on 28/04/2016 16:49:
> Regarding your suggestion, $foo instanceof Foo & Bar is conflicting with bitwise and here. Anyway, you already can $foo instanceof Foo && $foo instanceof Bar. Which is IMO just as easy, not conflicting and more flexible.


It's a shame that that's so verbose. It would be amazing to have 
something like Perl6's "Junctions": 
https://perlgeek.de/blog-en.cgi/perl-5-to-6/08-junctions.html

$foo instanceof any(Foo, Bar)

Well, I can dream... ;)