Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75464
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <53C3E31C.1070306@gmail.com>
Date: Mon, 14 Jul 2014 15:17:36 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <0C5F203F-3DA7-4C38-A132-955836AF2274@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <53C3E31C.1070306@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: ajf@ajf.me (Andrea Faulds)


On 14 Jul 2014, at 15:03, Rowan Collins <rowan.collins@gmail.com> wrote:

> Looking at the current table in the RFC, I'm not clear why NULL should =
pass as any value, but not array. Could it not behave the same as the =
existing type hints, i.e. accepted only if declared as a default?
>=20
> function foo(array $bar) { } foo(null); // ERROR
> function foo(array $bar=3Dnull) { } foo(null); // OK, $bar =3D=3D NULL
> function foo(int $bar) { } foo(null); // ERROR
> function foo(int $bar=3Dnull) { } foo(null); // OK, $bar =3D=3D NULL

I=92m thinking this as well. I wonder if perhaps it should be casted by =
default, but if you make it explicitly nullable, it won=92t cast if NULL =
is passed.

> In summary, I think if the rules can be explained concisely, and the =
table derived from those rules, it will feel less confusing than having =
to consult the table to be sure of the effect.
>=20
> Having to say "for arrays, the logic is this; for strings, this; for =
integers, this; for booleans, the other" makes the whole thing seem like =
a bit of a kludge, and is exactly what the existing "lossy" casts suffer =
from.
>=20
> I would stress that I see this as a new definition of "lossless cast"; =
this RFC is intentionally *not* using the existing cast logic, as =
explicit casts *never fail*, so "but existing casts work this way" is =
not relevant.

Right. I=92d like the rules to be simple enough. I think the string, int =
and float ones make perfect sense and can be easily explained, it=92s =
bool I=92m uncertain about.

--
Andrea Faulds
http://ajf.me/