Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119324 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84176 invoked from network); 18 Jan 2023 17:27:39 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jan 2023 17:27:39 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5CF34180547 for ; Wed, 18 Jan 2023 09:27:38 -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.5 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, 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-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (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 09:27:37 -0800 (PST) Received: by mail-yb1-f170.google.com with SMTP id p188so39009992yba.5 for ; Wed, 18 Jan 2023 09:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=6eyE7SOFXrn5WkZtX/9HmkoKVZcqZpN1gWfvQhYeVmI=; b=AzmF77XprqHTgeqlPkNBZakrdy9EIv1FX9CO5/hyk3bZ326TT8N0sEnadZkPG4wS0m pc/42DRD/lbptbZ6DCk3r31yarcd+kgTk3FFfz1wLndkZR95iK+nsrm5HdI4+58oC7q2 gnldZWsErUPqVoZKbFhqVja0/gW4Canm5MXig/GFHipZZiCX5zDdWZpKQVX1Yg9+NbfM AdX18wRf/3tp8QvAOstaU06wMMGcKED3tN7ceiytaWLSxCChyxjutqldV/ZDy2oIwmSO ecu0FOGCJSQpA43tpahtZoXyhmEWQMHoIi1/1kQpsFpDBmV60MwdDe8KF9Or6C9Al8wM ytiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=6eyE7SOFXrn5WkZtX/9HmkoKVZcqZpN1gWfvQhYeVmI=; b=XHW93QLXLptPuvasKpN5O/hZBOtJYaL9FPKAnjopFpXbWnGYd+I+5mvx8X8aZCf+Hf 5YCl7katCeTDr276ldZL4mNz3nK4vG9o6ObiTULT2lsA1jt2rILnfR2toT61JeMk8Slm /L/WhMquby8AfJaqOs4CzMDR1xECAHdWJzjAxrk0Km5ICQiXDj1pBZm7Nrg2lGW4Hm2U 6aHjblFm+v2bxWtLrqE7m7OCZ7+wbBBIDboSUp3DkS3QhkKWDbgtxv0vvDendGiKAeOc LLmpOafUxxhgA/JxQjDSph3UIFABKq6988JPqp6E00Eq+Hk+7p6X/1xRTZeWHsJG8a/I DFpg== X-Gm-Message-State: AFqh2kpoF1gmPhJ2OdijGba8E4On7VMEiUL7oy9NJ+aSAW3qjkfHyR+0 jRF0g8VApmJSqAQHPr0QDIg3ukDG4l9gc7iali7LMvKOnqM= X-Google-Smtp-Source: AMrXdXtm/Nqe0cnk4Vqgma+t5JSmqXJjcCjU81Zu/q+fEOYPukLhVyW5DbuS8WHS9IQ3i3aqQ+7Jr18HE4m0ZYg0fYE= X-Received: by 2002:a25:ba48:0:b0:797:cc8c:d54f with SMTP id z8-20020a25ba48000000b00797cc8cd54fmr1034756ybj.291.1674062856755; Wed, 18 Jan 2023 09:27:36 -0800 (PST) MIME-Version: 1.0 References: <04288995-54CE-41A4-BFFD-A7CF72F16D3F@gmail.com> In-Reply-To: <04288995-54CE-41A4-BFFD-A7CF72F16D3F@gmail.com> Date: Wed, 18 Jan 2023 17:27:25 +0000 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000e8a27f05f28d21c7" Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators From: tekiela246@gmail.com (Kamil Tekiela) --000000000000e8a27f05f28d21c7 Content-Type: text/plain; charset="UTF-8" I like this proposal and I support making the language consistent. I wasn't aware there were so many inconsistencies with increment/decrement operators. When I read the RFC I was a little sceptical about the deprecation of string increment functionality. It's something I used in the past and I see no easy upgrade path. However, after reading this thread and thinking it over, I realize that deprecation is the right way to go. Someone said that it's useful when working with Excel. Excel uses bijective base-26 system. PHP does not. I cannot even explain what logic governs PHP string increment functionality. ``` $s = "az"; var_dump(++$s); // string(2) "ba" $s = "a9"; var_dump(++$s); // string(2) "b0" $s = "99"; var_dump(++$s); // int(100) $s = "zZ"; var_dump(++$s); // string(3) "aaA" $s = "9D9"; var_dump(++$s); // string(3) "9E0" $s = "9E0"; var_dump(++$s); // float(10) $s = "CHEAP BED"; var_dump(++$s); // string(9) "CHEAP BEE" ``` Strings should not be incrementable unless they are numeric strings. The current "feature" is more like a bug from xkcd comic. https://xkcd.com/1172/ But as there is a real need for a similar functionality, for example when working with Excel, I would propose to add a class into the language that is able to calculate and iterate any bijective base system. It needs to have a clear functional spec and should support both increment/decrement operators as well as iterators. I see this as the only way out of this mess. This RFC needs to pass, but it cannot pass without an alternative for people who actually use this "feature". The PHP manual says: "The increment/decrement operators only affect numbers and strings. Arrays, objects, booleans and resources are not affected. Decrementing null values has no effect too, but incrementing them results in 1." But that's not true. You cannot increment an array or resource as it would trigger an error. But incrementing false/true doesn't generate any errors. It's very inconsistent and misleading. --000000000000e8a27f05f28d21c7--