Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121533 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18220 invoked from network); 30 Oct 2023 15:59:41 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Oct 2023 15:59:41 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EC1B51804BC for ; Mon, 30 Oct 2023 08:59:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 30 Oct 2023 08:59:40 -0700 (PDT) Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-2800f7c8125so2093372a91.1 for ; Mon, 30 Oct 2023 08:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698681579; x=1699286379; 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=wYuUHo5Gu9drBE6MOpmys3MJrvc9Jx4bgsNXAfhfDqI=; b=dN0sp0/M0sM3e2VJt9DW/N43oipLczvCcVDfR9EWzCAPH6FA/t8arqh851wKR7NC0G sesiZPX7BMHpUEk2uYbnYnS2+z/Kfi49G/nVIkHYZ7NTp5kHJ81JPvLF8A4b+h7dnmbs H2ahneSeNYG6CSoWyfPVUXAhVubtWTNH8delmwhC+SD4UXTTc//TTaJON8J7MaQuAvAq 0T2h2mHZy5D2SoUxjCpqBg4WB8T4bTgnMgxklTCvRxgJheWj6x6mXy9QffjD2Y8rxckV 2F+/b5mtj/1bvqLohwj9HoQ1haWXNwKtbgf93ku3Rps/Eq74uKoEUZBRAA2Cy0levhbV yu4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698681579; x=1699286379; 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=wYuUHo5Gu9drBE6MOpmys3MJrvc9Jx4bgsNXAfhfDqI=; b=VM1Waq3h0jXWFvT7JwWSB/2sYlvC/q3F8jJY2Gf8m99PBHIR7nVUfUL6dMo7cMGN7i v+OyZzZMxohsHbILnKcKp3LgMclD+QrXcWjd/UMJIQjIyWWaYjb7JbF4gOJOw7G1ayeT +ACKXJh3CS2SAv3LhSaXq7CY+FuljE5MLRWL6go1yEEIYoGvnlNBuSS8SdZc6MJrHjx4 W7NvB85sXE4MPXP2441Mql0Nka2/Yf4tEKYgr6kUuZNnn/15nstvBdGZWFuIac9brS/u M/s4ONAUuceMMlyQdZViHTrclf1hmyxAekoa3wxYHs4PhAhZAhpKDam0shxD+mmdg8sv wTrQ== X-Gm-Message-State: AOJu0Yx+32jcgxkoo//k//kOz5S9asCPfhsdWLl/AjlWMmQKlWLmhB4X lRdiu9SrRu3qry7XmscMjAXGWzwNoGSabw6C77U= X-Google-Smtp-Source: AGHT+IFipcivduOrec/GFmA/AbkOloGz648EwGUsO/zDi8tokvwFDNKtWgo8KH5xd0yd+O0ygMP7wuZhOC6cYz2LmoQ= X-Received: by 2002:a17:90b:33c2:b0:280:7cd2:429 with SMTP id lk2-20020a17090b33c200b002807cd20429mr8300pjb.18.1698681579453; Mon, 30 Oct 2023 08:59:39 -0700 (PDT) MIME-Version: 1.0 References: <22ad21cc-f6ba-49e9-b1a9-8c73fe173648@gmail.com> In-Reply-To: Date: Mon, 30 Oct 2023 15:59:28 +0000 Message-ID: To: Lynn Cc: Marcos Marcolin , internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000002141ef0608f12011" Subject: Re: [PHP-DEV] New RFC : empty() function From: fenniclog@gmail.com (tag Knife) --0000000000002141ef0608f12011 Content-Type: text/plain; charset="UTF-8" > > This is exactly where the problem lies. Is a string with just whitespace > empty? Why would an ArrayObject with count 0 not be considered to be empty > while an array with count 0 is? "empty" is subjective and therefore not a > reliable function to use. Especially in legacy code I find that people use > `empty` where they should've been using `count() === 0` and have resulted > in bugs that weren't discovered until months or years later. The variations > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already > check all the scenarios you need, without risking funky bugs due to how the > internal check for "falsy" values works. > trust me, Ive worked on some terrible code bases that do exactly that and have variables redefined or dynamically assigned and you have to really check if it has been assigned a value or not and what value. It might be forgotten by everyone because of how far PHP has come but there is still extensive use of the @ suppressor and the alternative to empty would be if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){} empty() is 1 of 3 functions i believe that does not throw an undefined variable warning if you don't @ suppress the variable you are passing in. So if you want to get rid of empty, can we reignite the talks to finally get rid of @ --0000000000002141ef0608f12011--