Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120191 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 99872 invoked from network); 5 May 2023 14:49:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 May 2023 14:49:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 600561804AC for ; Fri, 5 May 2023 07:49:11 -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.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 ; Fri, 5 May 2023 07:49:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id B787210C401; Fri, 5 May 2023 15:49:09 +0100 (BST) Date: Fri, 5 May 2023 15:49:09 +0100 (BST) To: "G. P. B." cc: PHP internals In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1153989788-1683298149=:41807" Subject: Re: [PHP-DEV] [RFC] Define proper semantics for range() function From: derick@php.net (Derick Rethans) --8323329-1153989788-1683298149=:41807 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 27 Mar 2023, G. P. B. wrote: > While working on analysing the impact of the changes proposed by=20 > amending the behaviour of the increment and decrement operators (=20 > https://wiki.php.net/rfc/saner-inc-dec-operators) I discovered that=20 > the range() function has some rather lax behaviour that is very=20 > unintuitive. >=20 > I therefore propose the "Define proper semantics for range() function"=20 > RFC to address the unintuitive behaviour that sees no usage and/or=20 > hide bugs: https://wiki.php.net/rfc/proper-range-semantics | If $step is a float but is compatible with int interpret it as an=20 | integer. I guess you mean with that "the fraction is '.0'" and "-2^52 < number <=20 2^52" ? What is also going to be playing up is the range of $start and=20 $end itself.=20 | Introduce and use a proper ZPP check for int|float|string $start and=20 | $end parameters, this will cause TypeErrors to be thrown when passing=20 | objects, resources, and arrays to range().=20 I am not sure whether it wise to disallow resources. These are often=20 file descriptors and having a range on those *could* make sense? Not=20 fussed much either way though. | Throw a ValueError when passing a negative $step for increasing=20 | ranges. I think that's a BC break that is not worthy of making.=20 | Emit an E_WARNING when $start or $end has more than one byte. Surely only if the string doesn't represent an int or float? | var_dump(range(null, 2)); I think that safely can be interpreted as range(0, 2) =E2=80=94 I wouldn't = throw=20 a deprecation warning for that... but then of course, we do already have=20 a similar (deprecation) warning for arguments. >=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. | Target Version: PHP 8.3 In my opinion that's not a good thing. There are a fair amount of BC=20 breaks (beyond the one that I oppose to with nagative steps throwing an=20 ValyeError), without first having deprecations. IMO, the actual BC=20 breaks here should become deprecations in 8.X and BC can only be really=20 broken in 9.0. cheers, Derick --8323329-1153989788-1683298149=:41807--