Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83135
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E51B9E.1060201@gmx.de>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
	<54E51B9E.1060201@gmx.de>
Date: Wed, 18 Feb 2015 18:21:06 -0500
Message-ID: <CAAyV7nFFVrDMik-OV1fi7VEjsSEcLjN4rygQevs=UR8yjeEcvw@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: ircmaxell@gmail.com (Anthony Ferrara)

Christoph,


On Wed, Feb 18, 2015 at 6:09 PM, Christoph Becker <cmbecker69@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