Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109517 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 63021 invoked from network); 2 Apr 2020 19:15:36 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 2 Apr 2020 19:15:36 -0000 To: internals@lists.php.net Date: Thu, 2 Apr 2020 17:42:13 +0000 (UTC) Message-ID: <479ea7da1eb418d7d73df14b5767@news.php.net> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1; format=flowed X-Newsreader: JetBrains Omea Reader 1098.1 X-Posted-By: 81.166.177.73 Subject: Re: [RFC] Stricter type-checks for arithmetic/bitwise operators From: terje.slettebo@sandefjordbredband.net (=?iso-8859-1?Q?Terje=20Sletteb=f8?=) 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). I definitely support this proposal, and I'd love the "strict_operators" directive as well, but that's a different proposal, and a different discussion. The current proposal seems, in the words of the proposal, to be pretty uncontroversial: It basically corrects a bunch of WTFs in PHP's type system. Regards, Terje