Re: Proposal: Arbitrary precision native scalar type

From: Date: Sun, 05 May 2024 17:45:24 +0000
Subject: Re: Proposal: Arbitrary precision native scalar type
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-123268@lists.php.net to get a copy of this message
On 30 April 2024 11:16:20 GMT-07:00, Arvids Godjuks <arvids.godjuks@gmail.com> wrote: >I think setting some expectations in the proper context is warranted here. > >1. Would a native decimal type be good for the language? I would say we >probably are not going to find many if any people who would be against it. As I said earlier, I don't think that's the right question, because "adding a native type" isn't a defined process. Better questions are: Should a decimal type be always available? Does a decimal type need special features to maximise performance? Should we have special syntax for a decimal type? What functions should support a decimal type, or have versions which do? >2. Is there a need for it? Well, the whole world of e-commerce, accounting >and all kinds of business systems that deal with money in PHP world do not >leave any room for doubt - https://packagist.org/?query=money . >The use >case is right there :) That's a great example - would a decimal type make those libraries redundant? Probably not - they provide currency and rounding facilities beyond basic maths. Would those libraries benefit from an always-available, high-performance native type? Certainly. Would they benefit from it having strong integration into the syntax and standard library of the language? Not really; there's a small amount of actual code dealing with the values. >4. Is it a lot of engine work? Only if we go for the maximum ambition, highly integrated into the language. > Is it worth it? I'm actually not convinced. >5. But BCMath/GMP/etc!!! Well, extensions are optional. Extensions are only optional if we decide they are. ext/json used to be optional, but now it's always-on. > They are also not as fast and they deal with strings. Not as fast as what? If someone wants to make an extension around a faster library, they can. And only BCMath acts directly on strings; other libraries use text input to create a value in memory - whether that's a PHP string or a literal provided by the compiler doesn't make much difference. I absolutely think there are use cases for decimal types and functions; but "I want a faster implementation" and "I want to add a new fundamental type to the language, affecting every corner of the engine" are very different things. Regards, Rowan Tommins [IMSoP]

« previous php.internals (#123268) next »