> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
