Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119750 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35896 invoked from network); 28 Mar 2023 07:19:24 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Mar 2023 07:19:24 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EC8B11804A9 for ; Tue, 28 Mar 2023 00:19:22 -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=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15623 212.45.192.0/19 X-Spam-Virus: No X-Envelope-From: Received: from mail.gna.ch (mail.gna.ch [212.45.196.109]) (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 ; Tue, 28 Mar 2023 00:19:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id 8DDE23A1DCB for ; Tue, 28 Mar 2023 09:19:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mail.gna.ch ([127.0.0.1]) by localhost (darkcity.gna.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYaqKFP1GxGe for ; Tue, 28 Mar 2023 09:19:19 +0200 (CEST) Received: from smtpclient.apple (unknown [IPv6:2a02:1210:2ea4:cf00:d5f5:91d7:c707:e14c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id B6CC83A1DC0 for ; Tue, 28 Mar 2023 09:19:19 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Date: Tue, 28 Mar 2023 09:19:19 +0200 References: To: PHP internals In-Reply-To: Message-ID: <9318094F-139C-4392-8307-1C42B327CDD6@cschneid.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) Subject: Re: [PHP-DEV] [RFC] Define proper semantics for range() function From: cschneid@cschneid.com (Christian Schneider) Am 28.03.2023 um 00:36 schrieb G. P. B. : > I therefore propose the "Define proper semantics for range() function" = RFC > to address the unintuitive behaviour that sees no usage and/or hide = bugs: > https://wiki.php.net/rfc/proper-range-semantics >=20 > The change propose to throw TypeErrors and ValueErrors for case where = I > couldn't find occurrences in the wild and hide bugs, and emit some > E_WARNINGs for cases that are hard to detect via static analysis. I think it makes sense to clean up the range() function, thanks! There are two cases I would handle differently: - I'm not sure why a negative step for $start > $end is considered = wrong, I consider range(10, 0, -2) at least as logical/readable as using = a positive decrement of 2. Not requiring a sign for steps seems weirder = to me but that's something we cannot change. *BUT* if it is the result = of a calculation it seems wrong to require an abs() around it. I do see = the reason for a warning/error when $start < $end and $step < 0. - Values of '' or null in integer context (e.g. range(null, 10, 2)) = should IMHO emit a warning first, not directly be changed to a = TypeError. The usual BC / migration concern :-) Regards, - Chris