Hi! > If you need to force to map value to PHP type, you have "strict" mode. > "Weak" > mode is just too strict currently even if PHP handled int/float/string as > "integer"/"float" including invalid values traditionally.
That is what was decided by votes - to make type conversions fail on values that can not be represented by these types. > New PHP7 type hint doesn't allow "valid" int/float/string as > "integer"/"float". Because "string having lots of digits" and "integer" is not the same thing - the latter has limits, the former does not. You can not really use them interchangeably. > This is unintuitive change for most PHP users because of weakly typed > tradition. I don't think it's correct - there was never tradition that any string can be successfully represented in integer type. It's just not possible - integer type is a limited type and string is not. The only change was made that if it can not be represented, the parameter typing produces failure. I'm not a big fan of it, but that's what the vote decided, so that's what we have. > I'm sure there will be so many codes that misuses type hint if there is no > "numeric" type hint. I'm also sure their problem is not in absence of type that says "string matching regexp [0-9]+" since I do not see a use case which such type would improve. You can not do anything you do with int with such type, and if you need to so string pattern validation, that's not function of the type system, at least not in PHP. > Users must validate all inputs that cannot be trusted. e.g. Users must > validate is JSON numeric value has numeric form expected. Surely, but we won't have scalar types of "url", "email address", "host name", "IPv6 IP address", "phone number in Brazil" or "russian car license plate" - even though I'm sure validating such strings has a lot of applications. It's just not what types in PHP do. Of course, you can have *user* types implementing all that - nothing prevents you from doing it. > PHP types are not machine native types. But yes, it forces PHP type - > that's why it is *type* check. > > > Type hint is better to stay as "hint" under weak mode. IMO. I'm not sure I understand what you mean here. > It's alternatives. Resuming execution with exception is harder. > Customizable pseudo-type is too late for PHP 7.0. We do decided > to introduce basic type hint and it has issue to be resolved. Let's > concentrate on resolution. That's what we're doing, and the resolution should not be introducing ad-hoc pseudo-types for specific use cases. For 7.0, the resolution can not be introducing anything at all, as April 29 > March 15, but more long-term it is also not the right approach. > Having "numeric" type hint or StrictSTH RFC concept adoption are > possible resolutions. If there is better resolution, I appreciate it. I don't see what specifically you're trying to resolve. If the case is to validate numeric strings, there are functions for it. If the case is to avoid failures on dirty data, your only option is pre-validation, since strict validation is what was decided for parameter types. If you'd like to change that, you can submit an RFC for 7.1, but as it was just recently decided by vote otherwise, I don't see how such RFC can succeed. > BTW, GMP integer is already integrated into PHP why not treat GMP as int? Because GMP object is not int. It can be convertable to int, but the question of conversion failure still remains. > It's type "hint", isn't it? I'm not sure I understand what you mean here. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
