[RFC] Union types

[bwoebi]

This is the patch for union and intersection types, see https://wiki.php.net/rfc/union_types

It currently allows | null in an union, which is very simple to remove again from compiler, in case we decide to vote first on the RFC without support for null.

[NinoSkopac]

do it

[ghost]

I don't know what core developers think!
This feature is very important for php. (Maybe you want us to go the hack lang!)
They accept ugly ?QuestionMark null able type with overwhelming majority but in this...!!! :|

[NinoSkopac]

@sharifzadesina you tell 'em m8

[ghost]

I followed the internal discussion but I did not understand the main reason for voting overwhelmingly in favor of no, this feature seems nevertheless important following the latest changes caused by type hints. Someone to enlighten me ?

[Izopi4a]

man that's so much work :( . Hopefully later on devs will decide to implement it.

[nikic]

Closing as the RFC has been declined (for now!)

[codedokode]

@lilty I do not like this proposal and I think it will bring just more confusion.

When you have a type hint declaration you can understand what can you do with a value. For example if you have an array $a you can use count($a) or take a value by index. When you have callable argument, you can call it as a function.

But what if you have int|array $a or int|SomeClass $s. What can you do with it?

Accepting or returning values of multiple types is generally a bad idea that makes code more complicated and prone to errors.

Regarding standart PHP functions like strpos() that can return either int or bool they are just poorly designed. false can be easily converted to 0. There is no need to implement type hints for such functions. In other languages like Javascript usually -1 is used instead of false.

[steve-todorov]

I would vote "no" as well because of the purposed syntax. There are a lot of problems:

1. What happens if you have more than 2 possible argument types? (i.e. you're building an adapter class which can receive data from different places)
2. How would you debug it if it's all in one method?
3. What happens when you need to handle all the "corner cases" which occur only when the argument type is of specific code? You will have to "polute" your method with all that "extra" code which has nothing to do with the main action.

IMHO the cleaner implementation would be the way it's done in Java - method-overloading. You will be able to have a method with the same name multiple times, but each method has to accept different arguments types. This will make the code cleaner and easier to work with and debug. If the purposed syntax was implemented the way it is - it would have made a lot of people's life a living hell.

@codedokode that's why you should have the ability to do method overloading - use the same method name and implement the code to handle the different cases. It's easier to debug and you end up having cleaner code. Furthermore, your IDE would know exactly which method you're trying to call by looking at the types of arguments you're passing and will show you "hints". This has already been done - we don't need to re-invent the wheel. :)

[codedokode]

@steve-todorov

Overloading has problems of its own too. For example in PHP some types can be automatically converted (e.g. number to string when concatenating). Also PHP is not completely statically typed so it will not always be clear what version of method would be called.

[kirtangajjar]

@nikic Can you point the link to where the discussion happened which decided to decline this proposal?

[carusogabriel]

@kirtangajjar
Discussion: https://externals.io/message/92274
Voting: https://externals.io/message/93953

[travisfont]

This RFC needs to be revisited for PHP 8.
There are huge advantages for having this.

[olleharstedt]

Ping for this. Intersection types are useful for middleware containers, where the container's content can be described as an intersection of different interfaces, e.g. RequestContainer&UserContainer will have both getUser() and getRequest().

Also described here: https://phpixie.com/blog/taking-middleware-psr-7-and-mvc-to-the-next-level.html