Hi! > How many of us are expected that > > mydb_find_by_id(INT_MAX+1); > Note: INT_MAX+1 is pseudo integer string value. > > fails with fatal error? I guess it's not many.
I'm not sure what is the meaning of "INT_MAX+1 is pseudo integer string value" - if it fits the integer, it's the integer, if it's a string that looks like decimal rendering of a natural number that is equal to INT_MAX+1, then it's not an integer, it's just a string. It can not be used as integer. If somebody voted on this RFC without expecting it, that means they did not understand the RFC. I don't know what can be done about people voting for RFCs they don't understand - we can't take an exam before voting. We expect people first understand it then vote, and assume everybody who votes understands what it means and accepts the consequences. > Users are recognized record ID as integer even if it's a string integer > indeed. There's no such thing as "string integer". It's either string - which can be convertible or not convertible to integer - and there's actual integer value. > I think many, if not most, users are not aware that db record ID field is > "string integer" . As long as users do not apply arithmetic, string integer > worked perfectly with PHP. I'm saying this is a tradition. I don't see where you derive such "tradition" from. PHP never worked this way. The only difference is that before you'd get something like INT_MAX or -INT_MAX or 0 or whatever random value after conversion. I don't see how that would be better than fatal error, really. > Most obvious use case is record ID that I mentioned above, but it's not > limited to record ID. e.g. all database numeric values/JSON numeric/ > PHP array integer type key beyond INT_MAX/MIN. You can't have integer array key beyond integer, that is a logical impossibility. As for external values, external value can be anything - row of ones, random binary noise, string "porcupine", anything. You can't expect it to be convertible to integer. You'll have to check anyway. "numeric" type is not going to help you. > Great. I think "int"/"float" type hint is too strict even under weak mode. > Therefore, I want to have "numeric" type hint at least. I don't see how this helps anything. "numeric" is not a type, it is a validation of a string form. As such, it has very little to do with PHP types. > Having "numeric" or accepting huge value(including GMP) for "int"/"float" > should be acceptable. IMHO. That negates the whole purpose of having "int" type, since what comes out of it is not int anymore. > As I wrote, huge numbers are valid data for databases. I don't want to have String "porcupine" is a valid data for database too. Should we have a type that says "number or string 'porcupine'"? Both are valid data for DB. But they do not form a type. > DoS incident just because PHP limits numbers to native type range > while databases accept these larger values as valid values. Databases accept *anything* as valid values. If you expect this to fit PHP's scalar types, you need to check. Otherwise, you need to use PHP type that can accommodate anything, namely - string. > We may have integrated GMP float in near future also. Accepting compatible > value/type is mandatory if it's a type "hint" for weak mode. I don't > think we > decided to have type declaration(type enforcement), do we? We can accept compatible values. The question is what to do with *incompatible* values. Accepting those is not really possible within typed parameters semantics. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
