On Fri, Apr 3, 2015 at 11:59 PM, Andrea Faulds <a...@ajf.me> wrote: > Hi, > > > On 3 Apr 2015, at 20:46, Dmitry Stogov <dmi...@zend.com> wrote: > > > > May be you'll also suggest something regarding bitwise shifts with > negative offset? > > Allowing negative offsets using opposite directions would fix > inconsistency, but I remember, you didn't like it. > > May be keep WARNING (Bit shift by negative number) and then perform > shift in another direction? > > + disable negative shifts at compile-time. > > I don’t think opposite-direction shifts would work well for a few reasons. > I don’t believe this is normal behaviour in other languages, for one. > Another issue is that << and >> are not actually opposites, they have > different behaviour with respect to signs, so there’d be ambiguity as to > what $x << -$y means (is it the same as $x >> $y, or does it deal > differently with signs?). Negative shifts being used are usually the result > of mistakes, as well, so you want to inform the user. > > The main problem, though, is that we previously did something different if > the shift is negative. Having it now produce a warning, means you’ll see > error messages when you run existing code. But shifting in the opposite > direction might change the behaviour of existing code silently > > I think the most sensible solution would be to make negative shifts > produce an exception, since they’re really an error, an unsupported > operation. I made them be a warning + return FALSE just because it matched > division. But that’s not ideal and I’d be fine if it was replaced. >
OK. Exception is fine. So the summary: 1) division by zero produces a warning and +/-INF IS_DOUBLE. Compile-time evaluation is disabled. 2) Negative shift produces Exception.Compile-time evaluation is disabled. 3) Modulo by zero produces Exception.Compile-time evaluation is disabled. Everything right? I'm going to implement this on Monday. Thanks. Dmitry. > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ > > > > >
