Christoph,
On Wed, Feb 18, 2015 at 6:09 PM, Christoph Becker <cmbecke...@gmx.de> wrote:
> Anthony Ferrara wrote:
>
>> 3. int typed variables can resolve a parameter type of float So
>> calling requiresAFloat(10) will work even in strict mode.
>
> Have you considered the overflow behavior of ints resulting in a float?
> For instance, the following code would produce E_RECOVERABLE_ERROR, AIUI:
>
> <?php
>
> declare(strict_types=1);
>
> function foo(int a, int b) {
> bar(a * b);
> }
>
> function bar(int n) {
> }
>
> foo(10000000000, 10000000000);
>
> It seems to me that this behavior is hard to deal with generally for
> programmers as well as static analyzers. Andreas' bigint RFC[1] would
> solve that issue, but it has been withdrawn, and AFAIK nobody is working
> on it. OTOH, bigint would make the widening from int to float
> potentially even more lossy (i.e. inaccurate) than it is now (64bit ints
> vs. IEEE 754 doubles).
>
> IIRC, Pascal does not promote int to float on overflow, but rather
> discards the high bits (unless overflow checking is enabled; available
> only in some "newer" dialects). I don't know how Java handles this
> case, but I assume there's no promotion to float either.
>
> [1] <https://wiki.php.net/rfc/bigint>
>
That is a very good point. We had discussed that a while ago, but it
hasn't come up in a while here. I've added a section in the RFC on it:
https://wiki.php.net/rfc/scalar_type_hints_v5#integer_overflow_to_float_behavior
Basically, I don't see any sane alternative but to have it cause an
error at runtime. It's not precision loss, it's magnitude loss.
The only other thing I can think of is to have the operators not
promote in strict mode, but that's even worse since now you're
clamping and not even giving the ability to detect it.
I don't think in practice it will be a huge issue, but even if it
comes up, it'll at least error sanely...
Thanks
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
