Re: [VOTE][RFC] Integer Semantics

On 16 Sep 2014, at 11:19, Chris Wright <cw@daverandom.com> wrote: > On 16 September 2014 11:05, Dmitry Stogov <dmitry@zend.com> wrote: >> you already made silent break for N << 64 and N >> 64, but it may be >> explained as more consistent behaviour. >> I don't see a big difference with negative shifts. >> >> The real thing that I don't like - is a "boolean" result. Warning is not a >> big problem. > > I'm inclined to agree with this. The warning makes sense as it's > almost certainly a userland bug, and if the expected old behaviour is > desired it can easily be modified in userland, but returning FALSE > doesn't make a huge amount of sense. This will almost certainly be > immediately cast to int(0) by the next operation - almost no-one is > going to actually check for a return value of FALSE - so it makes more > sense to just return 0 and avoid the implicit cast. This would also > produce possibly-unexpected results if a future operation was to > stringify the result, as FALSE would cast to the empty string. > > I have voted in favour of the RFC as it stands as I believe that > overall the changes are positive, but ideally this particular case > would be addressed. The choice of bool(false) was due to precedent. This is what we do for a division by zero. I agree that some other value would make more sense, but I couldn’t think of a better one, so I just stuck with the existing behaviour for div0. -- Andrea Faulds http://ajf.me/