Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93722
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
To: internals@lists.php.net
References: <BLU437-SMTP785CB095BE08FBC1CC2FAFE2580@phx.gbl>
 <0A.C5.62101.1C860575@pb1.pair.com>
Message-ID: <a58caf44-dae1-c544-804f-089360243607@gmail.com>
Date: Thu, 2 Jun 2016 18:33:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <0A.C5.62101.1C860575@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
From: rowan.collins@gmail.com (Rowan Collins)

On 02/06/2016 18:11, Andrea Faulds wrote:
> That aside, the behaviour the RFC now specifies for how weak typing
> interacts with union types is frighteningly complicated. I don't see how
> it could be anything other than that, but the new complexity this
> introduces to PHP is enough for me to vote against this RFC, even
> ignoring my other concerns.

That is rather a long-winded set of rules, I agree. I wonder if it's 
possible for the order the union type is defined to be taken into 
account? That way you could specify the rule thus:

* The type is tested against each type in the union in turn.
* If weak typing is active, scalar types will be coerced where this 
would normally be allowed, and passed over where a TypeError would be 
thrown.
* If strict typing is active, scalar types will be treated the same as 
non-scalar types, and must match precisely.


So:

function f(int | float $number) { echo gettype($number); }
f('10'); // int

function g(float | int $number) { echo gettype($number); }
g('10'); // float

function h(int | Foo | string) { echo gettype($number); }
h('10'); // int
h(new Foo); // object
h('hello'); // string

function i(string | int) { echo gettype($number); }
i('10'); // string
i(10); // string

This last example is the only one that might be a bit surprising - the 
"| int" in the type def is actually doing nothing - but there's always 
scope for user error.


In strict mode, things would be a bit different, because no coercion is 
allowed:

declare(strict_types=1);

function f(int | float $number) { echo gettype($number); }
f('10'); // [!] TypeError

function g(float | int $number) { echo gettype($number); }
g('10'); // [!] TypeError

function h(int | Foo | string) { echo gettype($number); }
h('10'); // string
h(new Foo); // object
h('hello'); // string

function i(string | int) { echo gettype($number); }
i('10'); // string
i(10); // int


It may be that the implementation makes this prohibitively difficult, 
but it would certainly be easier to document than the rules currently 
proposed.

Regards,
-- 
Rowan Collins
[IMSoP]