[ * ] Historical tails

[gzhegow1991]

Description

What is historical purpose of these two:

<?php
var_dump((bool) '0'); // false (internally intval, ok)
var_dump((bool) ''); // false
var_dump((bool) '00'); // true (internally intval... what???)

Actually i agreed that:

• Any has NULL
• TRUE has FALSE (actually FALSE logically is data, and no-data...)
• 1/1.1 has 0 and NaN (still is_nan() magic and bugs here, somebody wrote standart that NaN equals nothing even itself... So why only NaN works that way then? Btw, returing NaN from json_decode() seems a great thing like "you cannot encode NaN in your JSON")
• 'hello' HAS ''
• ['1','2'] HAS []

Any type has "null/bad equivalent" to reduce count of types at input/output step and detect error via single IF comparison.

But why string with '0' equals to false - its not empty string, but empty value inside... Why 2 comparisons? And why 3rd case does the same different way...

So, the bug could be safely fixed, because every coder that knows this - write if ('' === $str) so nothing changed, thus who write if (! $str) logically loose nothing, just unexpected bug is fixed silently.

Why not? Whats dangerous?

<?php
// strpos('hello', 'abc') === false

I mean, why return "string or false" instead of "string or null" ? Why force to false check via IF preventing to chaining using null-coalesce operator?

Am not just about one function, actually tonns of functions in php returning 2 different types to show possible warning (!). Actually its converted to additional check at each step.

And in addition some functions raises fatals/warnings, so second check is required.
Some functions returned null where NULL is possible value (json_decode()) and needed 3rd check using if (json_last_error())...

Some functions like dates needs to try/catch them to check internal errors... As the result 4 possible layers of error catching.

I mean - whats the idea that function has few ways to indicate errors inside. So, if function throw fatal that can be catched up using "set_error_handler()" globally, and returns null, if ignored - whats wrong?

Maybe, to fully safe implement NaN type for any data here? I mean - if something wents wrong - function returned "data mailformed" internal type that equals nothing and breaks any typehint as fast as it can?

For me its like "warning" and "fatal". If function returned expected type (even empty data, unable to calculate, but its possible) - the whole flow should continue with empty result. If function is returned unexpected type or "data mailformed type" - the code should be stopped immediate even without handling of fatals or warnings.

PHP Version

PHP 8.0

Operating System

Win10 x64

[bwoebi]

It's more like "0" being special cased as a common representation of a falsy value (especially from query parameters and databases). "00" on the other hand isn't, and thus is true, like all other non-empty strings.

And yes, strpos is a fully historical issue.

[gzhegow1991]

It's more like "0" being special cased as a common representation of a falsy value (especially from query parameters and databases). "00" on the other hand isn't, and thus is true, like all other non-empty strings.

Ah, forgot that DB always returning strings... My bad...

[cmb69]

Note that changing either behavior requires the RFC process.