Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109620
MIME-Version: 1.0
References: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
 <CALKiJKouE3HJGO2CEu_SXU6Dz3_=ra7_DR14oN=ba8naY2YLyQ@mail.gmail.com>
In-Reply-To: <CALKiJKouE3HJGO2CEu_SXU6Dz3_=ra7_DR14oN=ba8naY2YLyQ@mail.gmail.com>
Date: Tue, 14 Apr 2020 14:50:41 +0200
Message-ID: <CAF+90c9C0_7PYpYSpVuPE+D5wX1VPmh0oJXDaLeJoJYs3TOxgg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b2a88005a33fa655"
Subject: Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000b2a88005a33fa655
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 2, 2020 at 3:11 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> 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.
>

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

--000000000000b2a88005a33fa655--