Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109513
MIME-Version: 1.0
References: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
In-Reply-To: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
Date: Thu, 2 Apr 2020 14:10:43 +0100
Message-ID: <CALKiJKouE3HJGO2CEu_SXU6Dz3_=ra7_DR14oN=ba8naY2YLyQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000005845c05a24e88e2"
Subject: Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000005845c05a24e88e2
Content-Type: text/plain; charset="UTF-8"

Hi Nikita,

On Thu, 2 Apr 2020 at 09:14, Nikita Popov <nikita.ppv@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]

--00000000000005845c05a24e88e2--