[RFC] Deprecate type juggling to and from bool type within the function type juggling context

Further, this makes a ton of shorthand nearly impossible — the manual casting to bool in strict mode is one of the most annoying casts someone has to do (and people screw up order of operations all the time leading to subtle bugs worse than coercion). Bringing this into all of php is probably not a good idea.

It would have been nice to showcase some of these shorthands rather than hiding them behind some sort of mystic as a counterargument.
I really would like to know in which cases you use non-boolean values as argument to boolean parameters.
People creating more subtle and worse bugs due to arbitrary casting is precisely why I want to unify the typing modes, so it's good to know that we think somewhat the same.

// From a real codebase (sanitized):
$shouldStop = (bool)($result = $service->doSomething($input)) && $result->isError();

This pattern comes up a lot in strict mode: you have to be extra careful with casts and parentheses, or you can end up with subtle bugs like accidentally always returning true/false, or masking null/error values. In looser modes, this just “worked”, but strictness can make it surprisingly easy to trip up.

I don't get it, you don't need a bool cast here: https://3v4l.org/J4BWi

Even with strict_types: https://3v4l.org/dhnpc

In my experience, a lot of “non-boolean to boolean” cases are legacy patterns or integrations, but sometimes we’re dealing with values that can be “falsy” in multiple ways (empty array, 0, '', etc.). Sometimes we’re adapting legacy code or writing wrappers that need to accept a wide range of inputs.

The problem, in my view, is that forcing strictness everywhere makes the simple, idiomatic code that worked in PHP for years much more verbose; and potentially more error-prone if the developer isn’t careful with casts or operator precedence.

This proposal has no intention of changing the type juggling behaviour of the logical binary operators (and unary ! op) so you shouldn't ever need to use both an operator and a cast (even now with strict_types on).

Best regards,
Gina P. Banyard

I don't understand what you mean.
The purpose is to deprecate the behaviour in 8.5 so that it can be removed in PHP 9.
We try to not break behaviour with no prior warning.
Could you clarify what you mean?

I meant to move the deprecation to PHP 9.0. I feel the impact of
deprecation itself in this case might be significant.

You feel there might be a lot of code passing floats, ints, or strings to
bool parameters? I'm doubtful this is the case, since static analysis tools
and IDEs are in much more widespread use nowadays.

In my experience passing non-boolean values to a bool parameter almost always
indicates a bug, and it would be valuable to get a deprecation notice sooner
rather than later so these mistakes can be fixed.

Regards,
Theodore

On Monday, 30 June 2025 at 10:26, Nicolas Grekas wrote:
...
The latter, cast-from-bool, I think they'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'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 the explicit cast (and shouldn't of course).

From my experience there is a very real benefit to deprecating both cast-from-bool and cast-to-bool.
Let me give an example of both.

Recently had to fix some legacy code where the result of filemtime was being passed to gmdate to format
the modification timestamp. filemtime returns false on failure, but this is silently coerced to zero
(a valid timestamp) when passed to the int parameter, which would result in the script continuing with bad
data instead of halting with a type error.

Cast-to-bool can cause the same kinds of issues, which are sometimes even harder to notice. Consider the following:

function processArray(array $items, bool $hasCertainKey) { ... }

$keyOrFalse = array_search('my value', $items);

processArray($items, $keyOrFalse);

It's very easy to miss the bug in this code, especially since it seems to function correctly as long as 'my value'
is not in the array, or is not the first item in the array. However, when it's at index 0 the key will be silently
coerced to false and the array will be incorrectly processed as though the value is not in the array.

I believe deprecating type juggling to/from bool will help avoid creating bugs like this (and likely
surface existing ones that should be fixed).

Kind regards,
Theodore

Le ven. 11 juil. 2025 à 13:00, Gina P. Banyard internals@gpb.moe a écrit :

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: the
change made sense from a language 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's not over yet. That made me say at conferences that this
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. While
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 the
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 communicate
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 probably
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 rules,
or have it as a secondary vote.

In the RFC, you write that its motivation is to allow making the bool type
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 justified
IMHO.

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
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 the
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 also
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 :)

Am 01.07.2025 um 14:40 schrieb Gina P. Banyard internals@gpb.moe:

The RFC talks about "from" AND "to" bool conversion but the examples under Backward Incompatible Changes only seem mention "from" bool, is that correct?

I didn't think adding examples for "to" bool was useful, but I can add some.

Thanks!

I tried the implementation in branch bool-juggling-dep-poc on https://github.com/Girgias/php-src.git and encountered two things:

• php -r 'strlen(false);' produced a core dump with Zend/zend_API.c:561: zend_arg_from_bool_deprecated: Assertion `func->common.fn_flags & (1 << 14)' failed.

I forgot to update the optimized strlen opcode, I pushed a fix for this, please pull in the latest version of the branch that has been force pushed.

Yes, that fixed it for me.

• array_slice($a, 1, preserve_keys:"a") did not produce a warning even though I would have thought that is a "to" bool conversion. Am I wrong? What should I test instead?

I haven't had time to look at why this is not triggering as it should. But some internal functions do weird stuff sometimes.

Not sure if it was a side-effect of the other fix or if you fixed more but the code above now correctly reports a warning.

Thanks again, my evaluation with our code base show very little impact so I'm positive about the change,

• Chris