Might be worth making this into a zend_always_inline function and then have _zval_get_long_func and _zval_get_long_func_nonsilent or something. Dunno how compiler deals with this atm, haven't benchmarked.

this will convert the same string twice. This also misses incorrect double string usage, e.g. (5 & "12.5")

"12.5" should probably still be allowed. After all, we also support 5 & 12.5. But agree that if we use is_numeric_string we no longer need the STRTOL call.

This part is troublesome. If we use is_numeric_string to convert, then we start supporting scientific notation for numbers, which we don't at present because strtol() doesn't support it.

If we don't use it, though, then there's the problem Dmitry points out: is_numeric_string will accept things that strtol won't handle properly.

Supporting floats and their notation (scientific) would make PHP more consistent. We currently support this for long parameters in argument parsing, e.g.

$ php -r 'var_dump(intdiv("1e3", 1));'
int(1000)

Yet due to the use of strtol() here, we don't for the integer operators, nor for (int) and intval(). So this means that 3e3 is considered to be 3 for some integer operations and 3000 for others, which is not ideal.

Would it cause backwards-compatibility issues if we started allowing floats here? I don't think it would.

I think more consistent float support makes sense and worth the minor BC break in 7.1.

I think so too. Anyway, this is a significant change, so I'll suspend the vote on the RFC and update it.

s/only/don't?

Good catch.