Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129902
Precedence: list
MIME-Version: 1.0
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
 <EDFD449E-59F4-4DFA-B348-B1650A745DB1@rwec.co.uk>
In-Reply-To: <EDFD449E-59F4-4DFA-B348-B1650A745DB1@rwec.co.uk>
Date: Fri, 23 Jan 2026 18:05:02 +0100
Message-ID: <CAMU7irJW2S89JVzTQcJuXSjAuRgTn-29vgavq+0SCpxYwFH-JQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable
 in Strict Mode
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.daubois+php@gmail.com (Alexandre Daubois)

Hi Rowan,

Le ven. 23 janv. 2026 =C3=A0 15:55, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> a =C3=A9crit :
> I am strongly against the Stringable part of this.
>
> It would mean users who have explicitly asked for no type coercion would =
get silent type coercion. It would mean that a string parameter in mode 1 w=
ould still reject an integer 42, but would *accept* new BcMath\Number(42). =
I can't see how that makes sense.

Stringable is an explicit contract that an object can be safely
converted to a string. If an application breaks because of such a
cast, this means the implementation of the `__toString()` method is
buggy and does not respect the contract. Currently, non-strict and
strict modes differ on Stringable handling, and I'm not aware of this
non-strict behavior causing bugs in production applications - though
I'd genuinely welcome counterexamples if you're aware of any.

Regarding your BcMath\Number example: I see the distinction you're
making, but I think the key difference is the *explicit opt-in*. An
integer doesn't choose to be convertible to string - that's a built-in
coercion. A class implementing Stringable explicitly declares "I have
a canonical string representation". The parallel would be: strict mode
rejects int -> string coercion (implicit), but should accept
Stringable -> string because it's an explicit contract, much like it
accepts objects implementing ArrayAccess for array operations in
certain contexts.

As mentioned by Larry, Stringable changes would deserve another RFC.
We're considering creating a second RFC just for the Stringable part,
so I propose to continue this discussion in the coming thread if that
suits you, so we can keep things organised.

> As I've said elsewhere, I think the right approach to this is to design a=
 new set of cast operations, with a more extendable syntax. They can have m=
ore clearly defined rules for "int-like string" etc, and different modes/va=
riants for use cases like "error on failure" vs "default value on failure".

Our goal is to make things more consistent and simple, and I'm afraid
creating a new set of casts would just overcomplexify things. The
fundamental problem would be shifted to somewhere else, not solved.
Adding new cast operators would create a third set of rules alongside
type coercion and type declarations. Aligning existing casts with the
type checking semantics that have been standard since PHP 7.0 seems
simpler and more maintainable long-term.

=E2=80=94 Alexandre Daubois