Re: [RFC] Scalar Type Hints

Hey Zeev, > On 1 Jan 2015, at 12:41, Zeev Suraski <zeev@zend.com> wrote: > > I like this draft too, and that's a first after countless proposals over the > last decade - so kudos! :) Glad to hear that. > My main feedback here are the discrepancies between this RFC's casting rules > and PHP's current built-in casting rules. Ideally, I'd like those to be > completely identical and not almost-identical. The RFC’s behaviour exactly matches that of zend_parse_parameters, with the exception of NULL handling. In fact, the implementation is shared. Whether zend_parse_parameters’s behaviour matches that of other implicit casts in PHP is another matter. > Since we're talking about v7.0, we do have the option of making changes to > PHP's fundamental casting rules where appropriate (e.g. converting an array > to a string). > But that said, I think the way strings->numbers are handled - where they > accept only numeric strings as it would mean you can't use casting to an > int/float as an ultra-simple way to sanitize untrusted input. I would > change the † section from: > > †Non-numeric strings not accepted. Numeric strings with trailing characters > are accepted, but produce a notice. > to > † Numeric strings with trailing characters and non-numeric strings are > accepted, but produce a notice. > > - and apply it to both this RFC and the infrastructure convert_to_*(), so > that it applies across the board in PHP. That could be changed, of course, but I don’t think it’s the job of this RFC to change our implicit casting/validation rules for functions. I would be willing to postpone this RFC’s vote until an RFC that makes some changes gets through, though. That said, I don’t actually like the idea of changing this specific thing. “0”, “0.0” and possibly even “0 foobar” are reasonable candidates for an integer value, but I don’t think making “” or “foobar” be accepted as numbers makes much sense at all. Thanks! -- Andrea Faulds http://ajf.me/