Hi Nikita,
Nikita Popov wrote:
Hi internals,
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.
Sounds good!
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.
Regarding that, the RFC says we could “Make non-numeric string operands
throwing. Non-numeric here means not starting with a digit (optionally
preceded by whitespace). This would not apply to operators that have
special behavior for strings, such as string increment.”
I know you used “such as” there, but maybe you should specifically point
out the bitwise case. I think increment and the bitwise operators are
the only special cases for strings?
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).
That would be nice! We currently have essentially three (actually more
but these are the big ones) different “weak” behaviours: function
arguments and return values, non-comparison operators, and comparisons,
and I doubt people who don't follow internals are fully aware of the
differences, so it would be good to eventually have just one set of rules.
I guess https://wiki.php.net/rfc/invalid_strings_in_arithmetic was
already a step in this direction and your RFC is a further development
of it.
Thanks,
Andrea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
