Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127769
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] Allow BcMath\Number to work identically to bcmath functions
Date: Fri, 27 Jun 2025 21:59:59 +0900
Message-ID: <189192D8-2505-4742-9FD9-E3CD2789A2B9@sakiot.com>
References: <20250626143156.5AA9D1A00BD@lists.php.net>
Cc: internals@lists.php.net
In-Reply-To: <20250626143156.5AA9D1A00BD@lists.php.net>
To: Russell Lee <zimzat@zimzat.com>
From: saki@sakiot.com (Saki Takamachi)

> =EF=BB=BFWhen `BcMath\Number` was introduced it allowed `string|int` metho=
d arguments. According to a separate RFC to allow `int` to the functions thi=
s was done as a performance optimization. Unfortunately this also means it e=
ffectively disallows `float` types because PHP will truncate them to integer=
s (and emit a deprecation report) instead of preserving them as strings.
>=20
> Example: https://3v4l.org/Bi5Kl
>=20
> ```php
> var_dump(
>    (string)new BcMath\Number(5)->sub(4.2, 1),
>    bcsub(5, 4.2, 1),
> );
>=20
> string(3) "1.0"
> string(3) "0.8"
> ```
>=20
> Per SakiTakamachi:
> > If there is strong demand for creating the object from a `float`, it wou=
ld be better to add support for `float` rather than removing `int` from the s=
ignature.
> > As with the bc functions, converting a `float` to a `string` can be easi=
ly handled within php-src.
> >
> > In any case, discussion on the mailing list is necessary.
>=20
>=20
> I was hoping to be able to use Number as a drop-in replacement for various=
 operations, especially back-of-the-napkin calculations, but this behavior m=
akes it too easy to accidentally write `$number * 1.2` and get unexpected re=
sults.
>=20
> There are many arguments that could be made that float is the wrong type, t=
hat it has rounding issues, and possibly other edge cases, but in the vast m=
ajority of cases `(string)$float` does exactly what is expected. The lack of=
 a non-float decimal numeric type doesn't leave much room for native express=
ion short of doing `Number((string)$i) * Number((string)$j)` or `Number('1.2=
') * '1.2'`.
>=20
> The expectation is that in PHP 9.0 float-to-int will be disallowed and wou=
ld automatically drop back to float-to-string in this case, but that is stil=
l a long way away and would mean being unable to recommend using Number in 8=
.4, 8.5, and beyond.
>=20
> Request context and discussion:
> https://github.com/php/php-src/issues/18674
>=20
> BcMath\Number RFC:
> https://wiki.php.net/rfc/support_object_type_in_bcmath
>=20
> bcmath function int type RFC:
> https://wiki.php.net/rfc/allow_int_args_to_bcmath_function

Hi Russell!

As I already mentioned in the issue thread, I want to clarify just in case: e=
ven if we allow `float` as an argument, the internal behavior would essentia=
lly be the same as passing `(string) $float_num`.
In fact, implementing any kind of custom conversion logic should be avoided,=
 as it could lead to inconsistencies with PHP=E2=80=99s native casting behav=
ior.

Also, even if implicit casting behavior changes in PHP 9.0, please note that=
 this would not benefit methods when `strict_types=3D1`.

Personally, I chose not to accept `float` in the method signature because I p=
rioritize the precision of BCMath.

To be honest, I=E2=80=99m curious about how much demand there actually is fo=
r this kind of feature.

Regards,

Saki