> Le 27 avr. 2023 à 00:03, Rowan Tommins <rowan.coll...@gmail.com> a écrit : > >> >> In PHP8, passing float values >> to BCMath may lead to issues due to type mismatch which is a >> mind-blowing counter-intuitive issue. > > Far from counter-intuitive, that's an essential feature of any decimal > implementation - as soon as the value is in a floating point variable, it's > *already too late* to make it a fixed-precision decimal. > > The php-decimal homepage at http://php-decimal.io/#basic-usage makes this > very clear: > > > Special float values are also supported (NAN, INF and -INF), but float is > > otherwise not a valid argument in order to avoid accidentially using a > > float. If you absolutely must use a float to construct a decimal you can > > cast it to a string first, but doing so if affected by the precision INI > > setting. > > > > Projects using this extension should avoid float entirely, wherever > > possible. An example workflow is to store values as DECIMAL in the > > database, query them as string, parse to Decimal, perform calculations, and > > finally prepare for the database using toFixed.
This is the the description of the PHP Decimal extension, which does indeed the Right Thing. But BCMath (which is not PHP Decimal) does have “mind-blowing counter-intuitive” issues (at least in `strict_types=0` mode) with floats. Formally, the root of the issue is in PHP type juggling, not in bcmath itself; but from a user perspective, it doesn’t matter. Specifically, passing a float to the bc*() functions will “work” most of the time; but in rare cases, when PHP decides to use the scientific notation while casting it as string, it will fail with an “argument is not well-formed” error, which is puzzling for the unprepared user. —Claude
