Re: [RFC] Scalar Type Hints

Hi, On Jan 4, 2015 3:10 AM, "Andrea Faulds" <ajf@ajf.me> wrote: > > Hi Sebastian, > > > On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen <sbj.ml.read@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. Hm. It sounds bad. There is a data loss, a notice must be raised. This is exactly the kind of magic conversion that should not happen for arguments. > 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. Right, but this is what I would expect. Am I the only one?