Am 26.04.2022 um 11:54 schrieb Andreas Leathley<>:

I have not found any past proposals or discussions to change boolean
coercions, so I would like to find out how the thoughts on internals are
to change this, or if there are any reasons not to change this that I
have not thought of.

I was actually thinking about this the other day, in the context of adding new cast functions which reject more values than our current explicit casts.

For integers, I can think of several levels of casts / type checks that you could theoretically define:

0) Plain type checking, no cast or coercion
1) Non-lossy casts, e.g. (string)(int)'42' === '42'
2) Unambiguous casts, e.g. (int)'42.0', (int)' 42 '
3) Best-guess casts, e.g. (int)'99 red balloons' === 99, (int)'1e3' === 1000
4) Zero failures, e.g. (int)'hello' === 0

When I started thinking about booleans, it was much harder to define what makes sense. I've certainly seen new programmers confused that (bool)'false' is true, and having it error would usually be more helpful; but (bool)'on' being true is useful when dealing with HTML forms, for instance.

On 26/04/2022 13:47, Christian Schneider wrote:
And would !empty($foo) even work in your world or how would empty() be defined?

That's an interesting question; but I think it would be OK for empty() to match with an *explicit* boolean cast, and both continue to accept all values, while *implicit* casts become more strict. This is how integers already work - (int)'hello' === 0, but passing 'hello' to an int parameter is an error regardless of mode, as is 'hello' + 1


Rowan Tommins

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:

Reply via email to