Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113096
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>
In-Reply-To: <CAG9XoMTsgrQetKA9jkZC9-pxq7aYSgS3FEWLPMmTjSE_vS70GA@mail.gmail.com>
Date: Fri, 5 Feb 2021 23:45:59 +0000
Message-ID: <CA+p1FaaB-84BteyC6k0EMqUFwsDmozsAYys9ZYKsr34DBgQ7=Q@mail.gmail.com>
To: Benjamin Morel <benjamin.morel@gmail.com>
Cc: AllenJB <allen@allenjb.me.uk>, "G. P. B." <george.banyard@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b2ff3705ba9f6cd5"
Subject: Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
From: davidgebler@gmail.com (David Gebler)

--000000000000b2ff3705ba9f6cd5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Floats (doubles) can accurately represent all integers up to 2=E2=81=B5=
=C2=B3, so there
> is no inaccuracy in this range; the result from round() or floor() could
> therefore be safely passed to (int) even if the cast operator checked for
a
> 0 fractional part, which is what I'm advocating for.

Generating a warning on explicit casts of (non-integer) floats to int would
IMO make no sense at all, it would put PHP at odds with other major
languages such as C, Python and Java and go against normal, reasonable
expectations of how a programming language behaves.

You said in an earlier comment "it's better to be explicit about your
intent", but doing something like (int)3.5 *is* being explicit about your
intent - and truncating casts on float to int is the widely established
norm.

This was exactly my reservation about deprecating this behaviour even as an
implicit cast - in my mind it isn't a bug or flaw, it's there by design.

If developers want to round/ceil/floor/do whatever with a float prior to
using it as an int, they already have that option and the greatest
flexibility.

At least with the implicit case, I understand the motivation and argument
for bringing coercion more in line with strict typing behaviour and
catching cases where such a cast may not have been intentional (though I
still think a warning is too high an error level for this and would favour
a notice or deprecation, were it to be done at all).


On Fri, Feb 5, 2021 at 12:52 PM Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> On Fri, 5 Feb 2021 at 11:56, AllenJB <allen@allenjb.me.uk> wrote:
>
> > (And after checking the manual, I'd also note here that round() also
> > returns a float, so how exactly does your example here work? Is it only
> > OK to explictly cast a float that's the return value of a function? Or
> > only explictly cast a float if the fractional part is .0? Is that viabl=
e
> > given the "inaccuracy" of floats? Or would it be better for PHP to have
> > some non-range/accuracy-sensitive representation for integers (and
> > decimals) here?) (and now we're getting into "why are we still using
> > floating point math by default in 2021" territory, so I'll stop right
> here)
> >
>
> Floats (doubles) can accurately represent all integers up to 2=E2=81=B5=
=C2=B3, so there
> is no inaccuracy in this range; the result from round() or floor() could
> therefore be safely passed to (int) even if the cast operator checked for=
 a
> 0 fractional part, which is what I'm advocating for.
>
> There are legitimate cases for explicitly casting floats to int. For
> > example floor() outputs a float, but in the context of the domain I'm
> > working I might know that the result is never going to exceed a certain
> > value and want the result explicitly as an int.
>
>
> Perfect, so (int) floor() would work wonders for you, even with the stric=
t
> casting I'm talking about.
> And if the result does overflow an integer one day, I'm sure you'd be hap=
py
> to know it by getting an exception, rather than getting silently ZERO:
>
> echo (int) 1e60; // 0
>
> =E2=80=94 Benjamin
>

--000000000000b2ff3705ba9f6cd5--