Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124275
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath
 function
In-Reply-To: <668B6428.9030705@adviesenzo.nl>
Date: Mon, 8 Jul 2024 13:29:13 +0900
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3DF46B77-530C-4CC7-8BFF-8B3DC2232EE2@sakiot.com>
References: <668B4C78.2000808@adviesenzo.nl>
 <8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com>
 <668B6428.9030705@adviesenzo.nl>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
From: saki@sakiot.com (Saki Takamachi)

Hi Juliette,

> I honestly don't understand what you are saying here.
>=20
> If 0.285 is a string, then no type conversion would be needed to pass =
it to BCMath anyhow.
> Otherwise, 0.285 would be a floating point number already.
>=20
> If the type for BCMath would become `int|string`, in non-strict mode, =
there would be quite a significant change in behaviour for the BCMath =
functions as passing the _float_ 0.285 would previously result in the =
string "0.285" being passed to the BCMath function, but would now result =
in the integer 0 being passed.
>=20
> I think this BC-break will need to be called out as it is not =
mentioned in the RFC.
> I also think this BC-break should be enough reason not to accept the =
RFC.

I had overlooked the priority order of Union type casts, thank you.

I don't think a satisfactory specification will be decided on this =
before the feature freeze, so I will not rush into discussing this RFC =
for now. Of course, no voting will take place until the specifications =
are decided. If we were to discuss this change again, it would be in =
versions beyond 8.4.

Regards,

Saki=