Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83138
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
Message-ID: <54E53AFD.7060000@gmx.de>
Date: Thu, 19 Feb 2015 02:23:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>	<54E51B9E.1060201@gmx.de> <CAAyV7nFFVrDMik-OV1fi7VEjsSEcLjN4rygQevs=UR8yjeEcvw@mail.gmail.com>
In-Reply-To: <CAAyV7nFFVrDMik-OV1fi7VEjsSEcLjN4rygQevs=UR8yjeEcvw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: cmbecker69@gmx.de (Christoph Becker)

Anthony,

Anthony Ferrara wrote:

> On Wed, Feb 18, 2015 at 6:09 PM, Christoph Becker <cmbecker69@gmx.de> wrote:
>
>> 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);
>
> 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

Thanks for adding a respective note to the RFC, because IMHO it's quite
important to consider the behavior.  Somehow I would like to have
Scheme's numeric system, but that doesn't seem to fit well with type
hinting (neither strict nor weak) -- at least not when it's about
performance.

> 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...

ACK.

-- 
Christoph M. Becker