Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110341
MIME-Version: 1.0
References: <CADK1yX+HbuTP-81ABdANHZidLm7zorM9n-7Q6NmP_aDDv_R+8Q@mail.gmail.com>
 <CALKiJKr1bM32aV_zm9BcPnwjZC8pbSFyr6citDApHkp6oHw04A@mail.gmail.com>
In-Reply-To: <CALKiJKr1bM32aV_zm9BcPnwjZC8pbSFyr6citDApHkp6oHw04A@mail.gmail.com>
Date: Wed, 3 Jun 2020 10:50:23 +0200
Message-ID: <CADK1yXLJ0+YxGDscVq1nUpSRkgmV+Ej9=vi9UW__0KDy7AxNSw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000738e6605a72a2060"
Subject: Re: [PHP-DEV] Numeric Type
From: deleugyn@gmail.com (Deleu)

--000000000000738e6605a72a2060
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Rowan,

Although I understand your concerns, I wouldn't consider them a roadblock
for this feature. My rationale is that `is_numeric` has been with PHP for
so long that I don't think we would ever be able to have a `numeric`
type-hint that doesn't align with it, which imho means we either have it or
we don't, a 3rd option where a possible type-hint that is inconsistent with
the function seems worse than not having it. I fully agree with your
concerns that it might not fully represent what the developer wants, but I
would make a judgement call when using it the same way developers have to
make a judgement call when using `is_numeric`. It might allow far more than
you want, but there seems to be enough use-case that it fits where the
downside is negligible or even insignificant.
My point is that I don't look at the language validation to protect my code
against unexpected values and I can setup validation to deal with that.
What complicates things is that I want to avoid having a force-cast which
is not safe for my usage because I want to preserve `null` while not having
to disable strict_types.


On Tue, Jun 2, 2020 at 5:47 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> Hi Marco,
>
> On Tue, 2 Jun 2020 at 16:10, Deleu <deleugyn@gmail.com> wrote:
>
> >
> > The primary intent would be to safely pass around input that usually
> comes
> > from HTTP, CI or Database. Whenever interacting with these data
> providers,
> > string is a common format. `is_int` will not return true for integer
> values
> > that are string, instead we need to rely on `is_numeric`.
> >
>
>
> The problem with is_numeric() is that it uses an extremely broad definiti=
on
> of "numeric", which is not often what you actually want - for instance,
> is_numeric("-2.56E-90") returns true.
>
> The case I frequently see is much stricter: the variable should either be
> an integer, or a string representation of an integer. Whenever this comes
> up, I struggle for what the correct check actually is:
>
> * is_int($x) won't accept any strings
> * is_numeric($x) will accept far too much
> * an int type annotation with strict_types=3D0 is similar to is_numeric; =
in
> strict_types=3D1 it's the same as is_int
> * (int)$x will never give an error (meaning it's oddly easy to accidental=
ly
> _suppress_ errors by trying to make code run under strict_types=3D1)
> * (int)$x !=3D 0 is sometimes good enough, as long as zero is not a valid
> value (if you use this when accepting Unix timestamps, for instance, Jan
> 1st 1970 is going to be rejected!)
> * ctype_digit( (string)$x ) is confusing to read (the cast is required to
> accept actual integers, and the name is odd out of its intended context);
> it will also reject any negative numbers, which may or may not be desirab=
le
>
> The only suitable built-in function I'm aware of is filter_var, which has=
 a
> pretty horrible API:
>
> if ( filter_var($x, FILTER_VALIDATE_INT) !=3D=3D false ) ...
>
> In the common case that you want to cast the variable to int on success (=
to
> pass to a strictly typed function), you would need to do something like
> this:
>
> $x =3D filter_var($x, FILTER_VALIDATE_INT);
> if ( $x =3D=3D=3D false ) {
>     throw new TypeError;
> }
>
> I would love to see the language have a built-in short-hand for that, in
> the form of some kind of "strict cast", e.g.:
>
> $x =3D (int!)$x;
>
> or:
>
> $x =3D (strict int)$x;
>
> Once converted in that way, you could safely pass to a parameter marked i=
nt
> in strict mode, so wouldn't need a new pseudo-type.
>
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>


--=20
Marco Aur=C3=A9lio Deleu

--000000000000738e6605a72a2060--