On Thu, Apr 2, 2020 at 10:35 AM Christoph M. Becker <cmbecke...@gmx.de> wrote:
> 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). > While resource to int conversions are indeed valid, they are not exactly commonly used, and if they are used, I would expect an explicit (int) cast to be involved. I very seriously doubt that someone writing "$x = $y / 2" really intended this to mean "$x = resource_id($y) / 2" -- it is much more likely that a variable go mixed up. In the unlikely case that that they really did intend that, the option of writing "$resourceId = (int) $y; $x = $resourceId / 2" remains, and is much clearer. On that note, I do wonder whether we should introduce a function like get_resource_id(), that makes it more explicit that an (int) cast is supposed to fetch a resource ID. This is not a very common operation, and I suspect that many PHP programmers may not be familiar with the semantics of integer casts on resources. Using get_resource_id($file) would make the intent clearer relative to (int) $file. This is similar to the recently added get_mangled_object_vars() function, which essentially does the same as (array) $object, but makes it obvious that you really are interested in mangled properties. > 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. I think that's really an argument to align the behavior of resources and objects, as it means one less BC break when resources are converted to objects. Historically that's something we did in minor versions, so it's good to reduce the amount of semantics that change when such a conversion is done. Regards, Nikita
