Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75391
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
Date: Sun, 13 Jul 2014 14:09:42 +0200
Message-ID: <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b41baeab12e2304fe120cf3
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b41baeab12e2304fe120cf3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 13, 2014 at 3:57 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Good evening,
>
> PHP=E2=80=99s type hinting system is rather incomplete as it does not sup=
port
> scalars, only arrays, callables and objects. In 2012, Anthony Ferrara
> created an RFC which proposed type hinting for scalar types (int, float,
> bool, string and resource) with casting, with behaviour nearly the same a=
s
> that of zend_parse_parameters. Sadly, he later left PHP internals and
> withdrew his RFCs.
>
> Since I am very much in favour of scalar type hints, I=E2=80=99ve updated=
 the
> patch to master and made some minor improvements, and I am re-opening the
> RFC with the intent to try and get it into PHP 5.7. The patch is mostly
> there. It needs some more tests and there are some edge cases I need to
> deal with, but it otherwise works, and I expect I can finish fixing it up
> very soon.
>
> The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast
>
> A pull request is here: https://github.com/php/php-src/pull/717
>
> I=E2=80=99m hoping I can get this into PHP 5.7. I think scalar type hinti=
ng would
> be a valuable addition to PHP=E2=80=99s existing type hinting system.
>
> Thanks!
>

I think the approach described in this proposal is the best way to
implement scalar typehinting, as it allows typical loosely-typed usage
patterns, while still providing type guarantees within the function.

I haven't yet closely reviewed the details of what is and isn't allowed,
but one things I would strongly recommend against is introducing any
"accept but throw a notice" cases. Either a value is allowed or it isn't.
"12foo" to an int/float argument should throw a recoverable fatal error,
like everything else. (I'd change that in zpp as well, but that's a
different discussion).

The question of passing floats like 12.5 to an int param is somewhat
tricky. One could argue that it's possible to end up with floats like
12.0000000001, which are nearly integers but not quite there, and a user
might expect them to behave the same as the integer 12. On the other hand
one can also argue that it's easy to end up with the inverse, namely
11.999999999999. In this case the end user might also expect it to be
treated as integer 12, however an integer cast will truncate it to 11.

The truncation behavior of the float to int cast is why I tend towards the
behavior the RFC currently proposes (forbid non-integral floats): It is
rather unlikely that truncation is what was intended, as such an explicit
rounding call is necessary anyways.

Nikita

--047d7b41baeab12e2304fe120cf3--