Re: Integer operations are implementation-defined

On 31 Jul 2014, at 01:56, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > I think we don't need to close the door to infinite precision ints. This wouldn’t close the door to them IMO, it just means that PHP can’t have them for 5.6, and I think that’s reasonable. I suppose you could make a 5.6 implementation which had them, but we make a number of assumptions in other places don’t really make sense with arbitrary-precision ints, and code generally relies on them *not* being arbitrary-precision (whether the authors realise it or not). We can always change the spec in a large increment (I’m hoping for 7.0) to mandate them to be arbitrary-precision instead, indeed that is what I would like to do. However, I am firmly of the opinion we should only allow one approach, the one that php.net PHP currently uses and that most code consequently relies on. To given an example of problems with implementing arbitrary-precision ints for an implementation conforming to 5.6, the shift left and shift right operators wouldn’t make sense for negative operands as they’re currently locked to the maximum number of bits. Another problem is PHP_INT_MAX, which you’d either have to invent an “infinite” integer value for, not include it, use a floating point INF, or use the maximum platform integer size (probably max 64-bit or 32-bit int). All of these present considerable problems and make it difficult to write code that works properly on multiple implementations. These are all also problems that my bigints RFC is able to deal with specifically as it would go into a major version and could change how the language deals with these things. In summary, arbitrary-precision integers don’t make any sense when most code relies on integers being fixed-size, and without changing what the operators do. We can always change what they do in a later iteration of the specification. > Wrapping though makes little sense to me in the spec - it's a C > artifact, and if some implementation chooses to do this for some reason, > that's ok but not a reason for us to make it normative. > > Other option would be to make #1 and #3 recommended ways of implementing > it, while leaving an option for another behavior open. I don’t think we should be loose here. One of the chief advantages of very high-level languages like PHP is you can usually guarantee code works the same across platforms and implementations. Furthermore, part of the point of a specification is in ensuring different implementations do the same thing in edge cases like this one. I don’t think we should allow any leniency on this specific point. I realise that this isn’t what some implementations do here, but I don’t think we should always make things be up to the implementation simply because certain existing implementations have decided to do different things. We also risk actually fragmenting PHP further, because php.net previously defined the language and did only one thing here, while we now have a draft specification which explicitly permits doing something else. In a sense, then, we are changing the language to permit these things, if this specification is to be normative. Actually, on that point, this is an advantage of specifying things only for a new version (like PHP 5.6). 5.6 isn’t out yet, so implementations other than php.net PHP have a chance to make sure their behaviour matches the spec. While we could make #1 be recommended and allow others, this still leaves us with the same problem really. I’d rather we limit leniency as much as possible. There are obviously some cases where we can’t just now (some things are actually “implementation-defined” in *php.net PHP* like casting INF to an int, as it does whatever the C compiler does), but we should still limit freedom for implementations where we can it affects observed behaviour. -- Andrea Faulds http://ajf.me/