On 15 February 2015 at 02:46, Andrea Faulds <a...@ajf.me> wrote: > Hi everyone, > > I should’ve done this a long time ago, but I’m going to hold a vote on this > RFC. The implementation isn’t finished, but the remaining work isn’t > impossible to surmount (though help would certainly be appreciated). RFCs can > be put to vote without implementations (or so says > https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished > isn’t necessarily a blocker. > > Putting it to a vote, finally, means I can stimulate further discussion > (let’s face it, most discussion on a given RFC happens during voting), and > importantly, see how much support the RFC has in order motivate myself to > finish the implementation. > > I think this would be a useful feature for PHP. It brings PHP into line with > other modern dynamic languages in having integers of arbitrary size. It makes > integer behaviour both more intuitive and more consistent across platforms. > It (finally) adds a means for handling of 64-bit (and larger) integers in > 32-bit environments. I think allowing integers to grow as needed and not > having to worry about platform-specific details is very “PHP”, as well. > > So, anyway, here’s the RFC, including the voting widget: > > https://wiki.php.net/rfc/bigint > > Voting starts today (2015-02-15) and ends in 10 days (2015-02-25). > > If you have any queries, please ask. > > Thanks! >
I think this adds a ton of unnecessary complexity and isn't worth the breaks or performance degradations that come with it. We already have big integer support in the form of the GMP extension, and it is very clear when you are working with arbitrary length integers. But instead this patch adds GMP as a dependency and hides it away internally (or for a bigger performance hit, LibTomMath). Extensions "that deal with numbers" are all going to need updating. So probably every extension? You talk about eventually deprecating ext/gmp and moving it to PECL. Definitely not acceptable. Sorry, the fixed size integer data type is far too baked-in and useful. I don't see any gain from this patch except hidden performance penalties, breaks, and extra work for everyone in maintaining it and other extensions. I'd rather big int usage was kept verbose and conscious. -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php