[RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, Some remarks about the paragraph “Backward Incompatible Changes”

This is a real concern. I have personally defined a `bcround()` global function because I needed such a functionality. A quick search on GitHub shows that I am not alone: https://github.com/search?q=bcround+language%3Aphp&type=code

If the existence of the function is checked in advance, the BC risk is worst, because they cannot have known whether the signature and semantics of the function you will introduce will be compatible with the one they have defined. In case of mismatch the eventual breakage could be more difficult to notice and trace back. Note in particular this SO question: https://stackoverflow.com/questions/231057/how-to-round-ceil-floor-a-bcmath-number-in-php, where the second answer has a different rounding mode on halves than the first and third answers. Fortunately, the few examples I have seen don’t foolishly guard the definition with `if (!function_exists(...))`, so that there will be a hard break when upgrading PHP (static error: function already defined), and they’ll have to decide explicitly what to do. In my case, I’ll wait until this RFC is accepted, then (and only then) I’ll decide what to do depending on whether my version of `bcround()` is compatible with yours (either rename or `function_exists()` guard).

I think that it is necessary to acknowledge that there will be breakage for some people, and to decide explicitly whether this breakage is acceptable. (I think it is.) —Claude

Hello, Recently I was trying to fix and clean some of the stuff within the BCmath extension along with Girgias who helped me. I wanted to enrich this extension with similar functions that GMP contains and improve the performance, however, I went to some conclusions and stopped it. 1. BCMath extension isn't fast enough compared to other existing arbitrary precision PHP extensions. Comparison: https://php-decimal.github.io/#performance 2. BCMath doesn't have OO API and thus it may break the backward compatibility as Claude noticed. 3. GMP GNU library provides support for float numbers, however, its functionality is not exposed in the PHP extension. And BCMath doesn't provide as many functions as GMP. And I understood that the BCMath extension should be abandoned eventually when the GMP library is properly extended. There is no need for 2 arbitrary precision extensions complementary to each other but for the rich one having all of the functionalities. I don't want to discourage you, because there is clearly a need for such functions. Speaking from my perspective I would rather invest time into the GMP extension than extend the BCMath extension. If anyone also thought about this direction I could help and join forces to have one proper math library in PHP. Kind regards, Jorg

Hi, It's been two weeks since then. I don't think there is any reason to prevent enhancements to BCMath's functionality at this point, unless there is a realistic discussion of deprecating BCMath and providing another math extension. Also, regarding conflicts with functions of the same name that are already in user land, this is targeted for a minor update, so we believe there will be enough time to fix them. Also, if we consider conflicts with user land function names, it will be difficult for PHP to add functions in the future, so this is not a good idea. Regards. Saki