# [RFC] Add "is_representable_as_float()" and "is_representable_as_int()" functions - Thread: https://externals.io/message/128296 - Original archive: https://news-web.php.net/php.internals/128296 - Started by Alexandre Daubois on 2025-07-29T12:52:04+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/128296.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #128296 — Alexandre Daubois — 2025-07-29T12:52:04+00:00 URL: https://externals.io/message/128296#128296 Hi internals, I would like to present the RFC to add the "is_representable_as_float()" and "is_representable_as_int()" functions. These functions provide developers with a way to check whether values can be losslessly converted between integer and floating-point representations. https://wiki.php.net/rfc/is-representable-as-float-int Best, Alexandre Daubois --- ## #128298 — Larry Garfield — 2025-07-29T16:04:06+00:00 URL: https://externals.io/message/128296#128298 · In reply to: #128296 > Hi internals, > > I would like to present the RFC to add the > "is_representable_as_float()" and "is_representable_as_int()" > functions. These functions provide developers with a way to check > whether values can be losslessly converted between integer and > floating-point representations. > > https://wiki.php.net/rfc/is-representable-as-float-int > > Best, > Alexandre Daubois This looks lovely. Since only int, float, and string can ever be true, does it make sense to type the function parameters as `int|float|string` rather than `mixed`, to automatically exclude arrays, objects, and null? (All of which would always be false.) (I could probably argue either way on it, but my first inclination is yes; push the initial validation upstream. You should always know if a variable is a primitive or not, at the very least.) --Larry Garfield --- ## #128300 — Hans Krentel — 2025-07-29T16:33:57+00:00 URL: https://externals.io/message/128296#128300 · In reply to: #128298 > > > […] > > This looks lovely. > > Since only int, float, and string can ever be true, does it make sense to type the function parameters as `int|float|string` rather than `mixed`, to automatically exclude arrays, objects, and null? (All of which would always be false.) There is prior art and also I'd personally recommend to abide to mixed to not open new gaps while closing older. php --rf is_countable Function [ function is_countable ] { - Parameters [1] { Parameter #0 [ mixed $value ] } - Return [ bool ] } > > (I could probably argue either way on it, but my first inclination is yes; push the initial validation upstream. You should always know if a variable is a primitive or not, at the very least.) IMHO this is not a validation but a test function. So if you think one should know, you probably should not need this function at all. Btw. is_primitive() was not a thing last time I looked. It would be great though to have the combined test of `is_scalar()` and `is_null()` in a single function call. This is perhaps something for the line-up. Just my 2 cents -- hakre --- ## #128304 — Thomas Bley — 2025-07-29T18:14:23+00:00 URL: https://externals.io/message/128296#128304 · In reply to: #128296 > Alexandre Daubois hat am 29.07.2025 14:52 CEST geschrieben: > > > Hi internals, > > I would like to present the RFC to add the > "is_representable_as_float()" and "is_representable_as_int()" > functions. These functions provide developers with a way to check > whether values can be losslessly converted between integer and > floating-point representations. > > https://wiki.php.net/rfc/is-representable-as-float-int > > Best, > Alexandre Daubois Thanks for the RFC. Since frameworks already have things like Strings::is_stringable() and Arr::arrayable(), I'd suggest to use is_floatable(), is_intable() or is_integerable(), etc. To me, this would also feel more consistent is `is_float()`, `is_int()`, etc. Regards Thomas --- ## #128309 — Rowan Tommins [IMSoP] — 2025-07-29T20:09:20+00:00 URL: https://externals.io/message/128296#128309 · In reply to: #128296 > https://wiki.php.net/rfc/is-representable-as-float-int In general, I think the proposed semantics make sense. I'm not sure about the names, but it's hard to think of a name that accurately describes what they do. > The value is a float that is not NaN or infinity It feels a bit odd to have a value where is_float($v) would be true, but is_representable_as_float($v) would be false. I'd be interested to understand the thinking behind this case. > Because of this, the function return value is also platform-dependent: > > is_representable_as_float(PHP_INT_MAX); // true on 64-bit platforms, false on 32-bit platforms This is, at best, misleading: it's not the function that's behaving differently, it's just being given different input. By that reasoning, `strlen()` is platform-dependent, because strlen(PHP_OS_FAMILY) returns 5 on Linux but 7 on Windows. As written, it's also the wrong way around: on a 32-bit platform, you are passing 2147483647, which is a "safe" value; on a 64-bit platform, you are passing 9223372036854775807, which is an odd number outside the "safe" range. is_representable_as_float(2147483647) === true on any platform is_representable_as_float(9223372036854775807) === false on a 64-bit build Confusingly, passing that absolute value on a 32-bit system will appear to return true, but that's because the loss of precision *has already happened* in the compiler: 9223372036854775807 will actually be compiled as 9223372036854775808.0, the nearest representable float. So again, it's actually running the same function with different input, not different behaviour inside the function. I suggest removing that sentence and example completely. There is nothing the function can or should do differently on different platforms. > Here also, the function return value is platform-dependent: > > is_representable_as_int(2**31); // true on 64-bit platforms, false on 32-bit platforms This one is fair enough, but I'd suggest tweaking the example slightly to avoid the same problem with different inputs: on a 64-bit build, 2**31 already is an integer, so it's trivially true. So either force a floating point input: is_representable_as_int(2.0**31); // true on 64-bit platforms, false on 32-bit platforms or, perhaps clearer, use an out-of-range string input: is_representable_as_int('2147483648'); // true on 64-bit platforms, false on 32-bit platforms Regards, -- Rowan Tommins [IMSoP] --- ## #128313 — Alexandre Daubois — 2025-07-30T06:40:52+00:00 URL: https://externals.io/message/128296#128313 · In reply to: #128300 > So if you think one should know, you probably should not need this function > at all. That's right. I'd also say that since the aim is to have better interoperability between systems, mixed seems judicious. For example, a bool or a null can occur. > Btw. is_primitive() was not a thing last time I looked. It would be great > though to have the combined test of `is_scalar()` and `is_null()` in a single > function call. I like the idea. Would it have its place in this RFC? I feel like it could with a separate vote, but maybe this would require its own RFC. --- ## #128314 — Alexandre Daubois — 2025-07-30T06:43:46+00:00 URL: https://externals.io/message/128296#128314 · In reply to: #128304 > Since frameworks already have things like Strings::is_stringable() and Arr::arrayable(), I'd suggest to use is_floatable(), is_intable() or is_integerable(), etc. > To me, this would also feel more consistent is `is_float()`, `is_int()`, etc. I get what you mean. Naming is definitely challenging here. However, with alternatives like "is_floatable()", I'm afraid that it is not clear enough that there's a potential loss of precision. I would personally feel that "is_floatable()" would mean "can this be cast to float?" without further "limitation". Best, Alexandre Daubois --- ## #128315 — Alexandre Daubois — 2025-07-30T06:54:11+00:00 URL: https://externals.io/message/128296#128315 · In reply to: #128309 > > […] > > It feels a bit odd to have a value where is_float($v) would be true, but is_representable_as_float($v) would be false. I'd be interested to understand the thinking behind this case. As the strings “INF” and “NAN” can't be cast as floats directly, I think it's safer to return false on these extreme values. See https://3v4l.org/TabMK#vnull for the cast example. > I suggest removing that sentence and example completely. There is nothing the function can or should do differently on different platforms. You are right, it's misleading. I'll update the RFC accordingly. > This one is fair enough, but I'd suggest tweaking the example slightly to avoid the same problem with different inputs: on a 64-bit build, 2**31 already is an integer, so it's trivially true. So either force a floating point input: > > is_representable_as_int(2.0**31); // true on 64-bit platforms, false on 32-bit platforms > > or, perhaps clearer, use an out-of-range string input: > > is_representable_as_int('2147483648'); // true on 64-bit platforms, false on 32-bit platforms I'll also update accordingly. Thank you! Best, Alexandre Daubois --- ## #128316 — Rowan Tommins [IMSoP] — 2025-07-30T07:30:49+00:00 URL: https://externals.io/message/128296#128316 · In reply to: #128315 > > […] > >As the strings “INF” and “NAN” can't be cast as floats directly, I >think it's safer to return false on these extreme values. See >https://3v4l.org/TabMK#vnull for the cast example. The sentence I quoted isn't talking about string inputs, it's talking about values that are already floats. The fact that you can't create one from a string cast doesn't seem relevant, if you have in fact created one some other way. https://3v4l.org/efucd Rowan Tommins [IMSoP] --- ## #128317 — Alexandre Daubois — 2025-07-30T07:45:10+00:00 URL: https://externals.io/message/128296#128317 · In reply to: #128316 > The sentence I quoted isn't talking about string inputs, it's talking about values that are already floats. The fact that you can't create one from a string cast doesn't seem relevant, if you have in fact created one some other way. Ah yes, my bad. I just updated the RFC page with your previous comments. Also, I changed examples of `INF` and `NAN` to return true with "is_representable_as_float()". The example of the float overflowing to infinity (2**1024) is also updated to return true. Best, Alexandre Daubois --- ## #128318 — Alexandre Daubois — 2025-07-30T11:27:35+00:00 URL: https://externals.io/message/128296#128318 · In reply to: #128296 > I would like to present the RFC to add the > "is_representable_as_float()" and "is_representable_as_int()" > functions. These functions provide developers with a way to check > whether values can be losslessly converted between integer and > floating-point representations. > > https://wiki.php.net/rfc/is-representable-as-float-int The RFC is now updated with the draft implementation of the current state of the document. The draft PR is available at https://github.com/php/php-src/pull/19308. Best, Alexandre Daubois --- ## #128365 — Hans Krentel — 2025-08-02T05:05:55+00:00 URL: https://externals.io/message/128296#128365 · In reply to: #128313 > > […] great > > […] single > > […] > > I like the idea. Thanks. > Would it have its place in this RFC? I feel like it > could with a separate vote, but maybe this would require its own RFC. Nah, at least me would not put it in there. But maybe after that RFC is done, we probably should revisit the idea. With representable as float, is_primitive() could get even more clarity apart from the ordinary type test, and probably buy into the commons mirrored in the rel. recent JSON Path Internet-RFC JSON value mindset, which was with an early PHP implementation since it's beginning ca. 20 years or so ago. If we're able to capture such longtime wisdom within the language it would be a testament to software engineering in web/phptech and could become a beautiful example of unveiling true ergonomics. My 2 cents -- hakre --- ## #128449 — Alexandre Daubois — 2025-08-12T07:17:06+00:00 URL: https://externals.io/message/128296#128449 · In reply to: #128296 Hi Internals, This is a friendly reminder that this RFC has been under discussion for a couple of weeks. Today marks two weeks since the announcement of this RFC. After some uneventful discussions, I am wondering how we should proceed now. Would you like to continue the discussion, or perhaps initiate a vote? With the feature freeze imminent (tomorrow, if I'm right?), I am not sure that the RFC would be implemented in 8.5 if it is accepted given that the vote lasts at least a week. What's the best way to proceed? The implementation is still available at https://github.com/php/php-src/pull/19308. Best, Alexandre Daubois Le mar. 29 juil. 2025 à 14:52, Alexandre Daubois a écrit : > > Hi internals, > > I would like to present the RFC to add the > "is_representable_as_float()" and "is_representable_as_int()" > functions. These functions provide developers with a way to check > whether values can be losslessly converted between integer and > floating-point representations. > > https://wiki.php.net/rfc/is-representable-as-float-int > > Best, > Alexandre Daubois --- ## #128451 — Daniel Scherzer — 2025-08-12T11:39:55+00:00 URL: https://externals.io/message/128296#128451 · In reply to: #128449 On Tue, Aug 12, 2025 at 4:35 AM Alexandre Daubois < alex.daubois+php@gmail.com> wrote: > Hi Internals, > > This is a friendly reminder that this RFC has been under discussion > for a couple of weeks. Today marks two weeks since the announcement of > this RFC. After some uneventful discussions, I am wondering how we > should proceed now. Would you like to continue the discussion, or > perhaps initiate a vote? With the feature freeze imminent (tomorrow, > if I'm right?), I am not sure that the RFC would be implemented in 8.5 > if it is accepted given that the vote lasts at least a week. > It is too late for RFCs to target PHP 8.5; they needed to finish voting today in order to be included. Given that this cannot be included in PHP 8.5, I would suggest waiting at least a few weeks before starting the vote - some people (myself definitely included) may not have had a chance to review the RFC because of the work surrounding trying to finalize and implement things before the PHP 8.5 freeze. -Daniel --- ## #128454 — Alexandre Daubois — 2025-08-12T13:07:33+00:00 URL: https://externals.io/message/128296#128454 · In reply to: #128451 > Given that this cannot be included in PHP 8.5, I would suggest waiting at least a few weeks before starting the vote - some people (myself definitely included) may not have had a chance to review the RFC because of the work surrounding trying to finalize and implement things before the PHP 8.5 freeze. Tim kindly told me so as well. Let's wait a few more weeks so everyone interested can get into the discussion. Good luck with the release! Best, Alexandre Daubois --- ## #128559 — tim@bastelstu.be — 2025-08-26T14:30:19+00:00 URL: https://externals.io/message/128296#128559 · In reply to: #128296 Hi Am 2025-07-29 14:52, schrieb Alexandre Daubois: > I would like to present the RFC to add the > "is_representable_as_float()" and "is_representable_as_int()" > functions. These functions provide developers with a way to check > whether values can be losslessly converted between integer and > floating-point representations. > > https://wiki.php.net/rfc/is-representable-as-float-int Thank you for the RFC. I fundamentally disagree with that there is a single, obvious and meaningful definition for `is_representable_as_float()`. In fact right from the beginning of the “Proposal” section: > The value is a string that represents a valid floating-point number > (e.g., “3.14”, “1e10”, “-0.001”) 3.14 is not exactly representable as a IEEE-754 double-precision floating point number. The two nearest representable values are 3.14000000000000012434 (this one is the nearest) and 3.13999999999999968026. Returning `true` for `is_representable_as_float("3.14")` is therefore wrong to me. The introduction is also wrong. JSON does *not* specify that numbers must be representable as IEEE-754 double-precision floating point numbers. The grammar for “Numbers” is independent of any particular representation and transmitting numbers > 2^53 is perfectly fine if every system involved can deal with 64 bit integers. Also just casting a non-representable value to string will break any consumers that are strongly typed and expect a number rather than a string. So that doesn't make sense to me either. I also question how meaningful it is knowing that a given number is exactly representable as a float when (e.g. a power of two) when almost any operation on it will incur implicit rounding. For `is_representable_as_int()` finding a reasonable definition is much easier, but I don't think I've ever had a use case where I needed to know whether a non-integer value is exactly representable as an int. Long story short: What actual real-world problem does this RFC attempt to solve? The list in the “Introduction” section is not particularly meaningful with regard to the real world and the JSON example is wrong as outlined above. Best regards Tim Düsterhus --- ## #128561 — Larry Garfield — 2025-08-26T14:48:40+00:00 URL: https://externals.io/message/128296#128561 · In reply to: #128559 > For `is_representable_as_int()` finding a reasonable definition is much > easier, but I don't think I've ever had a use case where I needed to > know whether a non-integer value is exactly representable as an int. > > Long story short: What actual real-world problem does this RFC attempt > to solve? The list in the “Introduction” section is not particularly > meaningful with regard to the real world and the JSON example is wrong > as outlined above. > > Best regards > Tim Düsterhus I have multiple times just recently had need of "I have a numeric string, should I cast it to an int or a float?", for which an is_representable_as_int() function (or similar) would be quite helpful, and neater than the messy solution I usually use. I haven't had a use for is_representable_as_float() that I can recall. --Larry Garfield --- ## #128562 — Alexandre Daubois — 2025-08-26T17:14:43+00:00 URL: https://externals.io/message/128296#128562 · In reply to: #128559 Hi Tim, Thank you for your thorough review. > 3.14 is not exactly representable as a IEEE-754 double-precision > floating point number. The two nearest representable values are > 3.14000000000000012434 (this one is the nearest) and > 3.13999999999999968026. Returning `true` for > `is_representable_as_float("3.14")` is therefore wrong to me. You're right about mathematical precision. Perhaps the function name is misleading. What the function actually should check is whether a string > float > string roundtrip preserves the value as PHP developers would expect it, not whether it's mathematically exactly representable in IEEE-754. Maybe a more accurate name would better reflect this behavior. Naming is super hard again here. The goal is pragmatic: "will this value survive a type conversion cycle without surprising changes?" > The introduction is also wrong. JSON does *not* specify that numbers > must be representable as IEEE-754 double-precision floating point > numbers. The grammar for “Numbers” is independent of any particular > representation and transmitting numbers > 2^53 is perfectly fine if > every system involved can deal with 64 bit integers. Also just casting a > non-representable value to string will break any consumers that are > strongly typed and expect a number rather than a string. So that doesn't > make sense to me either. Fair point about the JSON specification itself. However, the real-world issue is JavaScript's Number type limitation (safe integers only up to 2^53). The fact that it is fine if "every system involved can deal with 64 bits integers" is true, but nothing guarantees that all systems involved are systematically x64. Many PHP applications need to communicate with JavaScript frontends, and knowing when a numeric ID exceeds JavaScript's safe integer range would improve interoperability. > I also question how meaningful it is knowing that a given number is > exactly representable as a float when (e.g. a power of two) when almost > any operation on it will incur implicit rounding. To me, the code snippet in the RFC introduction illustrates a valid use-case of a numeric identifier that could be dangerous to cast. > Long story short: What actual real-world problem does this RFC attempt > to solve? The list in the “Introduction” section is not particularly > meaningful with regard to the real world and the JSON example is wrong > as outlined above. A few examples, as interoperability between with JSON/JavaScript is the main point here, could be: - Snowflake IDs - High-precision timestamps in microseconds - Large auto-increment IDs in mature applications Hope I addressed your concerns. Best, Alexandre Daubois --- ## #128563 — Alexandre Daubois — 2025-08-26T17:16:38+00:00 URL: https://externals.io/message/128296#128563 · In reply to: #128561 Hi Larry, > I have multiple times just recently had need of "I have a numeric string, should I cast it to an int or a float?", for which an is_representable_as_int() function (or similar) would be quite helpful, and neater than the messy solution I usually use. Indeed, this is a nice use case! This is also something I encountered a few times. > I haven't had a use for is_representable_as_float() that I can recall. Just thinking out loud, if this RFC ever makes it to the voting phase, maybe we should have two separate votes, one for each function. Best, Alexandre Daubois --- ## #128564 — tim@bastelstu.be — 2025-08-26T18:23:20+00:00 URL: https://externals.io/message/128296#128564 · In reply to: #128562 Hi > > […] > > You're right about mathematical precision. Perhaps the function name > is misleading. What the function actually should check is whether a > string > float > string roundtrip preserves the value as PHP > developers would expect it, not whether it's mathematically exactly > representable in IEEE-754. > > Maybe a more accurate name would better reflect this behavior. Naming > is super hard again here. The goal is pragmatic: "will this value > survive a type conversion cycle without surprising changes?" "Surprising changes" is not a meaningful term. Keep in mind that the behavior of the function will need to be accurately documented and that folks need something to work with to determine whether a report is valid or not when bugs in the function get reported - which will inevitably happen. In fact to use one of the examples for the RFC: 1e10 does not roundtrip. php > var_dump((string)(float)"1e10"); string(11) "10000000000" "1e10" clearly is different than "10000000000". Generally speaking, I'm also not sure if “printing raw floats” is a use-case we should encourage. Instead almost any application will need to format a number for a specific use-case. Formatting numbers for human consumption [1] has different requirements compared to formatting numbers for programmatic consumption. Also note that the stringification of floats unfortunately is controlled by INI settings `precision` and `serialize_precision` which adds additional complexity. [1] My recommendation is using ext/intl's NumberFormatter: https://www.php.net/manual/en/class.numberformatter.php > need to communicate with JavaScript frontends, and knowing when a > numeric ID exceeds JavaScript's safe integer range would improve > interoperability. For *this* use case we would not need a complex function. A simple constant FLOAT_INTEGER_RANGE or similar would be sufficient. > > […] > > To me, the code snippet in the RFC introduction illustrates a valid > use-case of a numeric identifier that could be dangerous to cast. Please note my remark regarding “strongly typed consumers”. Magically switching from JSON's number type to JSON's string type for specific values is needlessly increasing complexity for everyone who interacts with the JSON payload, particularly for compiled languages. If you know that the consumers of your JSON are having troubles with certain numbers you emit and you want to emit strings for those kind of numbers instead, then you should just emit strings all the time. In fact I'd argue that using JSON's number type for numeric IDs is wrong, just like treating phone numbers or zip codes as numbers is wrong. If it's not reasonable to do math on a value then it's likely not a number, but instead a numeric string. > > […] > > A few examples, as interoperability between with JSON/JavaScript is > the main point here, could be: > > - Snowflake IDs At the application boundary these should just be a string, since consumers of your API should treat IDs as opaque values, unless you want to give some guarantees (e.g. rough ordering, which would still work with strings). > - High-precision timestamps in microseconds Using a number is reasonable here, but see above regarding “magically switching types”. (From my experience timestamps are generally represented as ISO-8601 strings in JSON APIs anyways) > - Large auto-increment IDs in mature applications Same as snowflakes. > Hope I addressed your concerns. I'm afraid not. Best regards Tim Düsterhus --- ## #128565 — Rob Landers — 2025-08-26T18:33:00+00:00 URL: https://externals.io/message/128296#128565 · In reply to: #128564 > Hi > > > > […] > > "Surprising changes" is not a meaningful term. Keep in mind that the > behavior of the function will need to be accurately documented and that > folks need something to work with to determine whether a report is valid > or not when bugs in the function get reported - which will inevitably > happen. > > In fact to use one of the examples for the RFC: 1e10 does not roundtrip. > > php > var_dump((string)(float)"1e10"); > string(11) "10000000000" > > "1e10" clearly is different than "10000000000". > > Generally speaking, I'm also not sure if “printing raw floats” is a > use-case we should encourage. Instead almost any application will need > to format a number for a specific use-case. Formatting numbers for human > consumption [1] has different requirements compared to formatting > numbers for programmatic consumption. Indeed. In some parts of the world, 1.000,01 is interpreted as 1000.01 in computers. That format also doesn’t roundtrip but is a valid numeric string, depending on locale. — Rob --- ## #128566 — tim@bastelstu.be — 2025-08-26T18:36:01+00:00 URL: https://externals.io/message/128296#128566 · In reply to: #128561 Hi > I have multiple times just recently had need of "I have a numeric string, should I cast it to an int or a float?", for which an is_representable_as_int() function (or similar) would be quite helpful, and neater than the messy solution I usually use. It would've been nice to know what that use-case is, rather than just knowing that you had that use-case. I'm having a hard time thinking of something where I don't a-priori know what type I expect to get and would need to inspect the value to make a decision. I see how having a function that safely coerces a string into an int, returning null if coercion fails, basically `intval()` with better error handling and taking only `string`s, could be useful, but that's not what is being asked here. Best regards Tim Düsterhus --- ## #128567 — Larry Garfield — 2025-08-26T19:36:05+00:00 URL: https://externals.io/message/128296#128567 · In reply to: #128566 > Hi > > > > […] > > It would've been nice to know what that use-case is, rather than just > knowing that you had that use-case. > > I'm having a hard time thinking of something where I don't a-priori know > what type I expect to get and would need to inspect the value to make a > decision. > > I see how having a function that safely coerces a string into an int, > returning null if coercion fails, basically `intval()` with better error > handling and taking only `string`s, could be useful, but that's not what > is being asked here. > > Best regards > Tim Düsterhus When doing generic serialization, the input is often always-strings (eg, environment variables, HTTP Query parameters, etc.) When doing generic code (not type generics, but "works on anything" kind of generic), I often have to resort to this: https://github.com/Crell/EnvMapper/blob/master/src/EnvMapper.php#L88 Which gets the job done, but feels ugly to me. Even if I know what the target type is, I still need to ask the question "so does this string match the target type?" https://github.com/Crell/Carica/blob/master/src/Middleware/NormalizeArgumentTypesMiddleware.php#L73 "I have a string, the parameter wants an int, is that even possible?" Being able to replace that `floor()` nonsense with is_integerable() (by whatever name) would make my life a lot easier. For float, `is_numeric()` is already sufficient for my purposes. I just need to be able to differentiate between "3" and "3.14" to cast to the correct type. --Larry Garfield --- ## #128568 — Nicolas Grekas — 2025-08-26T20:38:59+00:00 URL: https://externals.io/message/128296#128568 · In reply to: #128567 Le mar. 26 août 2025 à 21:38, Larry Garfield a écrit : > > > […] > string, should I cast it to an int or a float?", for which an > is_representable_as_int() function (or similar) would be quite helpful, and > neater than the messy solution I usually use. > > […] > > When doing generic serialization, the input is often always-strings (eg, > environment variables, HTTP Query parameters, etc.) When doing generic > code (not type generics, but "works on anything" kind of generic), I often > have to resort to this: > > https://github.com/Crell/EnvMapper/blob/master/src/EnvMapper.php#L88 > > Which gets the job done, but feels ugly to me. > > Even if I know what the target type is, I still need to ask the question > "so does this string match the target type?" > > > https://github.com/Crell/Carica/blob/master/src/Middleware/NormalizeArgumentTypesMiddleware.php#L73 > > "I have a string, the parameter wants an int, is that even possible?" > Being able to replace that `floor()` nonsense with is_integerable() (by > whatever name) would make my life a lot easier. > > For float, `is_numeric()` is already sufficient for my purposes. I just > need to be able to differentiate between "3" and "3.14" to cast to the > correct type. > > --Larry Garfield > Why not just 0 + $theValue? Then the engine will decide. No? --- ## #128569 — Rob Landers — 2025-08-27T07:50:14+00:00 URL: https://externals.io/message/128296#128569 · In reply to: #128567 > > > […] > > When doing generic serialization, the input is often always-strings (eg, environment variables, HTTP Query parameters, etc.) When doing generic code (not type generics, but "works on anything" kind of generic), I often have to resort to this: > > https://github.com/Crell/EnvMapper/blob/master/src/EnvMapper.php#L88 > > Which gets the job done, but feels ugly to me. > > Even if I know what the target type is, I still need to ask the question "so does this string match the target type?" > > https://github.com/Crell/Carica/blob/master/src/Middleware/NormalizeArgumentTypesMiddleware.php#L73 > > "I have a string, the parameter wants an int, is that even possible?" Being able to replace that `floor()` nonsense with is_integerable() (by whatever name) would make my life a lot easier. > > For float, `is_numeric()` is already sufficient for my purposes. I just need to be able to differentiate between "3" and "3.14" to cast to the correct type. > > --Larry Garfield > Isn't this the entire use-case of type coercion? — Rob --- Next page: https://externals.io/message/128296.md?page=2