Hey Sherif, > On 4 Jul 2015, at 21:56, Sherif Ramadan <theanomaly...@gmail.com> wrote: > > 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.
Yeah, keeping it around makes sense. Thing is, if it’s a problem, you can silence it with @, so @($a / $b). If that’s slow, we could optimise it (make it call div_function_no_error or something?) Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
