Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113104
MIME-Version: 1.0
References: <CAFPFaMKDELHFr44kOncQWeCi7KZUL7XLNL2JyvJvmNLTgjDBOQ@mail.gmail.com>
 <CAG9XoMTc-7axJBQu2Skt6ng+6pU4o7gsXy+J47C5EeXyZLmZ=A@mail.gmail.com>
 <ecf37ece-51a9-5b41-5e68-cbcea3786e29@allenjb.me.uk> <CAG9XoMTsgrQetKA9jkZC9-pxq7aYSgS3FEWLPMmTjSE_vS70GA@mail.gmail.com>
 <CA+p1FaaB-84BteyC6k0EMqUFwsDmozsAYys9ZYKsr34DBgQ7=Q@mail.gmail.com>
 <CAG9XoMS2C8miP2-wEPYBOT6q+5CAs2y4E_5cQuGYg7y6yf-o9A@mail.gmail.com>
 <248543D8-4266-4495-9FC4-762A63625A93@cschneid.com> <0d04114d-d90a-913d-627e-16006ec655ef@gmail.com>
In-Reply-To: <0d04114d-d90a-913d-627e-16006ec655ef@gmail.com>
Date: Sat, 6 Feb 2021 20:29:09 +0000
Message-ID: <CA+p1FaZTd6ZMVATY-oBtzLDBxgvtA1rd+_fHDYeYdTCAuPgdpw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a05e3405bab0ca42"
Subject: Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
From: davidgebler@gmail.com (David Gebler)

--000000000000a05e3405bab0ca42
Content-Type: text/plain; charset="UTF-8"

This is all a bit moot anyway, the RFC proposal is for warnings or notices
on implicit casts only.

I'm not a voting member for RFCs so my opinion is mere food for thought,
nonetheless my two cents is that:

a) The proposal relies on a premise that an implicit cast of (non-zero
fractional) float to int is inherently ambiguous or a mistake.
I disagree with this as outlined in my previous messages; namely my
objection is truncating a float on cast to int is the widely established
normal behaviour in numerous programming languages.
There should not be a penalty in the form of an error just for doing such a
conversion implicitly, in accordance with how PHP's type coercion works by
design.

b) String offsets, where a warning occurs already, is something of a
special case; this warning was added I believe (5.4?) because malformed
string offset was a known common error in the community. It's not even
entirely consistent; $foo["2"] is fine, $foo[2.5] is a warning with offset
[2], $foo["2x"] is a warning with offset [2] and $foo["2.5"] is a TypeError.

c) It's a substantial BC breaking change likely to affect a lot of existing
code, even though that code works as intended.

d) If it is implemented at all, it should not be an error level as high as
a warning.

-Dave

On Sat, Feb 6, 2021 at 7:32 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 06/02/2021 14:47, Christian Schneider wrote:
> > I'm sure there is a lot of code which takes user input and uses (int)
> casts to ensure they are dealing with integers.
> > There is also intval() as an alternative but my guess would be that real
> world code uses 50% (int) and 50% intval() to do this.
>
>
> My thoughts exactly. Code along these lines is common and, in my
> opinion, perfectly reasonable:
>
> $id = (int)$_GET['id'];
> if ( $id !== 0 ) {
>       // throw an exception, return false, look up a default, etc, as
> the application's design requires
> }
> // proceed knowing that $id is a non-zero integer
>
>
> I would however welcome a new function or syntax that either performs a
> "strict cast" (producing an error if the cast is lossy in any way) or
> checks in advance if a cast *would be* lossy.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000a05e3405bab0ca42--