Re: Integer operations are implementation-defined

On 3 Sep 2014, at 20:35, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > Hi! > >>> Because they don't fit well together with the rest of the language, >>> and code right now almost certainly assumes integers are >>> fixed-size. To implement arbitrary-precision ints, something I'm >>> trying to do, you need to change the rest of the language, and >>> they'd break assumptions code currently makes. >> >> Basically, I don’t think they’d work well with how integers are dealt >> with generally in the language as it stands, and I suspect it would >> break existing code. > > You mean, there's code out there that depends on the fact that integer > is converted to float on overflow? That would be pretty strange code, > could you give an example what such code would be used for? > It just seems strange to me to explicitly ban arbitrary precision ints, > especially as we don't put any actual limit on it, so you can not rely > on any specific limit even if you needed it. I’m not sure if code depends on it, but I wouldn’t be surprised. The problem is we do different things if you hit limits. If integers are arbitrary-precision, then the limits claimed by things like PHP_INT_MAX aren’t actually correct. Also, for things like bitwise shifts, they are supposed to do different things when they hit the limit (<< shifts off bits and shifts on zeroes, for example). How would you do that sanely with arbitrary-precision integers? You’d have to pretend they’re not arbitrary-precision for that specific case. I’m all for bigints, but I don’t think we should permit implementations to do them in 5.6. If integers are to be arbitrary-precision, the rest of the language spec would need some alterations first, and that’s what my draft bigint RFC would do. -- Andrea Faulds http://ajf.me/