Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113087
MIME-Version: 1.0
References: <CAFPFaMKDELHFr44kOncQWeCi7KZUL7XLNL2JyvJvmNLTgjDBOQ@mail.gmail.com>
 <CAG9XoMTc-7axJBQu2Skt6ng+6pU4o7gsXy+J47C5EeXyZLmZ=A@mail.gmail.com>
In-Reply-To: <CAG9XoMTc-7axJBQu2Skt6ng+6pU4o7gsXy+J47C5EeXyZLmZ=A@mail.gmail.com>
Date: Fri, 5 Feb 2021 10:40:15 +0000
Message-ID: <CAFPFaMJPptonBSRVCv2Y8_Z61S1JVQ5LhKc=eQ=bLWR2FfL+Yg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, davidgebler@gmail.com
Content-Type: multipart/alternative; boundary="000000000000b5b97105ba947260"
Subject: Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
From: george.banyard@gmail.com ("G. P. B.")

--000000000000b5b97105ba947260
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 4 Feb 2021 at 17:55, Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> On Thu, 4 Feb 2021 at 17:05, G. P. B. <george.banyard@gmail.com> wrote:
>
>> Greetings internal,
>>
>> I'm proposing a new RFC which would warn when an implicit conversion
>> from float to int occurs.
>>
>> The draft is currently located on GitHub:
>> https://github.com/Girgias/float-int-warning/
>> for ease of commenting/providing changes to it.
>>
>> The official discussion phase wouldn't start before I convert it to
>> docwiki
>> and
>> post it on the wiki, something I'm planning to do next week.
>>
>> Any feedback is appreciated.
>>
>> Best regards,
>>
>> George P. Banyard
>>
>
> Hi George,
>
> Thank you for this proposal, I'm all for it, though I'd go one step
> further, and actually issue a warning during explicit casting as well:
>
> (int) 3.5; // E_WARNING
> (int) round(3.5); // OK
>
> In my experience, it's better to be explicit about your intent, so forcin=
g
> the user to round() before casting when the float has a fractional part i=
s
> OK to me.
> This would help prevent weird silent conversions such as when you cast to
> (int) from user input:
>
> $age =3D $_GET['age']; // '25.75'
> $x =3D (int) $foo; // I'd expect a warning, not a silent conversion to 25
>
> =E2=80=94 Benjamin
>

As Rowan said explicit casts are already very fuzzy and should be handled
globally, although I don't agree that they should be changed.
An explicit cast is a choice to *force* the value to a given type, and many
cases are somewhat reasonable
(e.g. (array) 5 giving array(1) { [0]=3D> int(5) }), there are IMHO only tw=
o
types of blatant bogus type casts which are array being casted to string,
and array/objects being casted to int/float.

And by the looks of it these casts were added *because* of the usage of the
strict_type declare, which encourages the usage of explicit cast despite
them leading to *less* type safe code.

This proposal is one of the stepping stones needed to make the strict_type
declare obsolete by converging the behaviour of the coercive typing mode to
the strict type one.
The more I think about it, the more I think it's just a bandaid on some of
the suboptimal behaviour PHP traditionally had.
However, many of these have been somewhat fixed in PHP 8, the two major
ones are systematic TypeErrors for internal functions and the other one is
a saner definition of what a numeric string is.
There are currently 3 remaining reasons, at least from my
perspective/knowledge, as to why the strict_type mode is still needed in
PHP 8:
  - Internal functions being implicitly nullable, something being
deprecated with Nikita's RFC [1] which is currently passing with flying
colours.
  - Implicit float to int conversions, which this RFC is trying to address
  - Implicit boolean to scalar conversions, something I want to look into
afterwards but it has a larger surface area which needs to be considered

All other implicit conversions, which currently do not warn or error, are
reasonable from my PoV, and if a codebase wants to adhere to strict type
safety rules there are enough different static analysers nowadays to
achieve this, as strict_types does *not* achieve this but provides a false
sense that it does.

On Thu, 4 Feb 2021 at 19:43, David Gebler <davidgebler@gmail.com> wrote:

> On Thu, Feb 4, 2021 at 7:22 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
> > On Thu, Feb 4, 2021, at 12:06 PM, David Gebler wrote:
> > > I get the idea behind your proposal, but equally I'm not convinced th=
is
> > is
> > > comparable to numeric vs non-numeric or malformed/partially numeric
> > > strings. There isn't any value of the string "foobar" which makes sen=
se
> > as
> > > an integer. But there is a value for a float which makes sense as an
> > > integer; the integral part. In the float 3.81232 the integral portion=
 3
> > is
> > > completely unambiguous. It's not like it would make just as much sens=
e
> to
> > > interpret it as any other arbitrary integer value.
> >
> > Except that example is ambiguous.  Specifically, which is more logical,
> to
> > truncate it to 3 or round it up to 4?  It probably depends heavily on
> your
> > context.  Implicitly doing one or the other can result in surprises.
>
> I disagree this is ambiguous. The integral portion of a float is what it
> is, any notion of rounding it up is no more relevant here than multiplyin=
g
> by it 20, calculating it's sin value or anything else you can do with a
> number. These are operations you explicitly choose to perform on a scalar=
.
>

If you don't care that it has a factional part, then yes it is unambiguous
(which is kind of debatable with the fact floating numbers can be slightly
below the integer value which it should represent when operations have been
done to them).
However, if you don't care then an explicit cast is totally in order to
signal this, as IMHO most people want to have some sort of indication that
they are receiving a float instead of an integer as that can mean there is
an issue prior to receiving it,
as it may need some further processing (be that rounding, increasing
validation on the value received, etc.).


Considering what my long term goal is with this proposal I think I will
change this to a deprecation and write an annexe document which I can refer
to.

The feedback so far has thus been productive.

Best regards,

George P. Banyard

--000000000000b5b97105ba947260--