Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129904
Precedence: list
MIME-Version: 1.0
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
 <53f11b44-11c1-4b23-a8be-c7846262a49c@app.fastmail.com>
In-Reply-To: <53f11b44-11c1-4b23-a8be-c7846262a49c@app.fastmail.com>
Date: Fri, 23 Jan 2026 18:06:23 +0100
Message-ID: <CAMU7irJm-46Ze168GUJj=S0rnnULK66a-p5AW3QNe7LtHANbyQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable
 in Strict Mode
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <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 Larry,

Le ven. 23 janv. 2026 =C3=A0 17:06, Larry Garfield <larry@garfieldtech.com>=
 a =C3=A9crit :
> 1. This really feels like two separate RFCs.  I'd rather see them as two =
separate RFCs than one mixed RFC.

Indeed, we'll be working on separating the RFCs. Let's consider this
one as the fuzzy casts one, and the soon-to-be-created RFC will only
talk about Stringable.

> 2. I tend to agree with other commenters that we should leave the existin=
g casts alone, and instead add a new, more reasonable type conversion opera=
tors (for some definition of reasonable).

I shared my point of view about this solution in my responses to
others. Don't hesitate if something's unclear or bothers you!

> 3. Unlike the other commenters, I am 100% in favor of allowing `string` t=
o accept Stringable in strict mode.  Strict mode basically broke Stringable=
, and that's been an annoyance for a long time.  I know some feel that Stri=
ngable is always and forever a bad thing, amen, but I don't agree.  It has =
ample valid use cases, even if it can be abused.  I want my Stringable obje=
cts back! :-)

Let's work for that!

=E2=80=94 Alexandre Daubois