On Wed, Dec 31, 2014 at 9:27 PM, Andrea Faulds <a...@ajf.me> wrote: > Good evening, > > Parameter type hints for PHP’s scalar types are a long-requested feature > for PHP. Today I am proposing an RFC which is a new attempt to add them to > the language. It is my hope that we can finally get this done for PHP 7. > > I’d like to thank Dmitry, who emailed me and gave me some feedback on the > draft RFC and some improvements to the patch. He encouraged me to put this > to internals sooner rather than later, as it’s a feature many people are > hoping will be in PHP 7. > > The new RFC can be found here: https://wiki.php.net/rfc/scalar_type_hints > > As well as the RFC, there is a working Zend Engine III patch with tests, > and an incomplete specification patch. > > Please read the RFC (and specification patch, if you wish) and tell me > your thoughts. > > Thanks! >
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. Nikita
