Hi Kayck,
Thanks for your proposal. Here are some points from me:
empty() is not a function, it's a language construct that's a shorthand for
!isset($var) || $var == false.
While it has its uses empty() should be avoided whenever possible. It's
generally a sign of the programmer being lazy not doing proper data
validation/type checking.
The zero-string being considered falsey isn't limited to empty(). It's just
how PHP types work. Introducing a new function with slightly different
semantics would create tons of confusion. On top of that, your new function
proposes rules that are unintuitive and very likely applicable only to your
project. Getting everyone to agree to these rules would be near impossible.
You can very easily create this function in global scope in your project
but introducing this at the language level would potentially break a lot of
existing code. It's not inconceivable that people have defined such a
function in global scope in their projects already.
My stance is that I am categorically against it even if the semantics would
have been more ironed out. Unless PHP is about to phase out loose
comparison, we don't need a new function that is just an opinionated
variation of it.
Thank you for the proposal and please don't be disheartened by my strong
opinion.
Regards,
Kamil
On Sat, Apr 5, 2025, 14:16 Kayck Matias <[email protected]> wrote:
> *INTRODUCTION*
> This RFC proposes the addition of a new global function blank() to PHP’s
> core, intended to provide a more intuitive and context-sensitive way of
> checking for "blank" values. This function is *not a replacement* for
> empty(), but a *complementary tool *to help developers more accurately
> evaluate user input, query parameters, and form values — particularly in
> situations where empty() may behave in unintuitive ways.
>
>
>
> *MOTIVATION*The motivation for this RFC arose from a real-world issue I
> encountered at work involving query string filtering — specifically when
> using the string "0" as a filter value. Because empty("0") evaluates to
> true, the logic skipped this valid input, causing incorrect behavior in
> the application. This highlighted a gap in PHP’s current toolset for
> handling “blank” values in a more semantic and intention-aligned way.
>
> *PROPOSAL*
> The proposed blank() function will behave similarly to empty(), but with
> semantics better suited for filtering, validation, and user input. Its
> primary goals are:
>
> -
>
> To treat whitespace-only strings as blank (e.g., " ").
> -
>
> To treat "0" (string zero) and 0 (int zero) as *not blank*, unlike
> empty().
> -
>
> To support clearer, intention-driven logic when working with dynamic
> input, especially in query strings and HTTP forms.
>
> Function Signature
>
> function blank(mixed $value): bool;
>
> Logic (PHP version)
>
> function blank(mixed $value): bool
> {
> if (
> false === $value ||
> (empty($value) && '0' != $value) ||
> (\is_string($value) && '' === \trim($value))
> ) {
> return true;
> }
>
> return false;
> }
>
> Examples
> echo blank(null); // true
> echo blank(false); // true
> echo blank(""); // true
> echo blank(" "); // true
> echo blank([]); // true
>
> echo blank(0); // false
> echo blank("0"); // false
> echo blank("test"); // false
> echo blank([0]); // false
>
> *BACKWARDS INCOMPATIBLE CHANGES*
> This feature is fully backward-compatible. It does not alter existing
> behavior of any function or construct, nor does it redefine empty(). It
> introduces a new global function and does not break any existing code.
>
>
> *RFC IMPACT*
>
> -
>
> *CLI & Web usage*: This function will be available globally, in both
> CLI and Web SAPI contexts.
> -
>
> *Core behavior*: The function is small, simple, and does not interfere
> with any existing language behavior or constructs.
> -
>
> *php.ini*: No changes required.
> -
>
> *New constants*: None introduced.
>
> This function is expected to improve *code clarity and correctness* in
> real-world applications, without burdening the language with complexity.
>
>
>
> *COMMUNITY FEEDBACK*Multiple developers have voiced concerns regarding
> empty() in real-world scenarios. A key example is PHP Issue #9845
> <https://github.com/php/php-src/issues/9845>
> on GitHub, where it's
> reported that:
>
> "empty("0") returns true when it should return false."
>
> This discussion highlights a recurring problem: developers often expect
> '0' to be treated as a valid, non-empty input (e.g., in filtering query
> strings), but empty() evaluates it as false. This leads to conditional
> logic silently skipping valid inputs.
>
> The blank() function is designed to directly address this gap, offering a
> more semantic and human-friendly approach to "blankness" that aligns better
> with what developers actually expect in these cases.
>
>
>
> *NEXT STEPS*This is my first RFC proposal, If there are any issues with
> the approach, naming, scope, or anything I may have overlooked, I’d greatly
> appreciate your guidance.
>
> If there’s interest in moving forward, I will prepare the full RFC
> documentation on the wiki along with an implementation patch and
> appropriate tests.
>
> *Thanks in advance for your time and input!*
>
>
> Best Regards,
> Kayck Matias ☕
>