On 14 Oct 2014, at 19:11, Stas Malyshev <[email protected]> wrote:
> Hi!
>
>> Still, it’s inconvenient. More for developers to worry about.
>
> I still have no idea why one would need a bigint constant, could you
> give an common example where you would do that?
The main point is why you should prohibit it. The point of bigints is to remove cross-platform
integer differences. Why shouldn’t you here? Why should I conditionally do different things on
64-bit and 32-bit?
>> No, only extensions. It is *completely* transparent to userland.
>> That’s the whole point.
>
> I'm not sure how it can be completely transparent if it's a different
> type. Is it still identifying as int?
Yes.
> In this case, this is dangerous as
> some functions may not be able to accept big integers when accepting int
> arguments, but checks for is_int, etc. would pass.
We already have this danger for another type: boolean. phpng got rid of IS_BOOL in favour of IS_TRUE
and IS_FALSE. If we can update everything to handle the IS_BOOL change, surely we can update
everything to handle bigints, too.
> If it's not, the extension has to handle it, the same way it has to
> handle bigint anyway if it makes difference for it. The point is many
> common cases are already covered, e.g. if the extension just needs a
> string, or if the bigint actually represents a small int, etc.
Many common cases are easily covered by a new type anyway. You overestimate the effort, I have
already done the work, it’s not much. Objects make nothing easier.
>
>> No, but existing code does have to handle float overflow. If you
>> allow that to optionally be int overflow, you now need to worry about
>> handling both.
>
> What's "float overflow”?
Beyond PHP_INT_MAX, integers magically become floats in PHP. They have done so for a long time.
> I'm not sure I'm getting your point here. You
> don't need to handle anything - if your code doesn't care about big
> ints, you just do math as usual.
Then get weird results when someone passes a large number in.
> If it does, then you have to check big
> ints are there, then do math as usual but be aware that int can be now
> of two different types. I don't see any difference from the RFC here.
The main point of the RFC is to make integers completely consistent across platforms and to remove
the need to worry about overflow. Adding optional overflow to GMP means you still have to worry
about it. It doesn’t solve anything. You can already use GMP for applications which explicitly
need to use large numbers. This RFC doesn’t exist for that purpose.
--
Andrea Faulds
http://ajf.me/