On Sun, Apr 6, 2025 at 9:52 AM Hans Henrik Bergan <divinit...@gmail.com>
wrote:
> Maybe a
> #[\SuppressUndefinedWarning]
>
> Parameter attribute could work, then everyone could implement their own
> blank() function with their own preferred logic
>
> Not sure if it's technically feasible tho, now the php engine would need
> to inspect the parameter attributes before deciding on generating a warning
> or not, idk how hard that would be.
>
> On Sat, Apr 5, 2025, 22:27 Iliya Miroslavov Iliev <i.mirosla...@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Apr 5, 2025 at 11:04 PM Rob Landers <rob@bottled.codes> wrote:
>>
>>> On Sat, Apr 5, 2025, at 14:15, Kayck Matias 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.
>>>
>>>
>>> I would personally advocate that empty() NEVER be used on strings. There
>>> are too many edge cases. As I said in an earlier message on the thread, if
>>> you want to know if a string is empty, just do $string == "" -- note the
>>> double equals, not triple equals. This matches null, an actual empty
>>> string, and false, but won't match anything else.
>>>
>>> *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
>>>
>>>
>>> I agree with most of these. I do not agree that " " (a space) is blank
>>> though. For people without last names, this is often their last name to
>>> pass validation on forms. As I said earlier, a simple loose check with an
>>> empty string is usually all you need, not empty().
>>>
>>> Best Regards,
>>> Kayck Matias ☕
>>>
>>>
>>> — Rob
>>>
>>
>> Just something that came into my mind. A "normal space" character is 32,
>> "non-breaking space" is 160 and a "zero width space" is 8203. These are all
>> characters so they are not blank and cannot be ignored
>> --
>> Iliya Miroslavov Iliev
>> i.mirosla...@gmail.com
>>
>
> then everyone could implement their own blank() function with their own
preferred logic
If this can still be implemented in userland you don't need logic
integrated at low level
--
Iliya Miroslavov Iliev
i.mirosla...@gmail.com
