Re: [RFC] Scalar Type Hints

Hey Nikita, > On 1 Jan 2015, at 14:05, Nikita Popov <nikita.ppv@gmail.com> wrote: > > While in favor of introducing scalar type annotations, I'm against this proposal in > particular. I've held a different position in the past, but by now I'm thoroughly > convinced that if we introduce scalar type declarations, they should be strict. No wiggling, no > casting. > > Apart from being consistent with the existing behavior of type declarations and being what the > majority of the vocal community wants, it is also possible to reason about strict type declarations > statically. > > This means that an IDE or other tool will be able to perform meaningful analysis based on > typehinted functions. E.g. if you pass the result of a string function to an int parameter, your > code is definitely wrong and you can be told so. Loose typehints as proposed here do not offer this > possibility, because a string can be or can not be a valid input to an int parameter depending on > the exact value. > > For the same reason loose typehints are also more fragile. Code that worked in casual testing > during development will fail in production when unexpected, improperly validated user input is > encountered. With strict types on the other hand it is very likely that code working with one input > will also work with all other possible inputs, because the type check is not value-dependent. (Types > are typically much less volatile than values.) > > The ability to statically check type annotations is rather important to me. I think much of the > usefulness of this feature would be lost without the ability to check correct usage with tooling. > I'd also like to point out that Hack uses a strict type scheme and it seems to work well there > (though I do acknowledge that the situation is not the same, as Hack has a generally more powerful > and fully statically checked type system). > > Apart from these general thoughts, I also think that this proposal is a regression from the > previous one. In the name of "consistency" it uses the rather weak zpp validation rules, > which allow a lot of questionable input. Just look at the conversion table in the RFC, practically > all of it is "Yes". I understand the motivation to reduce the number of different > conversion semantics, but I just can't get behind it if it means reusing existing, bad > conversion rules. I would respond with something novel, but I notice now that your email is exactly the same as your comment on reddit, and there’s little point in responding to the same thing twice. So, for that reason, I’ll just reproduce my response on reddit, with some minor edits: > I'm likely -1 on this proposal. I've held a different position in the past, but by > now I'm thoroughly convinced that if we introduce scalar typehints, they should be strict. Why are you opposed to adding non-strict type hints? I realise that strict type hints are desirable for certain reasons, but they fit very poorly with the rest of the language and are unlikely to ever make it into PHP. So why, then, oppose the addition of non-strict hints? Surely these hints, which offer many (albeit not all) of the benefits of strict hints, are far better than nothing? > Apart from being consistent with the existing behavior of typehints This RFC is consistent with the existing behaviour of extension functions (which match all userland type hints in behaviour). Besides, strict hints would be inconsistent with the rest of the language. PHP has never been strict for scalar types, and I think they'd make a rather awkward fit for that reason. > , it is also possible to reason about strict typehints statically. > This means that an IDE or other tool will be able to perform meaningful analysis based on > typehinted functions. E.g. if you pass the result of a string function to an int parameter, your > code is definitely wrong and you can be told so. Loose (casting) typehints do not offer this > possibility, because a string can be or can not be a valid input to an int parameter depending on > the exact value. You have a point there. Unfortunately, casting hints prevent certain types of validation. However, some type combos always work and some always don't, so you can still error for certain cases (NULL, array, resource, or object where scalar expected). While they do prevent certain types of validation, they don't prevent optimisations, so HHVM (and perhaps Zend in future) can still benefit from the type information. > For the same reason loose typehints are also more fragile. Code that worked in casual testing > during development will fail in production when unexpected, improperly validated user input is > encountered. This is also true to an extent, but it is alleviated partly if code is fully type hinted. If your entire codebase has type hints, such errors can be caught early before they're passed to other functions. Once values are converted to integers, they stay integers (unless you pass it to something taking a string). Thanks. -- Andrea Faulds http://ajf.me/