Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75081
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
In-Reply-To: <EFEB30F4-3F52-44B3-98CE-9DD29ED08E74@ajf.me>
Date: Wed, 25 Jun 2014 22:04:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <1CA68980-7451-4E28-AD4F-ED120393E131@ajf.me>
References: <EFEB30F4-3F52-44B3-98CE-9DD29ED08E74@ajf.me>
To: PHP Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [DRAFT][RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)

Good evening,

The RFC and patch are still incomplete, but there is a certain open =
question I would like to start a discussion about, which has wider =
impact beyond merely bigints, namely dealing with floats as array keys. =
To quote the RFC:

> A problem arising from allowing integers to be arbitrarily large is =
that array keys using strings for numeric keys beyond the maximum size =
of a long would probably seem weird. At present, bigints are just dealt =
with as if they were numeric strings when using them as array keys and =
indices, but this may not be optimal. This RFC aims for integer =
consistency across platforms, and this would be a remaining =
inconsistency. It also doesn't make sense from a user perspective to =
have integers over a certain value suddenly become string keys, though =
whether this matters much in practise with PHP's type casting and =
juggling is a different question.
>=20
> This also presents a further issue: inconsistency between longs, =
bigints and doubles, which **must** be avoided, as integer consistency =
cross-platform is a key goal of this RFC. Currently in PHP, doubles used =
as indexes are simply casted to longs, without any regard for size. This =
means that they overflow if they are larger than the platform's long =
size, either 32-bit or 64-bit. However, bigints as implemented, will be =
treated as strings if they are outside of the bounds of a long on the =
platform. While bigints are likely to  break existing code anyway, this =
would be a particularly bad breakage, as code relying on very large =
numbers being floats and wrapping when used as indices would break. =
Hence some sort of solution must be found. Either we cast bigints to =
longs and let them overflow (not terribly desirable), we don't change =
the current behaviour (inconsistent), or we change the handling of =
doubles. Personally, I don't like what PHP does here and would to go for =
this last option.

I think the current behaviour for floats as array keys is bad and we =
should change it. In my opinion, it should convert to string if =
fractional or if outside the range of a long, and otherwise convert to =
long. I think this is the most intuitive behaviour and the least =
confusing for new users, and probably also the least likely to cause =
bugs. Failing that, I=92d like to see warnings when fractional floats =
are truncated to be used as array keys. We already warn about casts for =
string offsets, so I don=92t see why we couldn=92t for array offsets.

I=92m less concerned about whether bigints become string keys or =
preserve their int-ness, as the difference to the end-user is much =
lesser. If I did add support for bigint keys, I=92d probably just do so =
by storing them as strings and converting to bigint on output.=20

What are your thoughts? Obviously, as this RFC targets PHP 6/NEXT, =
breaking BC is acceptable to a degree. Also, if this becomes too =
controversial an issue (I hope not), I could always call a parallel vote =
on it if this RFC eventually goes to a vote.

Thanks!
--
Andrea Faulds
http://ajf.me/