Re: [DRAFT][RFC] Big Integer Support

From: Date: Wed, 25 Jun 2014 21:04:08 +0000
Subject: Re: [DRAFT][RFC] Big Integer Support
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-75081@lists.php.net to get a copy of this message
Good evening, The RFC and patch are still incomplete, but there is a certain open question I would like to start a discussion about, which has wider impact beyond merely bigints, namely dealing with floats as array keys. To quote the RFC: > A problem arising from allowing integers to be arbitrarily large is that array keys using > strings for numeric keys beyond the maximum size of a long would probably seem weird. At present, > bigints are just dealt with as if they were numeric strings when using them as array keys and > indices, but this may not be optimal. This RFC aims for integer consistency across platforms, and > this would be a remaining inconsistency. It also doesn't make sense from a user perspective to > have integers over a certain value suddenly become string keys, though whether this matters much in > practise with PHP's type casting and juggling is a different question. > > This also presents a further issue: inconsistency between longs, bigints and doubles, which > **must** be avoided, as integer consistency cross-platform is a key goal of this RFC. Currently in > PHP, doubles used as indexes are simply casted to longs, without any regard for size. This means > that they overflow if they are larger than the platform's long size, either 32-bit or 64-bit. > However, bigints as implemented, will be treated as strings if they are outside of the bounds of a > long on the platform. While bigints are likely to break existing code anyway, this would be a > particularly bad breakage, as code relying on very large numbers being floats and wrapping when used > as indices would break. Hence some sort of solution must be found. Either we cast bigints to longs > and let them overflow (not terribly desirable), we don't change the current behaviour > (inconsistent), or we change the handling of doubles. Personally, I don't like what PHP does > here and would to go for this last option. I think the current behaviour for floats as array keys is bad and we should change it. In my opinion, it should convert to string if fractional or if outside the range of a long, and otherwise convert to long. I think this is the most intuitive behaviour and the least confusing for new users, and probably also the least likely to cause bugs. Failing that, I’d like to see warnings when fractional floats are truncated to be used as array keys. We already warn about casts for string offsets, so I don’t see why we couldn’t for array offsets. I’m less concerned about whether bigints become string keys or preserve their int-ness, as the difference to the end-user is much lesser. If I did add support for bigint keys, I’d probably just do so by storing them as strings and converting to bigint on output. What are your thoughts? Obviously, as this RFC targets PHP 6/NEXT, breaking BC is acceptable to a degree. Also, if this becomes too controversial an issue (I hope not), I could always call a parallel vote on it if this RFC eventually goes to a vote. Thanks! -- Andrea Faulds http://ajf.me/

« previous php.internals (#75081) next »