Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113098
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>
In-Reply-To: <CA+p1FaaB-84BteyC6k0EMqUFwsDmozsAYys9ZYKsr34DBgQ7=Q@mail.gmail.com>
Date: Fri, 5 Feb 2021 19:24:06 -0500
Message-ID: <CAPKYkKxjG9fAzXtvZGud6XTWi-kRZCgt3r6TW6H_YjALorQ0-A@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, AllenJB <allen@allenjb.me.uk>, 
	"G. P. B." <george.banyard@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e1eeb905ba9ff424"
Subject: Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000e1eeb905ba9ff424
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 5, 2021 at 6:46 PM David Gebler <davidgebler@gmail.com> wrote:

> > 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() coul=
d
> > therefore be safely passed to (int) even if the cast operator checked f=
or
> a
> > 0 fractional part, which is what I'm advocating for.
>
> Generating a warning on explicit casts of (non-integer) floats to int wou=
ld
> 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 favou=
r
> a notice or deprecation, were it to be done at all).
>
>
A notice is fine, but PLEASE don't make it a warning. I'm in the process of
upgrading to 8.0 right now and I have so much code that works perfectly
fine but generates warnings (undefined array key for example - in 99.9% of
the cases where an array key is not defined, the null value that used to
result from that was perfectly fine).




>
> 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 on=
ly
> > > OK to explictly cast a float that's the return value of a function? O=
r
> > > only explictly cast a float if the fractional part is .0? Is that
> viable
> > > given the "inaccuracy" of floats? Or would it be better for PHP to ha=
ve
> > > 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() coul=
d
> > 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 certa=
in
> > > value and want the result explicitly as an int.
> >
> >
> > Perfect, so (int) floor() would work wonders for you, even with the
> strict
> > casting I'm talking about.
> > And if the result does overflow an integer one day, I'm sure you'd be
> happy
> > to know it by getting an exception, rather than getting silently ZERO:
> >
> > echo (int) 1e60; // 0
> >
> > =E2=80=94 Benjamin
> >
>


--=20
Chase Peeler
chasepeeler@gmail.com

--000000000000e1eeb905ba9ff424--