Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75402
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com>
In-Reply-To: <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQJuUFVOlGiX172RfpkkW7aXwqSXwwOWY2SKmkP33FA=
Date: Sun, 13 Jul 2014 17:29:54 +0300
Message-ID: <be064c8882df8540c5a4c2f291695b4a@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: zeev@zend.com (Zeev Suraski)

> 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 use case of converting string based values into integers and floating
point numbers is a very common one, given anything that comes into PHP as
input is a string.  In terms of productivity, it's much easier for me to
stick an 'int' type hint (or whatever we call it) on a piece of $_GET value
that I know needs to be an integer, than it is for me to now surround it in
a try/catch block and protect against a user or a wannabe hacker sending in
'123abc' in there.  In such a case treating this as 123 (int) makes perfect
sense, with the erroneous input silently converted to something sane the
code can live with.  A key advantage of these casting type hints is saving
the need to write lengthy and somewhat obscure pieces of code that just
validate inputs.  If we force developers to surround them with try/catch
blocks, we lose at least half of the value here IMHO.

I therefore think conversion from string to any of the basic types should
never result in an exception even if information is lost;  And it does make

> 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.

I'm undecided on this one too.

Zeev