Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83139
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
Message-ID: <54E53D80.5040407@gmx.de>
Date: Thu, 19 Feb 2015 02:33:52 +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: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com> <54E51B9E.1060201@gmx.de> <54E53408.90005@lsces.co.uk>
In-Reply-To: <54E53408.90005@lsces.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: cmbecker69@gmx.de (Christoph Becker)

Lester Caine wrote:

> On 18/02/15 23:09, Christoph Becker wrote:
>> 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).
> 
> The 'unconstrained integer' RFC adds it' own problems, but the int ->
> float overflow is only a problem with 32bit builds anyway. 64bit builds
> will not overflow until they run out of space anyway.

It seems to me you're thinking too much (maybe only?) about "database
types".  IMHO PHP can be used more versatile, and there might be issues
which are exemplified in the RFC[1]:

  var_dump(2 ** 64); // float(1.844674407371E+19)

Clearly an int->float overflow that'll also happen on 64bit builds.

[1]
<https://wiki.php.net/rfc/scalar_type_hints_v5#integer_overflow_to_float_behavior>

-- 
Christoph M. Becker