Hi Theodore, > De : Theodore Brown [mailto:theodor...@outlook.com] > > however, there are hundreds of places where code relies on GET/POST > parameters > being automatically trimmed when passed to a function expecting an integer. > The current coercive proposal would deprecate this and later make it an > error.
Instead of rejecting the whole RFC, you can ask to keep supporting leading and trailing blanks in numeric strings. That's something that is really still under discussion, even between authors. To be clear, I prefer authorizing leading and trailing blanks (but just blanks), Zeev prefers restricting it, and I am not sure about Dmitry's preference. So you see it is still open ! About BC, I don't think we are too lax with BC because developers would have years to fix a pair of lines in their code. Running wordpress and other large code just found 10 or 20 places where developers would have to change something. So that's really minimal work and they have long years to do it. > To avoid these notices/errors when upgrading, developers may take the > "easy" > route of casting any input passed to a function expecting an int or float. That's possible but just much less often than they would do for 'strict mode'. > This is the same "too strict may lead to too lax" problem pointed out by the > coercive RFC itself. There's a reason that integer handling was actually > *relaxed* back in PHP 5.1 (see > http://php.net/manual/en/migration51.integer-parameters.php). > Why suddenly make the default more strict again? Agreed. But decision still open. > I am not against tightening up some of the default weak conversions (e.g. to > not allow "99 bugs" for an int type), but in my opinion this should be done > very carefully, and separately from any scalar type declaration proposal. > Major changes to the casting rules have the potential to seriously harm PHP 7 > adoption, especially in enterprises with large amounts of legacy code. The > Scalar Type Declarations v0.5 RFC has the advantage here because it "just > works" when type hints are added to existing code in the default weak > mode. Our STH does not break anything. Maybe the newly-published version is more clear. We propose implementing *exactly* the PHP5 logic and just raise E_DEPRECATED messages that won't stop execution at all. Ignoring these messages, there will be absolutely no difference in behavior with PHP 5. > 2. Strict types are important in some cases. > > When it comes to authentication and financial calculations (a couple of areas > I routinely deal with) it is extremely important that errors are caught and > fixed early in the development process. In financial or security-sensitive > code, I would *want* any value with the wrong type (even a string like "26") > to be flagged as an error when passed to a function expecting an integer. Agreed. That's why, in the future, we may add new 'strict' type hint that will accept nothing but their native type. We didn't add them here because it would have been too confusing for a first release, and the whole discussion is already complex enough. But I agree they can have some use. The difference with the other RFC is that, we can add strict types in the future but, is you choose the other RFC, it's a much more radical decision because dual mode will remain forever. > The option for type-based (rather than value-based) validation is equally > important when it comes to return types. Unless I have missed something, > the > "Coercive Types for Function Arguments" RFC currently doesn't deal with > return > types at all (they aren't mentioned in the RFC). Would it handle scalar return > types the same way as it does function arguments? Maybe not clear in the RFC but return types are handled exactly the same way. If I declare a function to > return an int, and I return a string instead (even if the string is numeric), > there are many cases where it would be an unintentional error. And if it > errors depending on the value, rather than the type, it often wouldn't be > possible to catch the problem statically. Right. That's an additional argument in favor of introducing strict scalar types in the future, as I said above. > Here's a simple example of the advantage offered by strict types and static > analysis in the Scalar Type Declarations v0.5 RFC: > > <?php > declare(strict_types=1); > > function getCustomerName(int $customerId): string > { > // look up customer name from database and return > } > > function getInvoiceByCustomer(int $customerId): Invoice > { > // retrieve invoice data and return object > } > > $id = filter_input(INPUT_GET, 'customer_id', FILTER_VALIDATE_INT); > > if ($id === false) { > echo 'Customer ID must be an integer'; > } else { > $customer = getCustomerName($id); > $invoice = getInvoiceByCustomer($customer); > // display invoice > } > > Strict types + static analysis can tell you that this will fail (because it's > based purely on types, and a string is being passed to a function expecting > an integer). Coercive typing cannot statically tell you that it will fail, > because it doesn't know whether the string passed to > `getInvoiceByCustomer` > is acceptable as an integer without also knowing its value. If strict type hints are defined in the future, and if you use them in your example, you will get exactly the same and static analysis will still be able to find your bug. The difference is that you will decide to use them only where you need to make it more strict, function by function, argument by argument. > To those who are worried that the addition of a strict mode will split the > community into separate camps, I would say "It's too late!" The community > has > already been split over this issue for years. Conceptually, the optional > strict mode proposed in Anthony's RFC is not very different from == vs. ===, > or `in_array` with the $strict argument set to true. And I certainly am > glad that PHP offers these options! Those choices are just additional options you may use in your code or not, not a global switch between to global modes. And, even if you consider the community is already split, we are very idealistic and consider that it can be unified again ;) Thanks for all. Tell me where I was not clear. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
