Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119331 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 1609 invoked from network); 18 Jan 2023 19:52:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jan 2023 19:52:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 944181804B4 for ; Wed, 18 Jan 2023 11:52:56 -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_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-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (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 ; Wed, 18 Jan 2023 11:52:56 -0800 (PST) Received: by mail-pg1-f181.google.com with SMTP id e10so25332259pgc.9 for ; Wed, 18 Jan 2023 11:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mvd5QGDdNv/8DF3aNNOtZUdWD0LuMVOzw9yWwx6gvHI=; b=SJX7XU8rMidupynhzxMX4oNkOzApFvH3WUzA7rCtmYPCU8oD6lrXGoKezzUeDwxNZs 386ND+5BIvLsuvasY+Io1zpHdouGSlTj0t+5he3D0TlYDKC3Me5WJhTNJsRL4CdvbeNh RSjX5e8/ktB41aTGVI6xo8Oq8hEEuVlJrkmV/eNw+LrgnkHZYKmJMeauuFrHlpnz1Sab Iz3JHLTyYMgFC32vUpHqdIsOVX5t4/fICGULAqS5HulRBZbbe4j0oaAtrhT0CXViU+dL v/oYo9yVWiOS56S2fvxXHhSelyS5ZgDdq3ymE7FI4Ogz0nUVuBPNStAwdTLNvWfaiCjq riDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=mvd5QGDdNv/8DF3aNNOtZUdWD0LuMVOzw9yWwx6gvHI=; b=RPrO3nV3Zob571rW7cEq2W/tGvEeCR8xSKcVRYCIhWEy0jQ/YX3V1YUsa8Trz2cGGw qnSF8qY7eG63DzElutFz3wD6i//WCYO3DEIL+W8RMlqeFcjTdwihsAkb+3VjJgeh0ZiW bKRj6JroR0AMKNiddshOKuqgyDRBh0IEou1CW2a41S76RGRXwY1XxUBkFKLVFmBG/I2q Q/X9LsQFZRoOcChQnQ0YzM1pZM7V39PgqNU3gUtFS6drc9auuzTwha2/XzOZeY09j7sG fzmVMckvt7rZV4mFBuc8a4o8Q1F4ZuK8iNEx+HvH0WOCOcXLhbf/HmX0yADiapVCkTdd m2VQ== X-Gm-Message-State: AFqh2kp88yeCLbrcuj9KbqG61CIeJXRdunowWh75inegPhu0MDYmaEK0 o/SLHx9YTugFH6Atn1bX1LZnNf3d0Pck1bKRdk/rIrOgs9Q= X-Google-Smtp-Source: AMrXdXu651jO+DokXQF7teUZimrJXQLJyopTe9X3LKJEVDuHTavhI6zVDA4rNNrHTlQYm1pHaPJCz75dwXQkTGvJdBs= X-Received: by 2002:a05:6a00:1d23:b0:58d:b662:af11 with SMTP id a35-20020a056a001d2300b0058db662af11mr696223pfx.37.1674071574929; Wed, 18 Jan 2023 11:52:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 18 Jan 2023 19:52:43 +0000 Message-ID: To: Derick Rethans Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000008d68cb05f28f29e4" Subject: Re: [PHP-DEV] [RFC] Saner array_(sum|product)() From: george.banyard@gmail.com ("G. P. B.") --0000000000008d68cb05f28f29e4 Content-Type: text/plain; charset="UTF-8" On Wed, 18 Jan 2023 at 15:06, Derick Rethans wrote: > On Tue, 17 Jan 2023, G. P. B. wrote: > > > I would like to start the discussion about the Saner > > array_(sum|product)() RFC: > > https://wiki.php.net/rfc/saner-array-sum-product > > > > Currently, the array_sum() and array_product() behave differently than > > their userland implementation as they ignore arrays and objects, and > > cast the remaining types to int/float. This is in contrast with the > > behaviour of arithmetic operators that throw TypeErrors on types and > > values that are not interpretable as int/float. > > > > This RFC aims to resolve this discrepancy. > > I think I agree with the premise of this RFC, but I do think a few > details are wrongly addressed. > > First of all, a clarification why this produces int(4) would be useful: > > $input = [true, STDERR, new stdClass(), [], gmp_init(6)]; > $output = array_sum($input); > > I had to look up that STDERR would cast to int(3) :-) > ACK will clarify this. > I don't understand why this would result in a warning and a return of > int(50): > > $a = [10, 15.6, gmp_init(25)]; > var_dump(array_sum($a)); > > Why doesn't this return float(50.6) instead? I realise that the > array_reduce variant (below) does the same, but it's not what I would > expect: > > $input = [10, 15.6, gmp_init(25)]; > $output = array_reduce($input, fn($carry, $value) => $carry + > $value, 0); > The issue is that now when encountering an object, if it defines a do_operation handler, it will use that and not cast the value to a numeric type. I suppose it's possible to first check if the entry is an object and do a manual cast, which might also negate the next issue you mentioned. > I think the phrase "If traversing the array transforms the return value > into an object, if that object is not numerically castable an E_WARNING > is emitted and the initial return value is returned instead, which may > change the return value if scalar values were present in the array. " > should come with an example :-) > Within php-src we don't really have any "practical" examples, FFI\CData can possibly satisfy this condition by doing something like: $x = FFI::new("int[2]"); $x[0] = 10; $x[1] = 25; var_dump($x + 1); /* dumps: object(FFI\CData:int32_t*)#2 (1) { [0]=> int(25) } */ I constructed a special class and added it to zend_test to be able to test this behaviour, but will see if I can wrangle FFI to also show this case. Best regards, George P. Banyard --0000000000008d68cb05f28f29e4--