On 3 Jul 2014, at 18:29, Andrea Faulds <a...@ajf.me> wrote: > Either way, I think there should be some sort of warning (probably an E_NOTICE > or E_WARNING?) when this cast happens implicitly and the number is truncated, > such as in function calls. I’m tempted to remove this from Open Questions and > instead just Do The Right Thing and if someone objects later, the patch and > RFC > can always be changed. > > Of course, it’s worth noting we currently *don’t* do any sort of warning when > casting a float to a long causes a loss of information. Anthony Ferrara’s > sadly > withdrawn RFC for scalar type hints would have done this for user land > functions, but that hasn’t happened yet, so adding a warning here would be > inconsistent with floats.
The patch now raises an E_RECOVERABLE_ERROR if a bigint that is too large is passed as an argument to a function expecting a long. I think this is best as it would hopefully prevent bugs. I was inspired by Anthony Ferrara’s scalar type hinting RFC and Python’s OverflowErrors here. However, this does cause the previously mentioned issue that floats don’t do the same thing and simply truncate without warning here. Should we change the behaviour for them as well? It would be inconsistent not to. Should I make a separate RFC which would make number casting behaviour strict and then make the bigint patch and RFC consistent with it, on the hope that separate RFC could be passed first? That way this wouldn’t become an issue that might block the bigint RFC. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
