On Sun, Jul 13, 2014 at 3:57 AM, Andrea Faulds <a...@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
