Hi Nikita, On Thu, 2 Apr 2020 at 09:14, Nikita Popov <nikita....@gmail.com> 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 for writing this up; one of the conclusions when revising my inc/dec RFC was that this should be proposed, but I've not had the energy to follow through. Discovering that objects become int(1) was a big WTF for me. I'd happily see that throw an error even under an explicit cast - "(string)new class{}" is currently an Error, but "(int)new class{}" and "(float)new class{}" are only a Notice.Would it be possible to throw an Error in this case without fixing the comparison operator quirk you noted in rfc/engine_warnings? I initially thought resources made sense as they are, but like you I concluded that the only real use is to get the ID itself, so explicit casts are enough. There's a possibility that someone used to JS might write $resource+0 instead of (int)$resource out of habit, but it doesn't seem particularly likely, and is easy to fix. get_resource_id() is a good idea, too; for similar reasons, I've often wished objects with __toString() aliased it to a more specific method, rather than it being the only way to get a certain representation. While the behaviour of other types such as strings would be nice to revisit, I think it's worth keeping this RFC to arrays, objects, and resources, because other cases have a lot more to consider in terms of detail and backward compatibility impact. Regards, -- Rowan Tommins [IMSoP]
