On Thu, Apr 2, 2020 at 3:11 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> 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? > In preparation for this change, I've decoupled the error reporting from the cast logic, so it is now possible to make just the cast throw, without influencing comparison. However, there might be exception safety concerns, along the same lines as https://wiki.php.net/rfc/tostring_exceptions for the string cast case. Nikita > 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] >
