On 02.04.2020 at 10:14, Nikita Popov wrote: > I would like to propose making the use of arithmetic/bitwise operators on > arrays, resources and (non-overloaded) objects a TypeError exception: > > https://wiki.php.net/rfc/arithmetic_operator_type_checks > > This is inspired by some of the recent discussions, in particular the > operator overloading RFC (where the fact that operations on non-overloaded > objects still succeed with just a notice was criticized) and the > increment/decrement RFC, which handles the array case of this proposal for > inc/dec only. > > I think as-is, this RFC should be completely uncontroversial. However, > there is an open question on whether we want to make this slightly more > strict, in order to align the semantics with the rules for weak parameter > type checks for ints/floats. > > If we do that, then this RFC could be a stepping stone towards making > "implicit" internal casts use the (weak) parameter type checking semantics > more generally, which I think would be a good idea. The current explicit > cast semantics we use everywhere are too forgiving for most circumstances > (e.g. an array is almost always not a reasonable input where an integer is > expected).
Thanks! Generally I like that very much. I'm not quite sure, though, what to do with resource to int conversions. These are documented to be valid[1], and are sometimes deliberately used[2], and as such it might be reasonable not to throw on these conversions (maybe even change the current behavior of the ~ operator). After all, I hope we will be able to port all resources to objects sometime, and till then we could stick with more lax semantics. [1] <https://www.php.net/manual/en/language.types.integer.php> [2] <https://www.php.net/manual/en/function.ssh2-sftp.php#refsect1-function.ssh2-sftp-examples> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
