Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75449
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: <DAE582FE-DABD-42DD-A0C3-ACB5C1BEA6AD@gmail.com>
Date: Mon, 14 Jul 2014 14:28:51 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D00169E9-7F9B-4471-88AA-BED075285B6F@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <DAE582FE-DABD-42DD-A0C3-ACB5C1BEA6AD@gmail.com>
To: Alexey Zakhlestin <indeyets@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 14:12, Alexey Zakhlestin <indeyets@gmail.com> wrote:

> I don=92t think that "scalar casts=94 should do any additional =
error-catching. they target a very different usecase.
> It shouldn=92t guarantee correctness of the whole program. It should =
guarantee that variable types are fixed inside of function.

That is exactly what is being proposed though. People (including Anthony =
himself, along with other proposals) have previously suggested type =
hints which just casted. However, I don=92t think this is terribly =
useful. You can already do that really easily (`$foo =3D (int)$foo;`), =
and it=92s too lenient; the non-scalar type hints are useful because =
they validate your types, and the scalar ones, while casting, should =
validate to a degree.

> In my opinion, this patch should act 100% similar to zpp.
> And if, at some later point zpp-behaviour changes similar change =
should happen to userland "scalar casts=94

Keeping close to zpp would be nice, but zpp=92s behaviour isn=92t always =
the most sensible and useful one, but we should try to keep somewhat =
close to it.

> Some people talk about inconsistency, which is introduced by reusing =
same syntax for "strict parameter types" and "scalar parameter casts=94. =
There=92s some truth there.
> Let=92s use different syntax.
>=20
> This might work:
>=20
>    function foo((int) $a)
>    {
>        var_dump($a);
>    }
>=20
> I would read it as declaration-level casting

That has already been proposed. That is not this proposal. I=92d suggest =
you read back in this thread; I=92ve previously explained my issues with =
just casting with no validation, pure strict type hints, why it=92s fine =
to re=FCse the syntax, and linked to Nikita Popov=92s blog post on the =
subject.

--
Andrea Faulds
http://ajf.me/