Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119310 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 57568 invoked from network); 18 Jan 2023 15:06:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jan 2023 15:06:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 286111804AA for ; Wed, 18 Jan 2023 07:06:44 -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=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS30827 82.113.144.0/20 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Wed, 18 Jan 2023 07:06:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id E59AA10C3A9; Wed, 18 Jan 2023 15:06:42 +0000 (GMT) Date: Wed, 18 Jan 2023 15:06:42 +0000 (GMT) X-X-Sender: derick@singlemalt.home.derickrethans.nl To: "G. P. B." cc: PHP internals In-Reply-To: Message-ID: References: User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [PHP-DEV] [RFC] Saner array_(sum|product)() From: derick@php.net (Derick Rethans) 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) :-) 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: $carry + $value, 0); 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 :-) cheers, Derick