GeezerVison

Discussions about the previous RFC:

• Discussion: https://externals.io/message/92274 and https://externals.io/message/93713
• Voting: https://externals.io/message/93953

I really like it. I've encountered many situations where I wanted a method to accept multiple types while retaining type safety. The solution so far was using docblock type hints + static analysis + runtime checks. Union types on a language level would be a much nicer solution!

In addition to the nullable (?Type) and iterable types mentioned in the introduction, isn't callable another union type, since it can be either an array (with certain criteria), a string (with certain criteria) or a Closure?

Appreciate the new RFC medium.

This feature would be great! 😍

@nikic can this feature bring performance issues?

Type aliases is great.

If an RFC is to be on Github and in Markdown anyway, I wonder if it couldn't be made as a pull request to the language specification repo instead. It could be beneficial to that spec for it not to be updated later after RFCs are passed, but instead the spec update could be the RFC. Perhaps this is too radical however :)

I hope it is the right place to ask for something? Its the first RFC I read, thats why please be patient.
Excuse me too, if I misinterpreted the RFC but I dont find any example where I want to use this feature, besides nullability?

IMO many programmers are going to use it like a mixed-typehint with "strict_types = 1". (something like : ":int|float|string|bool") Also IMO PHP was getting typified, harded, easier to read and write since version 7. Thx for that, but this feature could go in another direction.

Maybe a realworld example could help me to understand, which sourcecode is getting easier to maintain or to write with this new feature?

I don't if it was already asked before, but why would you want this over method overloading? If a method accepts both a string and an integer wouldn't you want to have different behaviours in the method?

In which method overloading creates a much clearer code base than a method that both handles a string and an integer.

@robbertstevens Dan has aggregated the current state of why method overloading is probably never going to happen in PHP here: https://github.com/Danack/RfcCodex/blob/master/method_overloading.md

There are some issues I would like to address. Union types are necessary, but I believe that some improvements must be made to this proposal.

Type aliasing

Let's look at the following example.

use Foo\bar;

function test(bar $bar) {
    // is $bar an object? 
}

If the Foo\bar type exists, then $bar is definitely an object. This is how it's been for years. But now, with the introduction of exported types, $bar could be anything. And this incertitude could prove to be a PITA in the long run.

namespace Foo;
type bar = int|float;

// Usable as \Foo\bar from elsewhere

Proposal

Introduce use type. This way we could no longer make wrong assumptions.

use Foo\bar;
use type Foo\baz;
use type int|float|string|bool as scalar; // local type

function test1(baz $baz, scalar $scalar) {
    // Don't make assumptions, check type definition.
}

function test2(bar $bar) {
    // It's an object
}

Nullable types

Nullable types should not be allowed when defining a union type.

use type ?(T1|T2|T3) as foo;
use type bar;

// What's this? Nullable nullable type?
function test(?foo $val) {
}

// Is bar nullable?
function test2(bar $val) {
   // Should I check if $val is null?
   if (is_null($val)) {
   }
}

Proposal

Keep it simple. No nullable types inside unions

use type T1|T2|T3 as foo;

// Not nullable
function test(foo $val) {
    // $val can't be null
}

// Nullable
function test2(?foo $val) {
   // I should check if $val is null
   if (is_null($val)) {
   }
}

Keep the syntax clean

There should be a single way of declaring a union type. The in place way of declaring a union type should be removed.

use type float|int as number;

// Confusing..
function sum(float|int $a, int|float $b): number{
}

// ??
function example(int|float $value, int $flag = 2|4|8|16|32, string|object $item = null): float|int|false {
}

It's hard to read, hard to follow and the syntax is super ugly.

Proposal

Keep the syntax unchanged by forcing the user to either export a union type or declare it locally with the help of use type.

use type float|int as number;

// Makes sense now..
function sum(number $a, number $b): number{
}

This way the ReflectionUnionType is no longer necessary. Only the ReflectionType needs to be changed.

class ReflectionType {
    isUnionType(): bool;
    getUnionTypes(): array;
}

Putting all together..

type scalar=int|float|string|bool; // export union type
use type int|float as number; // local union type

class Foo
{
    private number $foo; // non-nullable property
    private ?number $bar; // nullable property
    
    // non-nullable arguments & return type
    function sum(number $a, number b):number {
    }
   
    // nullable arguments and return type
    function test(?scalar $value): ?scalar {
    }
}

@mattacosta @kocsismate in PHP, there is a concept of "unset object properties", which matches what you want here.

To add to what @Ocramius said, typed properties default to uninitialized, so you can simply use private ?Value $lazyProperty and check whether it's initialized in getLazyProperty().

Unfortunately, there is no easy way to distinguish between an uninitialized and a null property right now (only possible via reflection), so this still falls short in practice. But generally this would be the correct way to go about it, I think.

@nikic Yes, I agree to you, and I already missed an easy-to-use functionality to check uninitialized properties when I wanted to lazy-load other properties which had type declarations. As far as I remember I had to downgrade type declarations to PHPDoc at the end :/ .

Speaking about unset, I use PHPStan strict rules so I didn't even consider using unset properties. But this is probably another topic which falls out of the scope of the discussion about union types. :)

I have always hated that typed properties added an extra "uninitialized" state, which can't be detected, and only exists in certain scenarios. I still think it was a bad design.

If you want more than one terminal value, then some kind of enum or algebraic data type is probably the ideal, and a union with specific values can emulate this a bit, e.g. string|INVALID_ENTRY|FILE_NOT_FOUND. Having both null and false allows you to write string|null|false, but you're still stuck if you want a third terminal value, or if you want a lazy boolean.

I admit that my Value|null|false solution is not elegant at all, but currently this is the easiest viable option (which won't be reported by static analyzers) for such a trivial use-case I have (a builder class for unit testing). Of course, I would welcome a mean to detect uninitialized properties besides reflection or inspecting the var_dump() result :D - it would certainly eliminate the need to use my workaround.

P.S: I believe the uninitialized state is a "necessary evil", otherwise we had trouble declaring non-nullable class types for properties or we ended up in a situation where Java is in now (where classes are implicitly nullable).

The reason I assumed that your code could work with booleans is because if not, then the property could just as easily have been typed as T|null|bool, which would mean that once again, false does not provide anything meaningful.

All of that is irrelevant to my original question of if a restriction would be feasible though. Assuming it is, I ask because the primary argument for false, as specified in the RFC, is to support internal functions. If that argument is sound, then it would seem to be a better solution. If not, then shouldn't the RFC text be updated to include the reasoning behind including this "convenience" in actual code? There's nothing mentioning its potential impact, nor anything backing the special rules involved either.

As a side note: It also kind of sucks that the false-as-a-type discussion is in like five different places throughout this PR, some of which is hidden behind resolved change requests. Maybe the next RFC experiment could use the TC39 model of having each proposal be its own repository with actual issues, and this repo just be a directory of sorts. Of course then the repo would have to be transferred to the PHP organization at some point for preservation... so ugh.

Please make all RFC's available on Github like this from now on!

A classical example is the strpos() family of functions, which returns int|false.

While it would be possible to model this less accurately as int|bool, this gives the false impression that the function can also return a true value, which makes this type information significantly less useful to humans and static analyzers both.

A similar argument could be said in favour of scalar types for, e.g., preg_match that returns 1|0|false.

Proposal+, GH RFC - good practice! Thx @nikic.

Voting has closed with 61 votes in favor and 5 against. As such, the RFC is accepted.

Nice!

Meta: will RFCs be opened to broader discussion via GitHub in the future as well? Also would it make sense to actually merge the accepted RFCs into the repo, instead of just closing the PR?

@rask See https://externals.io/message/107747. The tl;dr for now is: RFCs can be initially submitted against GitHub, but have to move to the PHP wiki before voting.

Sad but true.
Union types satisfies the worst programming practices. It makes interfaces unpredictable, it forces developers to write a lot of if(typecheck) {} ....

Nullable types are fine. I also understand that a lot of builtin function return false if error, so something like falseable is also good. For example ?int - falsable int, ??int - nullable int.

But the most of examples I see here https://gist.github.com/nikic/64ff90c5038522606643eac1259a9dae are just funny. RFC must prohibit such thigs:
Organization|Organization[]|Person|Person[]
\PHPUnit_Framework_MockObject_MockObject|\Payum\Paypal\ExpressCheckout\Nvp\Api
string|integer|array|Zend_Date
"Enum|null|bool|int|float|string|array
Awful!

Maybe some words as "scalar", "numeric" are acceptable, but such a full freedom in types definition is a.. is a... is a bottom|disaster|php-sunset|distrubance|upset|etc

to save space？

It's terrible feature. I can't accept that. I like that one variable has one type.
In a team, some people will make the code worst because of the union types. It a bad standard and hardly trace.