Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109510 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69749 invoked from network); 2 Apr 2020 14:07:04 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 2 Apr 2020 14:07:04 -0000 To: internals@lists.php.net References: Date: Thu, 2 Apr 2020 14:33:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 46.59.72.204 Subject: Re: [RFC] Stricter type-checks for arithmetic/bitwise operators From: ajf@ajf.me (Andrea Faulds) Message-ID: 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