> Am 4.7.2015 um 23:09 schrieb Niklas Keller <m...@kelunik.com>: > > 2015-07-04 22:56 GMT+02:00 Sherif Ramadan <theanomaly...@gmail.com > <mailto:theanomaly...@gmail.com>>: > Hey guys, > > I'm proposing that we reconsider removing the warning from floating point > division and here's why. > > While IEEE 754 defines special values for floating point arithmetic when > division by zero occurs, there's nothing stopping the language from > providing useful error information to the user, which may help them debug > potentially buggy code. It's true that it's not exceptional since there is > now well defined behavior in the case of changing division by zero to IEEE > 754 standard in PHP. However, PHP didn't actually distinguish between > integer division and floating point division prior to intdiv. So in the > case of division by zero the warning was useful to help someone catch their > mistake. > > Now, the onus is on the person writing the code to decipher whether or not > they created a potential division by zero scenario by deducing how they > arrived at INF at some point in their code. This is creating an unnecessary > burden when we've always provided the user with the useful error > information in the past. I'm not sure why we should remove it now, but > based on this conversation I can see that the confusion resonates around > this urge to convert the warning to an exception and the conflict of it not > being exceptional (in the case of floating point math) since there is now > well defined behavior. > > So my conclusion is that... > > Yes, it's not exceptional. No, we shouldn't throw an exception for division > by zero in floating point arithmetic. No, we shouldn't remove the warning > since it still provides useful information to the person debugging the > code. Debugging the code without this warning can be a monstrosity since > you won't necessarily know at which point in a compounded operation the > division by zero occurred. For example, PHP_INT_MAX ** PHP_INT_MAX creates > an overflow resulting in INF. Though 0 / INF results in 0. So an operation > like (1 / ($x / PHP_INT_MAX ** PHP_INT_MAX) where $x happened to be 0 in > one particular case, makes both hunting down and reproducing the bug quite > difficult without some direction. The warning has historically provided > this direction in the past and I believe that removing it now will only > further the confusion. > > I don't think people actually care about whether or not we keep the > warning. I think what they would care about more is the consistency of the > return value and defined behavior, which I believe we have already > addressed very well. > > +1, I fully agree. It's not exceptional, but it's potentially buggy code and > should > therefore produce a warning instead of just returning INF. > > I assume, most developers don't want to deal with INF in their code. If > there's > a warning, they can convert it to an exception which would not be possible > without it. > > Regards, Niklas
Generally, that was my first proposal, and I’d still support it and would like to implement it, when other people are agreeing here. As Andrea objected to that ( / floating point division should be handled like IEEE 754…), I’d like to wait for further opinions on this before committing anything in this direction. Ideally, I’d prefer to have that solved until Monday evening so that I can change it before beta 1 tagging. Thanks, Bob
