Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109504
MIME-Version: 1.0
References: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
 <d1e87385-d710-4eea-c40e-cc13653a1ba8@gmx.de>
In-Reply-To: <d1e87385-d710-4eea-c40e-cc13653a1ba8@gmx.de>
Date: Thu, 2 Apr 2020 10:47:07 +0200
Message-ID: <CAF+90c94_BxGU49+8qCCy+BWMMBjxe5WsadYORNN7YVQkJ01Bw@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000830dd705a24ad9d0"
Subject: Re: [RFC] Stricter type-checks for arithmetic/bitwise operators
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000830dd705a24ad9d0
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 2, 2020 at 10:35 AM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 02.04.2020 at 10:14, Nikita Popov 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
> >
> > This is inspired by some of the recent discussions, in particular the
> > operator overloading RFC (where the fact that operations on
> non-overloaded
> > objects still succeed with just a notice was criticized) and the
> > increment/decrement RFC, which handles the array case of this proposal
> for
> > 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 parameter
> > 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
> semantics
> > more generally, which I think would be a good idea. The current explicit
> > cast semantics we use everywhere are too forgiving for most circumstances
> > (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).
>

While resource to int conversions are indeed valid, they are not exactly
commonly used, and if they are used, I would expect an explicit (int) cast
to be involved. I very seriously doubt that someone writing "$x = $y / 2"
really intended this to mean "$x = resource_id($y) / 2" -- it is much more
likely that a variable go mixed up. In the unlikely case that that they
really did intend that, the option of writing "$resourceId = (int) $y; $x =
$resourceId / 2" remains, and is much clearer.

On that note, I do wonder whether we should introduce a function like
get_resource_id(), that makes it more explicit that an (int) cast is
supposed to fetch a resource ID. This is not a very common operation, and I
suspect that many PHP programmers may not be familiar with the semantics of
integer casts on resources. Using get_resource_id($file) would make the
intent clearer relative to (int) $file. This is similar to the recently
added get_mangled_object_vars() function, which essentially does the same
as (array) $object, but makes it obvious that you really are interested in
mangled properties.

> 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.

I think that's really an argument to align the behavior of resources and
objects, as it means one less BC break when resources are converted to
objects. Historically that's something we did in minor versions, so it's
good to reduce the amount of semantics that change when such a conversion
is done.

Regards,
Nikita

--000000000000830dd705a24ad9d0--