Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93725
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.80 as permitted sender)
Message-ID: <BLU436-SMTP187447B1819635CD2E6962E2580@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <a58caf44-dae1-c544-804f-089360243607@gmail.com>
Date: Thu, 2 Jun 2016 19:43:07 +0200
CC: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
References: <BLU437-SMTP785CB095BE08FBC1CC2FAFE2580@phx.gbl> <0A.C5.62101.1C860575@pb1.pair.com> <a58caf44-dae1-c544-804f-089360243607@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
From: bobwei9@hotmail.com (Bob Weinand)


> Am 02.06.2016 um 19:33 schrieb Rowan Collins =
<rowan.collins@gmail.com>:
>=20
> 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.
>=20
> 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:
>=20
> * 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.
>=20
>=20
> So:
>=20
> function f(int | float $number) { echo gettype($number); }
> f('10'); // int
>=20
> function g(float | int $number) { echo gettype($number); }
> g('10'); // float
>=20
> function h(int | Foo | string) { echo gettype($number); }
> h('10'); // int
> h(new Foo); // object
> h('hello'); // string
>=20
> function i(string | int) { echo gettype($number); }
> i('10'); // string
> i(10); // string
>=20
> 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.
>=20
>=20
> In strict mode, things would be a bit different, because no coercion =
is allowed:
>=20
> declare(strict_types=3D1);
>=20
> function f(int | float $number) { echo gettype($number); }
> f('10'); // [!] TypeError
>=20
> function g(float | int $number) { echo gettype($number); }
> g('10'); // [!] TypeError
>=20
> function h(int | Foo | string) { echo gettype($number); }
> h('10'); // string
> h(new Foo); // object
> h('hello'); // string
>=20
> function i(string | int) { echo gettype($number); }
> i('10'); // string
> i(10); // int
>=20
>=20
> It may be that the implementation makes this prohibitively difficult, =
but it would certainly be easier to document than the rules currently =
proposed.
>=20
> Regards,
> --=20
> Rowan Collins
> [IMSoP]

We had that exact idea relatively early, but it exposes other =
problems=E2=80=A6 order suddenly matters. You cannot just add "a" type =
and get the expected results.

E.g.
function f(true | string $foo) { ... }

everything except 0, =C2=B10, "0" and "" would now return true. That's =
totally WTF. Sure, it's more friendly for people who want to read =
*rules*. But it is very bad for intuitivity.

Also:

> function i(string | int) { echo gettype($number); }
> i('10'); // string
> i(10); // string

This. This is especially bad as it has different behaviors in strict and =
weak mode then. That's a no-go.

The current way is the only viable one, as far as we discovered.

Bob=