> 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....@gmail.com> wrote: > On Tue, Jun 2, 2020 at 5:10 PM Deleu <deleu...@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 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`. 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 given >> 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 through > to the end first. As far as I remember, it never did go to vote. > > Regards, > Nikita > -- Marco Aurélio Deleu
