Re: Integer operations are implementation-defined

On Wed, Jul 30, 2014 at 11:29 AM, Andrea Faulds <ajf@ajf.me> wrote: >> * The computation is done as though the types of the values were float with the result >> having that type >> * The result type is int and the value reflects wrap-around (for example adding 1 to the >> largest value results in the smallest value) >> * The computation is done as though the type had some unspecified, arithmetic-like object >> type with the result being mathematically correct > > I really don’t like this. > Found that one quicker than I expected. :) Side note: HHVM actually does the same behavior as PHP by default. We only do the wrap-around behavior when in "Hack" mode (which isn't PHP, so that's fine). For what it's worth, I think both of the first two options do the user a disservice with their behaviors. Wrap-around is probably not what you're expecting, but float promotion loses precision (immediately, on 64bit platforms) and that produces bugs which are even harder to spot (at least when it's negative, it's pretty obvious where something went wrong). > Of course, integer size will inevitably vary (unless my bigints RFC makes it in ;) > Actually, it's this RFC, and the 64-bit/float issue (which isn't a new idea on internals@) which led to the 3rd behavior option. Personally, I'd love to see both implementations move that way. Ultimately, option#2 was left in because it's used by a few implementations (not just HHVM) and it was worth mentioning. If it was pulled out of the spec, I wouldn't personally be bothered. As for option#3, that was perhaps optimistic. Maybe pull it out and replace it when your RFC passed. :) -Sara