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? > > 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. > I've now update the RFC to move the open question into future scope, as I agree that this is a larger topic that should be discussed separately. I plan to open voting on this RFC in a couple of days, if there are no further concerns. Nikita
