On 14 Oct 2014, at 19:11, Stas Malyshev <smalys...@sugarcrm.com> 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
