On 7 April 2024 11:44:22 BST, Saki Takamachi <s...@sakiot.com> wrote:
>I don't think the two threads can be combined because they have different
>goals. If one side of the argument was, "How about to add BCMath?" then
>perhaps we should merge the discussion. But BCMath already exists and the
>agenda is to add an OOP API.
>
>In other words, one is about adding new features, and the other is about
>improving existing features.
While I appreciate that that was the original aim, a lot of the discussion at
the moment isn't really about BCMath at all, it's about how to define a
fixed-precision number type. For instance, how to specify precision and
rounding for operations like division. I haven't seen anywhere in the
discussion where the answer was "that's how it already works, and we're not
adding new features".
Is there anything in the proposal which would actually be different if it was
based on a different library, and if not, should we be designing a
NumberInterface which multiple extensions could implement? Then Jordan's search
for a library with better performance could lead to new extensions implementing
that interface, even if they have portability or licensing problems that make
them awkward to bundle in core.
Finally, there's the separate discussion about making a new "scalar type". As I
said in a previous email, I'm not really sure what "scalar" means in this
context, so maybe "integrating the type more directly into the language" is a
better description? That includes memory/copying optimisation (potentially
linked to Ilija's work on data classes), initialisation syntax (which could be
a general feature), and accepting the type in existing functions (something
frequently requested for custom array-like types).
In other words, looking at how the efforts overlap doesn't have to mean
abandoning one of them, it can mean finding how one can benefit the other.
Regards,
Rowan Tommins
[IMSoP]
