[RFC] Union Types v2 - Externals

[deleted]

It went nowhere. There was a decent amount of support for it, but several key contributors didn't see "the value" and hence I pulled it.

It comes up every now and then, and a few major frameworks have asked for it. I think it will just take someone picking it up again and running with it to get it in...

That makes a lot of sense! Thanks for coming up with the shortest explanation while still getting the point across :)

I definitely like the sound of this! I can think of multiple places I could use this functionality!

Pardon my ignorance, but what other languages has this kind of feature? I've never really come across it in my few professional years.

Also, wouldn't this be the same as implementing your own interface that extends the 2-or-more interfaces you're requesting? I'm aware that this means extra code = extra maintenance, but depending on the use case having comprised interfaces might improve readability. E.g.:

interface CountableAndArrayAccess extends \Countable, \ArrayAccess
{
    [...]
}

I'm aware my above suggestion is a step away from the generics concept, and the amount of comprised interfaces might scale exponentially. Consider it me playing the devil's advocate. But as soon as you specify more than 2 interfaces, the function signature might start to look cluttered in extreme cases. Compare:

function foo((Countable&ArrayAccess&ThirdClass&FourthClass)|array $arrayLike) {
    for ($i = 0; $i < count($arrayLike); $i++) {
        echo $arrayLike[$i];
    }
}

... To:

interface Comprised extends \Countable, \ArrayAccess, ThirdClass, FourthClass
{
    [...]
}

function foo(Comprised|array $arrayLike) {
    for ($i = 0; $i < count($arrayLike); $i++) {
        echo $arrayLike[$i];
    }
}

Thanks for the explanation.

Your example kinda showcases the complexity in this though, as without any parentheses, it can be hard to determine the actual intention. E.g., does A | B & C mean either:

• Must implement A or both B and C
• Must implement A and C or B and C

I'm thinking order of operations (for lack of better word). As long as there's a common definition, there' no problem of course, other than people not reading the docs.

If you are creating a library/component you don't really want to create your own simple types (making a library more difficult to use and difficult to integrate into other components), and union types is probably a bigger feature for reusable libraries than for actual application code, because making something reusable can mean allowing multiple types or multiple interfaces, or something like array|ArrayIterator, or string|callable, etc.

In my application code I also don't need to union types in 95% of cases, but for components or even just for helper functions etc. this can be huge, and it can also be a first step towards refactoring in "old" code. Having a union type starts to restrict the types, so you can maybe reduce it to one type later, or to one interface or class.

Because the method does indeed accept such type.

A simplistic example based on a possible state machine:

interface GamePhase {
    // ...
}

class DrawCard implements GamePhase {}
class Untap implements GamePhase {}
class Attack implements GamePhase {}
class DiscardCard implements GamePhase {}
class End implements GamePhase {}

class Game {
    public function drawCard() : Attack|DiscardCard|End { /* ... */ }
}

Static typing =/= one type at a time.

Interfaces already allow you to do more-or-less the same thing (albeit with more ceremony and less flexibility). Union types are a very useful way to existing dynamically-typed APIs. And aside from that, they also allow you to more safely specify APIs that do accept different types, which plenty of people like to design.