Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109519
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: Fri, 3 Apr 2020 10:03:34 +0200
Message-ID: <CAF+90c-=dLPoh7pz1uP4bdpPj8ep=3OhAKXrAEFVm9GvkHozsg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008ee73d05a25e5b92"
Subject: Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000008ee73d05a25e5b92
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?
>

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]
>

--0000000000008ee73d05a25e5b92--