Hi Sebastian, > On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen <sbj.ml.r...@gmail.com> wrote: >> >> Yeah, I don’t like this behaviour much. I want to avoid inconsistency with >> the behaviour of extension functions (i.e. zend_parse_parameters) where >> possible, though. Since this has come up so much, I should probably make an >> RFC to change this aspect of ZPP’s behaviour. > > That RFC should probably be voted on before this RFC proceeds into voting.
That would be the idea. > After skimming through the RFC I'm unsure what the following code would > produce: > > function test(int $a, int $b) {} > > test("10.4", 10.6); > > If a warning/notice is raised, fine. If it will just result in $a === > (int)10 && $b ===(int)10 : The first argument would be converted to 10 and a notice (“Non well formed numeric string”). The second would also be converted to 10, but silently. I agree with your sentiments about data loss, but I am reluctant to deviate much from the behaviour of internal functions to avoid the inconsistency that plagued the previous RFC. > If type annotations wouldn't go beyond the safety that php currently > provides by converting in specific contexts and casting what is the > benefit in adding them? They’re still much safer than what we currently have. An unhinted parameter will accept anything. A scalar hinted parameter won’t accept non-scalars, and will only accept certain scalars. Plus, they also avoid the need to use things like docblocks for many functions where merely adding types would make them self-explanatory. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php