Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110350
MIME-Version: 1.0
References: <CADK1yX+HbuTP-81ABdANHZidLm7zorM9n-7Q6NmP_aDDv_R+8Q@mail.gmail.com>
 <CAF+90c-P_Djx6MWt=bJFUrGcC74N3xUEP+qjQVDGyrfEAG02Yw@mail.gmail.com>
In-Reply-To: <CAF+90c-P_Djx6MWt=bJFUrGcC74N3xUEP+qjQVDGyrfEAG02Yw@mail.gmail.com>
Date: Wed, 3 Jun 2020 14:00:04 +0200
Message-ID: <CADK1yXJ_jVgU5_QPRCyKK9tSqpYxGVvihVn95Vs=1Y+aM09xbA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000df62a005a72cc68b"
Subject: Re: [PHP-DEV] Numeric Type
From: deleugyn@gmail.com (Deleu)

--000000000000df62a005a72cc68b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

  > To clarify, what are the semantics of numeric? If you have a numeric
argument and "42" is passed in, will it be converted to int(42), or will it
remain as "42" (as is_numeric("42") returns true)?

I imagine it would remain as "42" since implicit casting is the source of
some of the problems with the PHP type system. To be honest, I'd be fine
with either, but I imagine that advocating for yet another implicit casting
on a specific type-hint would just lead to more edge-cases and not be
treated as other types are.

> From your description, it seems pretty clear that you really want the
nullable cast instead and "numeric" is just a workaround that makes a
specific case tenable. That does not seem like a good position to argue
from. I think it would make more sense to see the nullable cast RFC through
to the end first. As far as I remember, it never did go to vote.

There's no denying this, however when I looked at the discussion, I got the
feeling that it may not have move forward due to the arguments against it.
The reason I decided to send this email even though it doesn't seem like a
good arguing position is the fact that when I looked back at all the times
I wanted nullable casting they were all `int|string` scenarios. If a cheap
feature such as `numeric` type-hint can solve most use cases, I'd be more
than willing to deal with the custom code I will continue to have to write
for cases that are not `int|string`.

I don't know if there will ever be an interest in deprecating "42" + 10,
which correctly results in 52. If there is, I can understand how the
development of this feature might be counter-productive. Other than that, I
think the benefit of this feature outweight the cost specially when looked
at it from the `is_numeric` perspective, which is an existing behavior.

On Wed, Jun 3, 2020 at 12:26 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jun 2, 2020 at 5:10 PM Deleu <deleugyn@gmail.com> wrote:
>
>> Hello Internals,
>>
>> I'd like to know what would be people's feelings towards having a
>> `numeric`
>> type. I remember reading the nullable casting RFC (
>> https://wiki.php.net/rfc/nullable-casting) and it's discussion (
>> https://externals.io/message/105122). Although I would very much prefer
>> to
>> have nullable casting, it seems to be a bit controversial and perhaps
>> Numeric Type could be a middle ground solution.
>>
>> The primary intent would be to safely pass around input that usually com=
es
>> from HTTP, CI or Database. Whenever interacting with these data provider=
s,
>> 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`. Similarly, I
>> think we could benefit from having `foo(?numeric $value)` as a type-safe
>> mechanism to transfer data around without having to forcefully check for
>> numeric value before casting. If we simply `(int) $value`, we may end up
>> casting `null` to `0`. Type-hitting `?numeric` could be a compromise.
>>
>> ```
>> foo(?int $number);
>>
>> foo($_GET['param']); // TypeError: foo() expects int or null, string giv=
en
>> foo((int) $_GET['param']); // null becomes 0
>> foo($_GET['param'] ? (int) $_GET['param'] : null); // expected behavior
>>
>> bar(?numeric $number);
>> bar($_GET['param']);  // would work with any value that passes
>> is_numeric()
>> ```
>>
>> I also think this approach have a benefit over PHP 8 Union Type
>> (int|string) because is_numeric() does not return true for string values
>> and for consistency the `numeric` type-hint would behave similarly.
>>
>
> To clarify, what are the semantics of numeric? If you have a numeric
> argument and "42" is passed in, will it be converted to int(42), or will =
it
> remain as "42" (as is_numeric("42") returns true)?
>
> From your description, it seems pretty clear that you really want the
> nullable cast instead and "numeric" is just a workaround that makes a
> specific case tenable. That does not seem like a good position to argue
> from. I think it would make more sense to see the nullable cast RFC throu=
gh
> to the end first. As far as I remember, it never did go to vote.
>
> Regards,
> Nikita
>


--=20
Marco Aur=C3=A9lio Deleu

--000000000000df62a005a72cc68b--