Re: Proposal: Arbitrary precision native scalar type

On Sun, Apr 28, 2024 at 11:36 AM Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > > > > On 28 April 2024 07:02:22 BST, Alexander Pravdin <alex.pravdin@interi.co> wrote: > >Hello everyone. To continue the discussion, I'm suggesting an updated > >version of my proposal. > > > This all sounds very useful ... but it also sounds like several months of full-time expert > development. > > Before you begin, I think it will be really important to define clearly what use cases you are > trying to cater for, and who your audience is. Only then can you define a minimum set of > requirements and goals. > > It seems to me that the starting point would be an extension with a decimal type as an object, > and implementations for all the operations you want to support. You'll probably want to define > that more clearly than "anything in the language which takes a float". > > What might seem like it would be the next step is converting the object to a "native > type", by adding a new case to the zval struct. Not only would this require a large amount of > work to start with, it would have an ongoing impact on everyone working with the internals. > > I think a lot of the benefits could actually be delivered without it, and as separate projects: > > - Optimising the memory performance of the type, using copy-on-write semantics rather than > eager cloning. See Gina's recent thread about "data classes". > > - Overloading existing functions which accept floats with decimal implementations. Could > potentially be done in a similar way to operator overloads and special interfaces like Countable. > > - Convenient syntax for creating decimal values, such as 0.2d, declare(default_decimal), or > having (decimal) casts affecting the tree of operations below them rather than just the result. This > just needs the type to be available to the compiler, not a new zval type - for instance, anonymous > function syntax creates a Closure object. > > There may be other parts I've not mentioned, but hopefully this illustrates the idea that > "a native decimal type" doesn't have to be one all-or-nothing project. > > Regards, > Rowan Tommins > [IMSoP] I'm not so sure this could be implemented as an extension, there just isn't the right hooks for it. Robert Landers Software Engineer Utrecht NL