Re: [RFC] Scalar Type Hinting With Casts (re-opening)

Hi, Would it possible to control the implicit casting through a PHP variable ? (or perhaps modify E_STRICT to display a warning if this kind of implicit cast is done ?) I mean specifying explicitly a type is often useful to make sure the proper type is passed to the function, and there's no bug in the calling func. e.g. safety check like function foo($bar) { if (!is_int($bar)) {

      throw new Exception('Invalid parameter type');

} } will not be "equivalent" to function foo(int $bar) { } and there will be no way to have an equivalent behaviour once "type hinting" is used ! Thanks, Jocelyn Le 13/07/2014 14:09, Nikita Popov a écrit :

On Sun, Jul 13, 2014 at 3:57 AM, Andrea Faulds <ajf@ajf.me> wrote:

Good evening, PHP’s type hinting system is rather incomplete as it does not support 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 as 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’ve 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’m hoping I can get this into PHP 5.7. I think scalar type hinting would be a valuable addition to PHP’s 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