Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119291
Return-Path: <george.banyard@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 57465 invoked from network); 17 Jan 2023 14:33:37 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 17 Jan 2023 14:33:37 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 72DDA1804AB
	for <internals@lists.php.net>; Tue, 17 Jan 2023 06:33:36 -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=0.6 required=5.0 tests=BAYES_50,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: <george.banyard@gmail.com>
Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41])
	(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 <internals@lists.php.net>; Tue, 17 Jan 2023 06:33:36 -0800 (PST)
Received: by mail-pj1-f41.google.com with SMTP id w4-20020a17090ac98400b002186f5d7a4cso37383279pjt.0
        for <internals@lists.php.net>; Tue, 17 Jan 2023 06:33:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=nkFUGV9J9EbiLnf+odJ4eyE55ikU9fmnW2lSaEBEaRc=;
        b=gPW8xO8bCU5NUCK/fAIj7MVI6AH3xsIvHxH408rRlO1xX4kBwze0n+Xy4dmLCAEuQR
         XXMDpqUCE8VN/Jqmi2/0DfXFZO9C3WbM2AcHo6ccQ61T/boxgyZ2al80xGUBciNrLfpF
         OOanCnxS7fM1fSjeFOMvS6yA8ZLK05az557iTa5lWdbl4ty1yFuKLhqnFr5R53RCvn0+
         1IG2KQoEuqR/Q3lCpJ9XHMSk51c0lClhcK0FAfHfP73KEmUxP8CmdJd4pgNE4WCzS3kB
         eJIHQsLwNR3Bsugt2QxAIQXiDrrX9r2srpkClNJClJZi8h+jwp8Cd7eBcjYYq+Dl/9rk
         M3Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=nkFUGV9J9EbiLnf+odJ4eyE55ikU9fmnW2lSaEBEaRc=;
        b=6gbfnJMV3qRd7wtC4X8DHHuAKpIxIH9KccQCovCMAazA/GQ5sxXCcIj+rfzJ0iF4L6
         MGblFgMAoY87gqYFiIvIPVV/GRqnrq3qPCAVfj8QulxZkw63F+3ZOiq+Hc9qwOeBo0fG
         tKT7V1vQ/JoHKW3U8vy5O/AwlTo/5D077MXr59FAx2oyxvkO0RNLxMTNRkurgiYzVYCC
         5sA5wdL7DU4YKnWN3x2VqDcT9hGs+CjZfhGM2NcVnzxMLf8o8mz32PCPiaBZckAQVw2/
         wlB6kTLw0IxTYsHFLpNxQ5XAtQKRF5cxlNToalG36V3C7Kmk7lOT4NF43IGTA7F/w5Nd
         1YOQ==
X-Gm-Message-State: AFqh2krwANG4aCova8jp8BusmL6T+ewo/hKvmN5EKbDliHFQdofrKOsw
	gnOUQdrBmQVoW4r4nitQ2AAr9bEketudrZJi/NtlMRUOHdY=
X-Google-Smtp-Source: AMrXdXsNWS4F0np/0GnSdykPwk6FF83Q+0wgyhMKGdNBOE50C5dFIfox8avYm9fny2swu/IWTnk4m+l/8JoDWsZU7vQ=
X-Received: by 2002:a17:90a:30d:b0:215:f80c:18e6 with SMTP id
 13-20020a17090a030d00b00215f80c18e6mr345940pje.45.1673966014759; Tue, 17 Jan
 2023 06:33:34 -0800 (PST)
MIME-Version: 1.0
Date: Tue, 17 Jan 2023 14:33:23 +0000
Message-ID: <CAFPFaMJdqBAoAPahvJJ5pEO3_BZ6rBx16G1OT41QudNxabRY-Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ad0e3405f2769548"
Subject: [PHP-DEV] [RFC] Saner array_(sum|product)()
From: george.banyard@gmail.com ("G. P. B.")

--000000000000ad0e3405f2769548
Content-Type: text/plain; charset="UTF-8"

Hello internals,

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.

Best regards,

George P. Banyard

--000000000000ad0e3405f2769548--