Am 26.04.2022 um 11:54 schrieb Andreas Leathley<a.leath...@gmx.net>:
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
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
