Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80048
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=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <16d442a345cf2cbd4faac6d068c57343@mail.gmail.com>
Date: Thu, 1 Jan 2015 15:24:32 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <56A3D9D5-6971-405D-93BD-D5B9096DE9FC@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <16d442a345cf2cbd4faac6d068c57343@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hey Zeev,

> On 1 Jan 2015, at 12:41, Zeev Suraski <zeev@zend.com> wrote:
>=20
> I like this draft too, and that's a first after countless proposals =
over the
> last decade - so kudos! :)

Glad to hear that.

> My main feedback here are the discrepancies between this RFC's casting =
rules
> and PHP's current built-in casting rules.  Ideally, I'd like those to =
be
> completely identical and not almost-identical.

The RFC=E2=80=99s behaviour exactly matches that of =
zend_parse_parameters, with the exception of NULL handling. In fact, the =
implementation is shared.

Whether zend_parse_parameters=E2=80=99s behaviour matches that of other =
implicit casts in PHP is another matter.

> Since we're talking about v7.0, we do have the option of making =
changes to
> PHP's fundamental casting rules where appropriate (e.g. converting an =
array
> to a string).
> But that said, I think the way strings->numbers are handled - where =
they
> accept only numeric strings as it would mean you can't use casting to =
an
> int/float as an ultra-simple way to sanitize untrusted input.  I would
> change the =E2=80=A0 section from:
>=20
> =E2=80=A0Non-numeric strings not accepted. Numeric strings with =
trailing characters
> are accepted, but produce a notice.
> to
> =E2=80=A0 Numeric strings with trailing characters and non-numeric =
strings are
> accepted, but produce a notice.
>=20
> - and apply it to both this RFC and the infrastructure convert_to_*(), =
so
> that it applies across the board in PHP.

That could be changed, of course, but I don=E2=80=99t think it=E2=80=99s =
the job of this RFC to change our implicit casting/validation rules for =
functions. I would be willing to postpone this RFC=E2=80=99s vote until =
an RFC that makes some changes gets through, though.

That said, I don=E2=80=99t actually like the idea of changing this =
specific thing. =E2=80=9C0=E2=80=9D, =E2=80=9C0.0=E2=80=9D and possibly =
even =E2=80=9C0 foobar=E2=80=9D are reasonable candidates for an integer =
value, but I don=E2=80=99t think making =E2=80=9C=E2=80=9D or =
=E2=80=9Cfoobar=E2=80=9D be accepted as numbers makes much sense at all.

Thanks!
--
Andrea Faulds
http://ajf.me/