Hi! > Apart from being consistent with the existing behavior of type declarations
We have no existing behavior of scalar type declarations except for hidden ones in internal functions and object types behave in PHP completely differently from scalars, so there's no place for "consistency" claim here. Scalars always has been convertable in PHP, internal functions accepting scalars always behaved in a coercive and not strict way. > and being what the majority of the vocal community wants, it is also I have no idea what "vocal community" is, but what exactly you're basing your claim of majority on? > possible to reason about strict type declarations statically. You can reason about coercive declaration as well as you can reason about strict one. > possibility, because a string can be or can not be a valid input to an int > parameter depending on the exact value. And the IDE can tell you exactly that. > 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 Since all the inputs are ultimately strings for PHP, so you'd have to convert from string to other types somewhere, and if that code does not perform properly on certain input, you still get a failure. You are just moving the failure around. And of course the claim "if the code works correctly with one integer input it would work correctly with any other integer input" is wildly incorrect. In fact, type errors (if you define types broadly as string/integer) are a tiny minority of logic errors in software. > 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 Java uses strict typing too. And Perl has no typing whatsoever. So what? How bringing an example of one language that does what you want is an argument for PHP to do that? There are examples of languages doing practically anything imaginable. > 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 How many "yes" is a bad thing? It's not a competition of which approach can produce the most error messages. It's about which one is the most productive to work with. You want PHP to be strictly typed, but PHP is not that language. If you want to make PHP that language, IMHO it's misguided but doing it by introducing inconsistencies via new syntax that behaves different from existing analogous parts of the language - like having typed parameter behave differently in internal and user-defined function - is both misguided and wrong. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
