e to
introduce < and > modifiers and deprecate some letters, if I get it
right?
— Alexandre Daubois
ifferences. However, I may
reword it as I realized that the RFC states that differences appear
with specific endianness letters (and you showed that it's not true).
There are many differences when we're not talking about endian
specific formats actually.
— Alexandre Daubois
be really interested if someone comes up with
an RFC for this feature!
— Alexandre Daubois
change.
Here is the link to the RFC:
https://wiki.php.net/rfc/pack-unpack-endianness-signed-integers-support
Best,
Alexandre Daubois
Contributing to php-src with features and bug fixes
Hi Internals,
Le jeu. 4 sept. 2025 à 10:22, Alexandre Daubois
a écrit :
>
> Contributing to php-src with features and bug fixes
The page to request the VCS account states that we may add more
information to apply, but it doesn’t seem there’s a field for this in
the form, so this is a fol
s
everyone and every situation. Based on this thread feedback and
suggestions, the use cases seem niche, for is_representable_as_float()
at least.
Best,
Alexandre Daubois
[1] https://externals.io/message/128032
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
t 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
shortly after 6th September.
>
> Thanks
> James
Hi James,
Really nice, congrats on bringing the tool to the "finish line"!
Best,
Alexandre Daubois
s 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
p-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
precation warnings in the engine and prepare an RFC if required.
Unless the change is actually uncontroversial? It seems to me, but I'm
looking forward to your thoughts and feedback.
Best,
Alexandre Daubois
> Thanks for the suggestions. Maybe add a new function func_get_named_args():
> array, would be a good extension to the named arguments rfc.
I even wonder if this would require a RFC? If not, this is something
that may be proposed for PHP 8.5.
Best,
Alexandre Daubois
> Of course, empty catch blocks are bad practice in most cases. But this
> particular proposal is not intended to encourage these bad practices. I'm
> just suggesting that you don't have to write an extra boiler plate at the
> syntax level in situations where it's necessary.
>From what I can te
ng-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
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
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-
ing 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
> 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
resentations.
https://wiki.php.net/rfc/is-representable-as-float-int
Best,
Alexandre Daubois
ned in the discussion thread. This will help those interested to
better understand the scope of the RFC.
My wiki name is alexandre-daubois.
Best,
Alexandre Daubois
ful, but this use case is very specialised.
>
> —Claude
Right! I think we found Gina proposed a nice alternative. I wrote a
few specs in my last thread message in response to Gina. Please let me
know if there's something that is unclear or bothering you.
Best,
Alexandre Daubois
ot;); // true
is_representable_as_float("1e308"); // true
is_representable_as_float("1e400"); // false
```
What do you think of this new approach?
Best,
Alexandre Daubois
> That suggests maybe the name should communicate "safe for JavaScript"; or
> more generally "safe for 64-bit IEEE floating point".
>
> is_safe_for_js()
> is_safe_for_float()
I'm not sure we should mention Javascript, because it's actually
related to floating point storage.
> I'm not sure if acc
Hello Rowan,
Le ven. 25 juil. 2025 à 23:10, Rowan Tommins [IMSoP]
a écrit :
> 1) You need to flesh out your proposal to be explicit about *what* it would
> do, as well as why.
Indeed, I was too focused on the why and I forgot the most important part.
The idea is to have a function that receive
Hello Internals,
I would like to gather feedback on the proposal to add an
"is_integer_safe()" function to PHP. The idea came to me while
replying to a thread [1], but I think creating a discussion is more
appropriate.
Here are a few reasons I think this would be useful:
- PHP automatically conv
Hi Gina,
Le jeu. 24 juil. 2025 à 14:46, Gina P. Banyard a écrit :
>
> Hello internals,
>
> I'm mailing the list for the bike shed of the naming of a new constant I
> think we should introduce in PHP which I'm currently calling PHP_INT_MAX_SAFE.
> The purpose of this integer is to indicate what i
Hi Jakub,
Le mer. 23 juil. 2025 à 17:41, Jakub Zelenka a écrit :
> In addition it could be useful to create it from array or from class (sort of
> auto generate schema)
Writing schema by hand is painful, so that would be amazing to see
this feature land one day.
> I actually took that name fr
Hi Jakub
Le mer. 23 juil. 2025 à 15:33, Jakub Zelenka a écrit :
>
> Hello,
>
> I would like introduce and open discussion for RFC proposing the addition of
> JSON Schema validation support to JSON extension:
>
> https://wiki.php.net/rfc/json_schema_validation
>
> If this is successful, it should
30 matches
Mail list logo
