Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128061
Precedence: bulk
MIME-Version: 1.0
References: <3Yl0UGauXmKqk7s7Hqbv6iaXru-hZHf8Wj6VjwwihgRSaqZo5EZ2ndsOle-ae41C-lvnirynWt6PpuD7UJPL0zPCw18QHFE81Eb--fiiEbc=@gpb.moe>
 <bvjVobCbLKyWiVoKMNH_rtLH0_qZ5Jf2zi9FPqqpaIXNwNXi-niyI4yPc5SgLn0clNXeRvOLo0KWS2ma2o3CTMmczL5anK8G_56xi1wFegg=@gpb.moe>
 <CAOWwgpkO6CT2bD1zQ0fgg3PhmK8_TcmOpjyv3ML8HSfoFiRzsQ@mail.gmail.com> <XPhXQ7Qyp5Hwsr7C_2wl_trI8-M952asnpuVm_vo1ZinIovY3ecKNvR1udU_E6GHFSWnku7Na6Ig1PnaPJkLpJIbJXf_nMeBYPPulalOmYs=@gpb.moe>
In-Reply-To: <XPhXQ7Qyp5Hwsr7C_2wl_trI8-M952asnpuVm_vo1ZinIovY3ecKNvR1udU_E6GHFSWnku7Na6Ig1PnaPJkLpJIbJXf_nMeBYPPulalOmYs=@gpb.moe>
Date: Tue, 15 Jul 2025 20:11:23 +0200
Message-ID: <CAOWwgpnaJCF9VLCONo3GAYdW8ekgQuU3=3ZYkMx1up6jpmqP=w@mail.gmail.com>
Subject: Re: [PHP-DEV][RFC] Deprecate type juggling to and from bool type
 within the function type juggling context
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ed4cef0639fbb42e"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000ed4cef0639fbb42e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le ven. 11 juil. 2025 =C3=A0 13:00, Gina P. Banyard <internals@gpb.moe> a =
=C3=A9crit :

>
> On Monday, 30 June 2025 at 10:26, Nicolas Grekas <
> nicolas.grekas+php@gmail.com> wrote:
>
> Hi Gina
>
> Thanks for experimenting with this on
> https://github.com/symfony/symfony/pull/60890/files
>
> It's good to see that fitting this RFC requires a relatively small number
> of lines to change even on a codebase like Symfony. We're not at 100% but
> still nice.
>
> Yet, it IS a big bang in terms of deprecations to fix that this will
> trigger. Their number is super high, because these boolean conversions
> happen on hotpath / in loops.
>
> This reminds me of the mandatory "?" for arguments with null defaults: th=
e
> change made sense from a language design PoV, but the impact was, and sti=
ll
> is very high. It was and still is a very costly deprecation for the
> community, and it's not over yet. That made me say at conferences that th=
is
> was maybe not a good idea...
>
> Looking at the diff above, I think I can draw two sets of changes:
> 1. the ones that patch a cast-to-bool
> 2. the ones that patch a cast-from-bool
>
> The latter, cast-from-bool, I think they're all useful improvements. Whil=
e
> most likely harmless in all the specific cases of the PR, doing e.g. an
> strpos() on false feels hardly legit. I'm therefore sympathetic to making
> these changes.
>
> For cast-to-bool, I'm WAY less convinced. From the PR above, explicit
> casts like "return (bool) preg_match(...)" on a method that returns a
> "bool" or "(bool) ($this->loggedErrors & $type)" are a clear downgrade:
> it makes the typing PHP just more verbose without any real benefit. That
> doesn't look worth asking the whole ecosystem to fix those deprecations. =
It
> is especially hard to see this as an improvement when comparing to using
> the same expressions with e.g. the "if ()" operator, which doesn't need t=
he
> explicit cast (and shouldn't of course).
>
>
> Every cast-to-bool example you are providing are int-to-bool coercions,
> not string nor float casts type.
>

That's correct. I feel quite strongly about this: int-to-bool casts should
be handled gracefully by the engine seamlessly. Deprecating them will (plan
to) break many apps that are just fine, and as Rob wrote (and you also in a
gist), casting to (bool) is what many will do, wrongly. This won't improve
the language, quite the contrary.

About string-to-bool PHP is still that language that allows quickly
consuming $_GET['foo'] as whatever it looks like as a string. I suspect
tons of codebases rely on this behavior. To me, that's where the costs
might outweigh the benefits...

Especially that even within SFs test suite, various cases of string-to-bool
> casts seems to be highlighting some sort of bug in the test suite.
> Moreover, the fixes for the bitwise & operator are following the styles
> from surrounding functions that _already_ do that, and I was slightly
> confused about the inconsistencies.
>

That's an inconsistency favored by the strict-mode hype: people blindly
cast (and introduce bugs)... That inconsistency should be fixed the other
way around: removing these needless (and dangerous) casts.


> The preg_match() API is just unfortunate that it returns a boolean value
> as integers rather than booleans, as it uses a false return to communicat=
e
> it emitted a warning instead of null.
>

Unfortunate but still to be acknowledged as a likely contribution to making
this RFC a high-cost one for userland.


> Improving this API, is a very orthogonal problem to this, that we probabl=
y
> should be doing anyway (e.g. see if we can promote the warnings to
> exceptions).
> And I could be convinced to carve out an exception for int-to-bool,
> however that retains some complexity remembering PHP's type juggling rule=
s,
> or have it as a secondary vote.
>
> In the RFC, you write that its motivation is to allow making the bool typ=
e
> equivalent to the true|false union. To do so you propose to make the bool
> type always behave like in "strict" mode.
>
> Personally, I'm moot about the motivation. I understand it, but it looks
> inappropriate to push deprecations from this somewhat (IMHO) theoretical
> angle. The added friction would need way stronger arguments to be justifi=
ed
> IMHO.
>
> Would it be possible to trigger the deprecation only in the cast-from-boo=
l
> direction, and accept casts-to-bool as seamlessly as there are now? If ye=
s,
> then would it also be possible to make the true and false types have the
> same behavior (aka non-strict in casts-to-bool direction - when not in
> strict mode of course)? If yes to both questions, then that'd look like a
> better outcome that'd still allow fulfilling your goal, while providing
> maximum value to the community.
>
> As is, the cost/benefit ratio doesn't make this RFC look worth it to me.
>
>
> As said above, it is even possible to only warn on string- and
> float-to-bool and not on int-to-bool coercions.
> But I still think theoretical angles are important, because allowing edge
> cases always adds complexity that has causes us countless headaches in th=
e
> past.
>
> Last but not least, I'm not sure it's a good idea to rush this into 8.5.
> This is a high-impact change. We should give some time to the discussion,
> understand the impact and explore variants. Merging this in 8.6 would als=
o
> give a few more months for open-source projects to adapt to the change
> (since many do run their CI with the master branch of PHP to spot changes
> as early as possible.)
>
>
> I'm not exactly certain I buy the argument that delaying this deprecation
> is worthwhile, especially as I don't really think is as high impact as it
> is made out to be.
>

Deprecating implicit null-ness was (still is) a high impact deprecation,
and this one has a higher potential impact IMHO.


> And I don't really see what "variants" there are to explore other than a
> possible allowance for int-to-bool.
>

The variant I suggested is to relax the true and false types and make them
not-strict when not in strict-mode. Your motivation for the RFC is to make
the bool type equivalent to true|false. This can be achieved by relaxing
true and false types.

Nicolas
PS: what about null-forwarding cast operators? (?bool) to let null get
through the cast? Just throwing in case it reaches anyone :)

--000000000000ed4cef0639fbb42e
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">Le=C2=A0ven. 11=
 juil. 2025 =C3=A0=C2=A013:00, Gina P. Banyard &lt;internals@gpb.moe&gt; a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br><div>
        On Monday, 30 June 2025 at 10:26, Nicolas Grekas &lt;<a href=3D"mai=
lto:nicolas.grekas%2Bphp@gmail.com" target=3D"_blank">nicolas.grekas+php@gm=
ail.com</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>Hi Gina</div><br><div class=3D"gmail_quot=
e"><div>Thanks for experimenting with this on <a href=3D"https://github.com=
/symfony/symfony/pull/60890/files" rel=3D"noreferrer nofollow noopener" tar=
get=3D"_blank">https://github.com/symfony/symfony/pull/60890/files</a></div=
><div><br></div><div>It&#39;s good to see that fitting this RFC requires a =
relatively small number of lines to change even on a codebase like Symfony.=
 We&#39;re not at 100% but still nice.</div><div><br></div><div>Yet, it IS =
a big bang in terms of deprecations to fix that this will trigger. Their nu=
mber is super high, because these boolean conversions happen on hotpath / i=
n loops.</div><div><br></div><div>This reminds me of the mandatory &quot;?&=
quot; for arguments with null defaults: the change made sense from a langua=
ge design PoV, but the impact was, and still is very high. It was and still=
 is a very costly deprecation for the community, and it&#39;s not over yet.=
 That made me say at conferences that this was maybe not a good idea...</di=
v><div><br></div><div>Looking at the diff above, I think I can draw two set=
s of changes:</div><div>1. the ones that patch a cast-to-bool</div><div><di=
v>2. the ones that patch a cast-from-bool</div><div><br></div><div>The latt=
er, cast-from-bool, I think they&#39;re all useful improvements. While most=
 likely harmless in all the specific cases of the PR, doing e.g. an strpos(=
) on false feels hardly legit. I&#39;m therefore sympathetic to making thes=
e changes.</div><div><br></div><div>For cast-to-bool, I&#39;m WAY less conv=
inced. From the PR above, explicit casts like &quot;return (bool) preg_matc=
h(...)&quot; on a method that returns a &quot;bool&quot; or &quot;<span><sp=
an>(</span><span>bool</span><span>) (</span><span><span>$</span><span>this<=
/span></span>-&gt;<span>loggedErrors</span> &amp; <span><span>$</span>type<=
/span><span>)&quot; are a clear downgrade: it makes the typing PHP just mor=
e verbose without any real benefit. That doesn&#39;t look worth asking the =
whole ecosystem to fix those deprecations. It is especially hard to see thi=
s as an improvement when comparing to using the same expressions with e.g. =
the &quot;if ()&quot; operator, which doesn&#39;t need the explicit cast (a=
nd shouldn&#39;t of course).</span></span></div></div></div></div></blockqu=
ote><div><br></div><div>Every cast-to-bool example you are providing are in=
t-to-bool coercions, not string nor float casts type.</div></div></div></bl=
ockquote><div><br></div><div>That&#39;s correct. I feel quite strongly=C2=
=A0about this: int-to-bool casts should be handled gracefully by the engine=
 seamlessly.=C2=A0Deprecating them will (plan to) break many apps that are =
just fine, and as Rob wrote (and you also in a gist), casting to (bool) is =
what many will do, wrongly. This won&#39;t improve the language, quite the =
contrary.</div><div><br></div><div>About string-to-bool PHP is still that l=
anguage that allows quickly consuming $_GET[&#39;foo&#39;] as whatever it=
=C2=A0looks like as a string. I suspect tons of codebases rely on this beha=
vior. To me, that&#39;s where the costs might outweigh=C2=A0the benefits...=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px"><div><div>Especially=
 that even within SFs test suite, various cases of string-to-bool casts see=
ms to be highlighting some sort of bug in the test suite.</div><div>Moreove=
r, the fixes for the bitwise &amp; operator are following the styles from s=
urrounding functions that _already_ do that, and I was slightly confused ab=
out the inconsistencies.</div></div></div></blockquote><div><br></div><div>=
That&#39;s an inconsistency favored by the strict-mode hype: people blindly=
 cast (and introduce bugs)... That inconsistency should be fixed the other =
way around: removing these needless (and dangerous) casts.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-=
family:Arial,sans-serif;font-size:14px"><div><div>The preg_match() API is j=
ust unfortunate that it returns a boolean value as integers rather than boo=
leans, as it uses a false return to communicate it emitted a warning instea=
d of null.</div></div></div></blockquote><div><br></div><div>Unfortunate=C2=
=A0but still to be acknowledged as a likely contribution to making this RFC=
 a high-cost one for userland.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font=
-size:14px"><div><div>Improving this API, is a very orthogonal problem to t=
his, that we probably should be doing anyway (e.g. see if we can promote th=
e warnings to exceptions).</div><div>And I could be convinced to carve out =
an exception for int-to-bool, however that retains some complexity remember=
ing PHP&#39;s type juggling rules, or have it as a secondary vote.</div><di=
v><span><span><br></span></span></div><blockquote type=3D"cite"><div dir=3D=
"ltr"><div class=3D"gmail_quote"><div><div>In the RFC, you write that its m=
otivation is to allow making the bool type equivalent to the true|false uni=
on. To do so you propose to make the bool type always behave like in &quot;=
strict&quot; mode.</div><div><br></div><div>Personally, I&#39;m moot about =
the motivation. I understand it, but it looks inappropriate to push depreca=
tions from this somewhat (IMHO) theoretical angle. The added friction would=
 need way stronger arguments to be justified IMHO.</div><div><br></div><div=
>Would it be possible to trigger the deprecation only in the cast-from-bool=
 direction, and accept casts-to-bool as seamlessly as there are now? If yes=
, then would it also be possible to make the true and false types have the =
same behavior (aka non-strict in casts-to-bool direction - when not in stri=
ct mode of course)? If yes to both questions, then that&#39;d look like a b=
etter outcome that&#39;d still allow fulfilling your goal, while providing =
maximum value to the community.</div><div><span><br></span></div><div><span=
>As is, the cost/benefit ratio doesn&#39;t make this RFC look worth it to m=
e.</span></div></div></div></div></blockquote><div><br></div><div>As said a=
bove, it is even possible to only warn on=C2=A0string- and float-to-bool an=
d not on int-to-bool coercions.</div><div>But I still think theoretical ang=
les are important, because allowing edge cases always adds complexity that =
has causes us countless headaches in the past.</div><div><br></div><blockqu=
ote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><div>Las=
t but not least, I&#39;m not sure it&#39;s a good idea to rush this into 8.=
5. This is a high-impact change. We should give some time to the discussion=
, understand the impact and explore variants. Merging this in 8.6 would als=
o give a few more months for open-source projects to adapt to the change (s=
ince many do run their CI with the master branch of PHP to spot changes as =
early as possible.)</div></div></div></div></blockquote><div><br></div><div=
>I&#39;m not exactly certain I buy the argument that delaying this deprecat=
ion is worthwhile, especially as I don&#39;t really think is as high impact=
 as it is made out to be.</div></div></div></blockquote><div><br></div><div=
>Deprecating implicit null-ness was (still is) a high impact deprecation, a=
nd this one has a higher potential impact IMHO.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Aria=
l,sans-serif;font-size:14px"><div><div>And I don&#39;t really see what &quo=
t;variants&quot; there are to explore other than a possible allowance for i=
nt-to-bool.</div></div></div></blockquote><div><br></div><div>The variant I=
 suggested is to relax the true and false types and make them not-strict wh=
en not in strict-mode.=C2=A0Your motivation for the RFC is to make the bool=
 type equivalent to true|false. This can be achieved by relaxing true and f=
alse types.</div><div>=C2=A0</div></div><div class=3D"gmail_quote gmail_quo=
te_container">Nicolas</div><div class=3D"gmail_quote gmail_quote_container"=
>PS: what about null-forwarding cast operators? (?bool) to let null get thr=
ough the cast? Just throwing in case it reaches anyone :)</div></div>

--000000000000ed4cef0639fbb42e--