Re: [RFC] Stricter type-checks for arithmetic/bitwise operators

On 02.04.2020 at 10:47, Nikita Popov wrote: > On Thu, Apr 2, 2020 at 10:35 AM Christoph M. Becker <cmbecker69@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 >> >> 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. I think something like get_resource_id() would be a good addition. >> 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. Good point indeed! So +1 from me on the RFC. Not absolutely sure about the open questing regarding going one step further, but tentatively also +1 on that. Thanks, Christoph