Re: Proposal: Arbitrary precision native scalar type
| From: | Rowan Tommins [IMSoP] | 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]