Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109503
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
Message-ID: <d1e87385-d710-4eea-c40e-cc13653a1ba8@gmx.de>
Date: Thu, 2 Apr 2020 10:35:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC] Stricter type-checks for arithmetic/bitwise operators
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 02.04.2020 at 10:14, Nikita Popov wrote:

> I would like to propose making the use of arithmetic/bitwise operators o=
n
> arrays, resources and (non-overloaded) objects a TypeError exception:
>
> https://wiki.php.net/rfc/arithmetic_operator_type_checks
>
> This is inspired by some of the recent discussions, in particular the
> operator overloading RFC (where the fact that operations on non-overload=
ed
> objects still succeed with just a notice was criticized) and the
> increment/decrement RFC, which handles the array case of this proposal f=
or
> inc/dec only.
>
> I think as-is, this RFC should be completely uncontroversial. However,
> there is an open question on whether we want to make this slightly more
> strict, in order to align the semantics with the rules for weak paramete=
r
> type checks for ints/floats.
>
> If we do that, then this RFC could be a stepping stone towards making
> "implicit" internal casts use the (weak) parameter type checking semanti=
cs
> more generally, which I think would be a good idea. The current explicit
> cast semantics we use everywhere are too forgiving for most circumstance=
s
> (e.g. an array is almost always not a reasonable input where an integer =
is
> expected).

Thanks!  Generally I like that very much.  I'm not quite sure, though,
what to do with resource to int conversions.  These are documented to be
valid[1], and are sometimes deliberately used[2], and as such it might
be reasonable not to throw on these conversions (maybe even change the
current behavior of the ~ operator).  After all, I hope we will be able
to port all resources to objects sometime, and till then we could stick
with more lax semantics.

[1] <https://www.php.net/manual/en/language.types.integer.php>
[2]
<https://www.php.net/manual/en/function.ssh2-sftp.php#refsect1-function.ss=
h2-sftp-examples>

=2D-
Christoph M. Becker