Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127046 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 2B3651A00BC for ; Sat, 5 Apr 2025 14:32:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1743863416; bh=PrpwkF3hQOROQH3uMAEuHKBwhR56q3YyjxVA+OKM2io=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aP6AX7zdcitNc+UgFKa561F2knN/CdCrx2mGuuDehJdauxYcbkYBya9gRFDfWIZsV Z69WEDxz5twApxBwT4VGf7OicJ8mVxp05dYoACMG9kQ4oGgPywV5+WJG5+TkdTborC YU+UT035UBYQ9bmugKUHFH+8bUc2iHdQsHZ9I+jZaxqgqpU4rwcrrONSZfkbFwNxnR HtXNM/qLciRBJjbyyALY/kBt1WGv7qj5o3V7+ly2YlDRQeEsgI7xIB39l8F6q5Afoi SN0vOoWM68O8B0/briLmUxXzpzhetgDmAk90fctNcERHetbP5ApyzQzRU1oWgBT886 M/zqLDIM3XaNA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5F80618007E for ; Sat, 5 Apr 2025 14:30:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 5 Apr 2025 14:30:15 +0000 (UTC) Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-30bfed67e08so29309131fa.2 for ; Sat, 05 Apr 2025 07:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743863559; x=1744468359; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Lh7bvhAIXu5HvOJ6a7mhUeL3glyQhpOcBYHncT7ISJs=; b=KiYBiAc01EYb/miwgqQcQWLBTGQVX0X5vH8kc6ynEfZ6DyLQdKIYcymmHyyNe7xgZR uOdUa/4aa/rrXUQTBsJQBs+z95n/3Yagp7dPHEWgpkuvzUQR5ys6ljHsGE+L9J894w1O w7u9lt9yaWLy8xCVE9JZ+ylxgFM00WQ2Vx9KCLK1+ApmuYTGE7YeZ1i85k+KCO7ggzeA sZZeumFRmntb7iHv2ASl59pLwzrYChQT9LKFXgaBBBKA5bbEZTB/Hki81Z56urnYQHE0 zMG7GoBngQBwmzAAoKnSitEu7HtA0RprPJXnamPhXE83KDCWQNXDe6EMYOaYIu+Uth+/ m+Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743863559; x=1744468359; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Lh7bvhAIXu5HvOJ6a7mhUeL3glyQhpOcBYHncT7ISJs=; b=pAL9xQWV3GHrs3oc6+MocvropS4nR6nypu9op/bTTmCmc+O2SVybjPYKa7dBfj4nWa EHB1XfoPt2x1nBqa4qOOudkMCXoFE0RoNib8QcKnQlIofjJR7VovC2+MSHnhIs7NYuqB RUH4PQlm5S6rA6HC6GxApUkoq0AGty7+C6LWNH3fkc3iR671pESUN3JkFzlpBqM9/PLN 5zmAtBWZ0hwTaNh4YHOus/fCB/rInyRJMsz/G7e1qGdqfvGvgEhVYfRFwes2DjobCf5m +Vz44M6xpG0yFAb73OzM/UXywAmBsxNCS8VK+XfC31VeU06n2WO1BgDWB8hCltezlaei 65qg== X-Gm-Message-State: AOJu0Yy1NX3MRaW58BNEDWr5dXR7H5a/0cc0XLP15a6SDMRqRic+qIYs D3sdFhRuTX+4W5uUaULVl/1+Xm3hvAm5Z3Xb63bbpr1H3nMmzASGMl8Uz0PCPLXke8nvAHy2NVk UcUEI19yoBqym5JefuoKUrEGtQ05v1v6V X-Gm-Gg: ASbGncskkZyftv3OZidk7cNl3i+zKkcZl/kNg90/9wVwGEAp2p1JVIOj/Vqvn/hDGac +zjkUNdJweX1/KhaUv2rpOHHE36YrMhvIf1Kt3vpZyBbZ38cNnOxbPST4sSPK5DRz+ZDrwyLGN3 RNliaR0y1OYKYBANwy5Q2gZRT2 X-Google-Smtp-Source: AGHT+IEEXvPswzgHHg+tyQqhFYGfp0Lu1oJOCV93bWCdZTsAQFppCaKq3fTk7Mfs8mwqtfnzM4JuR0RIKwZbr4oUzAM= X-Received: by 2002:a2e:ad8a:0:b0:300:5c57:526b with SMTP id 38308e7fff4ca-30f0a108c9cmr19879351fa.11.1743863558646; Sat, 05 Apr 2025 07:32:38 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 5 Apr 2025 16:32:26 +0200 X-Gm-Features: ATxdqUHUW2LBWTmfF56WgHIOjv33NiLBwGBC5jF1CU_99OjvLES5ji-Xs6zQeuw Message-ID: Subject: Re: [PHP-DEV] RFC: blank() Function as a Complement to empty() To: Kayck Matias Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000f331e6063208df97" From: tekiela246@gmail.com (Kamil Tekiela) --000000000000f331e6063208df97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D=3D 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 wrote: > *INTRODUCTION* > This RFC proposes the addition of a new global function blank() to PHP=E2= =80=99s > 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 =E2=80=94 particul= arly 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 =E2=80=94 specifical= ly 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=E2=80=99s current toolset = for > handling =E2=80=9Cblank=E2=80=9D 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 =3D=3D=3D $value || > (empty($value) && '0' !=3D $value) || > (\is_string($value) && '' =3D=3D=3D \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 > 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 bett= er > 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=E2=80= =99d greatly > appreciate your guidance. > > If there=E2=80=99s interest in moving forward, I will prepare the full RF= C > documentation on the wiki along with an implementation patch and > appropriate tests. > > *Thanks in advance for your time and input!* > > > Best Regards, > Kayck Matias =E2=98=95 > --000000000000f331e6063208df97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Kayck,

Thanks for your proposal. Here are some points from me:

empty() is not a function, it's a language construct tha= t's a shorthand for !isset($var) || $var =3D=3D false.

While it has its uses empty() should be avoided whenever pos= sible. It's generally a sign of the programmer being lazy not doing pro= per 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 tha= t, your new function proposes rules that are unintuitive and very likely ap= plicable only to your project. Getting everyone to agree to these rules wou= ld 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 b= reak a lot of existing code. It's not inconceivable that people have de= fined 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 opinion= ated variation of it.

Thank you for the proposal and please don't be dishearte= ned by my strong opinion.

Regards,
Kamil


On Sat, Apr 5, 2025, 14:16 Kayck Matias <kayckmatias04@gmail.com> wrote:
I= NTRODUCTION
This RFC proposes the addition of a new global fu= nction=C2=A0blank()=C2=A0to PHP=E2=80=99s core, intended to pr= ovide a more intuitive and context-sensitive way of checking for "blan= k" values. This function is=C2=A0not a replacement=C2= =A0for=C2=A0empty(), but a=C2=A0complementary tool=C2=A0to help developers more accurately evaluate user input, query parameters, = and form values =E2=80=94 particularly in situations where=C2=A0empty= ()=C2=A0may behave in unintuitive ways.

MOTIVATION
The motivation for this RFC arose from a r= eal-world issue I encountered at work involving query string filtering =E2= =80=94 specifically when using the string=C2=A0"0"= =C2=A0as a filter value. Because=C2=A0empty("0")=C2= =A0evaluates to=C2=A0true, the logic skipped this valid input,= causing incorrect behavior in the application. This highlighted a gap in P= HP=E2=80=99s current toolset for handling =E2=80=9Cblank=E2=80=9D values in= a more semantic and intention-aligned way.

PROPOSAL
The proposed=C2=A0blank()=C2=A0function will behave similarly to=C2=A0empty(), but w= ith semantics better suited for filtering, validation, and user input. Its = primary goals are:

  • To treat= whitespace-only strings as blank (e.g.,=C2=A0" ").<= /p>

  • To treat=C2=A0"0"= =C2=A0(string zero) and=C2=A00=C2=A0(int zero) as=C2=A0= not blank, unlike=C2=A0empty().

  • To support clearer, intention-driven logic whe= n working with dynamic input, especially in query strings and HTTP forms.

Function Sign= ature

function blank(mixed $value): bool;

Logic (PHP version)
function blank(mixed $value):=
 bool
{
    if (
        false =
=3D=3D=3D $value ||
   =
     (empty($value) && '0' !=3D $value) ||
        (\is_string($value) && '' =3D=3D=3D \trim($value))
    ) {
        return true=
;
    }

    return false;
}
Examples
echo=C2=A0blank(null);=C2=A0// true=
echo=C2=A0blank(false);=C2=A0// true
echo=C2=A0blank("");=C2=A0// true
echo=C2=A0blank("= =C2=A0");=C2=A0// true
echo=C2=A0blank([]);=C2=A0// true

echo=C2= =A0blank(0);=C2=A0// = false
echo= =C2=A0blank("0<= /span>");=C2=A0// false
echo=C2=A0b= lank("test");=C2=A0// false
echo=C2=A0blank([0]);=C2=A0// false

BACKWARDS IN= COMPATIBLE CHANGES
This feature is fully backward-compatible.= It does not alter existing behavior of any function or construct, nor does= it redefine=C2=A0empty(). It introduces a new global function= and does not break any existing code.


<= /div>
RFC IMPACT
  • CLI & Web usage: This function will be available glob= ally, 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 r= equired.

  • New constants: None introduced.

This function is expected to impro= ve=C2=A0code clarity and correctness=C2=A0in real-world ap= plications, without burdening the language with complexity.


<= p>COMMUNITY FEEDBACK
Multiple developers have voiced concerns reg= arding empty() in real-world scenarios. A key example is PHP Issue=C2=A0#9845=C2=A0on GitHub, where it's reported that:

=

"empty("0") returns true when it should return false.&quo= t;

This discussion highlights a recurring problem: developers often e= xpect '0' to be treated as a valid, non-empty input (e.g., in filte= ring query strings), but empty() evaluates it as false. This leads to condi= tional logic silently skipping valid inputs.

The blank() function= is designed to directly address this gap, offering a more semantic and hum= an-friendly approach to "blankness" that aligns better with what = developers actually expect in these cases.


NEXT STEPSThis is my first RFC proposal,=C2=A0If there are any issues with the = approach, naming, scope, or anything I may have overlooked, I=E2=80=99d gre= atly appreciate your guidance.

If there=E2=80=99s interest in moving = forward, I will prepare the full RFC documentation on the wiki along with a= n implementation patch and appropriate tests.

Thanks in adv= ance for your time and input!


<= div>
Best Regard= s,
Kayck Matias=C2=A0=E2=98=95
--000000000000f331e6063208df97--