Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121667 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69069 invoked from network); 14 Nov 2023 01:08:21 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Nov 2023 01:08:21 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1D138180504 for ; Mon, 13 Nov 2023 17:08:19 -0800 (PST) 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_H2,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-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (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, 13 Nov 2023 17:08:18 -0800 (PST) Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3b3e13fc1f7so3116763b6e.0 for ; Mon, 13 Nov 2023 17:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699924097; x=1700528897; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=jOtWuw7kcUHD+hpRrgsx1KKu2aHWTFumhM481IkAka4=; b=HthRp15LmcrOjFtqZFOTQijX7fKCb5wGrNDc1TUkEq2KVAeRJRCvr3aLIMAT0/uqUc fjOr4wYBRGwblq/L+Vgc2pllWwqBFHKqlaJAOvRffp4v0NblhGKqCcC7Fc2HJ3Xg8psJ ZacBPH91v+57b+z/B9xlTe6uhSOkkhqDiLRUG6UQbANtnZ1da+q/jnKZv5paIonMmW1w P3X8BpaNwIRee+b/IzSS57eFXOxdmWtwtw3jtqgY9OkBsS3l5U6oOBYDIMZGDbxC5+Fz Yn6yzar5EOQdBTXSX2rhVXnxZGBiaUAs949/DPAbyx/C7Gzp/L6MZhaxmgL7n0yCDziG 4biA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699924097; x=1700528897; h=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=jOtWuw7kcUHD+hpRrgsx1KKu2aHWTFumhM481IkAka4=; b=C4V3+WPCiymxeiwjuGSwuKh3Lt/e0vARFpqmaP3b9FMlDbIN1pOO47e+bcKt/WPon6 4E13M9Y2oSNtc9zw4S3PJwW1c90fX8/Fqp9y6KOsLJugjwLEZ6bsisJWUd02kjoqjsXZ uv7ZYdmJdJRBoWRR9Zo7ABjphFy3SAd1zl9TOiHKppQ5mbVFYd0f0Z8pHKssXGNtWkt5 uk6PFS1d2mEt4dxG1XQGrEA8JaMkxZCp25jkIlYKubZs35ZACLcDXU6wqDAByv8nybav +RxrUitIjjAbYuo0FW0EJ/zlih2tm/Td/8JKthlJQJFmNZk4hgIETXKI9tOxrqs3tm8j IvtA== X-Gm-Message-State: AOJu0Yx92xogP3facnluM7v9X8iYnLRBlAc40QT4AjtlKFYstehio+53 WGj3hphX+TrTdWkklZMBIDK/5JfGWd6UUpnimRFphkZT X-Google-Smtp-Source: AGHT+IHTqaVt1g3hPajo47ORdACtp3nkupuPAUNY7WJ9RYpvBEnqCiVM8Ll8pGzkhPSY/HJDuCaWYN6Tbt+5Wd9kcFk= X-Received: by 2002:a05:6808:8cd:b0:3ae:2362:7137 with SMTP id k13-20020a05680808cd00b003ae23627137mr8632638oij.59.1699924097664; Mon, 13 Nov 2023 17:08:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 14 Nov 2023 01:08:06 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000fc8d8c060a126b79" Subject: Re: [PHP-DEV] Array functions with strict comparison From: davidgebler@gmail.com (David Gebler) --000000000000fc8d8c060a126b79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2023 at 8:20=E2=80=AFPM Andreas Hennings wrote: > So to me, this alone is an argument to implement this natively. > The other argument is that it is kind of sad how the current functions > don't behave as one would expect. I'd expect there to be a larger and proportionately increasing performance difference between array_diff versus array_udiff with callback or a userland array_diff_strict function the larger the datasets you feed in. But I'm not sure how common either the use case of diffing arrays of 25,000 or 250,000 elements might be, or needing this comparison to be strict equality. I suspect the use case where both these conditions apply is very rare. But if you want to create an RFC, please go for it. You could add an extra parameter to these functions after the input arrays, which was a flag for strict comparison. Whether such a thing with a default value of non-strict (so not BC breaking) would be considered preferable to new global functions, I'm not sure. I'd probably go with new functions but maybe someone else will weigh in with their thoughts. --000000000000fc8d8c060a126b79--