Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129940
Precedence: list
MIME-Version: 1.0
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
 <CANS-=pfCasTNSAMSdL8ajJMnrwNpfvbEOoQTQhAQ=X73iG+_tw@mail.gmail.com> <CAMU7irLgsMCzHsQDD6Ok2zJZsNyV7LF-PHotzqvSGRAkN9bovg@mail.gmail.com>
In-Reply-To: <CAMU7irLgsMCzHsQDD6Ok2zJZsNyV7LF-PHotzqvSGRAkN9bovg@mail.gmail.com>
Date: Tue, 27 Jan 2026 12:54:05 +0100
Message-ID: <CANS-=pd2+iqav=VKgON6R6XAs4rodNf+5gCgH=7EUPbTum3wWA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable
 in Strict Mode
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005fac5a06495d490f"
From: kjarli@gmail.com (Lynn)

--0000000000005fac5a06495d490f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 23, 2026 at 3:17=E2=80=AFPM Alexandre Daubois <
alex.daubois+php@gmail.com> wrote:

> I understand the concern about legacy code. However, if code relies on
> `(int) "123abc"` silently returning `123`, this represents a data
> integrity issue that would benefit from being made explicit. The
> deprecation period exists specifically to help identify and address
> these cases.
>
> > Does this behavior als affect parameters being passed in a non-strict
> fashion? Because then I don't see a realistic migration path within the
> next decade for this application.
>
> This behavior already exists and forbids such casts, see
> https://3v4l.org/WQJPv#vnull.
>

Thanks for your reply!

I've given it a bit more thought and while I 100% agree with the reasons
given, I'm still afraid this change is too big of an unknown break. I do
not have voting power, so all I can give is my opinion.

As an alternative, what about this? It could be the best of both worlds
where the new behavior is explicit:
```php
$var =3D (int) '123test'; // still works, nothing changes, becomes an `(int=
)
123`
int $var =3D '123test'; // follows the proposed rules, errors because it's
not a value that's a valid integer
int $var =3D '123'; // works because it's a valid integer format, becomes
(int) 123
int $var =3D (int) '123test'; // becomes (int) 123, existing behavior
```
This way nothing breaks and the casting remains what it is, but we can
still enforce correct types. I know the 3rd line might be controversial,
but it makes it an opt-in instead of opt-out feature and errors can be
thrown as of day 1.

Bonus:
```php
int|null $var =3D '123test'; // could result in `null` instead of throwing,
similar to the Enum tryFrom.

// could enable
MyEnum $foo =3D '123test';
MyEnum|null $bar =3D '123test';

// translates to
$foo =3D MyEnum::from('123test');
$bar =3D MyEnum::tryFrom('123test');
```

`from` and `tryFrom` could be taken as base for custom cast functions, but
that's probably a whole different can of worms.

--0000000000005fac5a06495d490f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jan 23,=
 2026 at 3:17=E2=80=AFPM Alexandre Daubois &lt;<a href=3D"mailto:alex.daubo=
is%2Bphp@gmail.com">alex.daubois+php@gmail.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">I understand the concern abou=
t legacy code. However, if code relies on<br>
`(int) &quot;123abc&quot;` silently returning `123`, this represents a data=
<br>
integrity issue that would benefit from being made explicit. The<br>
deprecation period exists specifically to help identify and address<br>
these cases.<br>
<br>
&gt; Does this behavior als affect parameters being passed in a non-strict =
fashion? Because then I don&#39;t see a realistic migration path within the=
 next decade for this application.<br>
<br>
This behavior already exists and forbids such casts, see<br>
<a href=3D"https://3v4l.org/WQJPv#vnull" rel=3D"noreferrer" target=3D"_blan=
k">https://3v4l.org/WQJPv#vnull</a>.<br></blockquote><div><br></div><div>Th=
anks for your reply!=C2=A0<br><br>I&#39;ve given it a bit more thought and =
while I 100% agree with the reasons given, I&#39;m still afraid this change=
 is too big of an unknown break. I do not have voting power, so all I can g=
ive is my opinion.</div><div><br></div><div>As an alternative, what about t=
his? It could be the best of both worlds where the new behavior is explicit=
:</div><div>```php</div><div>$var =3D (int) &#39;123test&#39;; // still wor=
ks, nothing changes, becomes an `(int) 123`</div><div>int $var =3D &#39;123=
test&#39;; // follows the proposed rules, errors because it&#39;s not a val=
ue that&#39;s a valid integer</div><div>int $var =3D &#39;123&#39;; // work=
s because it&#39;s a valid integer format, becomes (int) 123</div><div>int =
$var =3D (int) &#39;123test&#39;; // becomes (int) 123, existing behavior</=
div><div>```=C2=A0</div><div>This way nothing breaks and the casting remain=
s what it is, but we can still enforce correct types. I know the 3rd line m=
ight be controversial, but it makes it an opt-in instead of opt-out feature=
 and errors can be thrown as of day 1.</div><div><br></div><div>Bonus:</div=
><div>```php</div><div>int|null $var =3D &#39;123test&#39;; // could result=
 in `null` instead of throwing, similar to the Enum tryFrom.</div><div><br>=
</div><div>// could enable</div>MyEnum $foo =3D &#39;123test&#39;;<div>MyEn=
um|null $bar =3D &#39;123test&#39;;</div><div><br></div><div>// translates =
to</div>$foo =3D MyEnum::from(&#39;123test&#39;);<div>$bar =3D MyEnum::tryF=
rom(&#39;123test&#39;);</div><div>```</div><div><br></div><div>`from` and `=
tryFrom` could be taken as base for custom cast functions, but that&#39;s p=
robably a whole different can of worms.</div></div></div>

--0000000000005fac5a06495d490f--