Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108658 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84504 invoked from network); 18 Feb 2020 15:45:37 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Feb 2020 15:45:37 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 13AE918050A for ; Tue, 18 Feb 2020 06:01:15 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 18 Feb 2020 06:01:14 -0800 (PST) Received: by mail-lf1-f41.google.com with SMTP id r14so14585991lfm.5 for ; Tue, 18 Feb 2020 06:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qeOxVkJAOFfBnItScMZDLP48mfJL+DGH/yjNJXVDpn8=; b=KDO+Wmr6q/LItsxSyPTlxMktrT87bY8otgSTqhXPl9n4EfsZyBFNDMqu7BfwuHOprX C49y7VCm1syR3X/zOziSWisDPurOfoONBtvMrGZ2d6DBA8CtBJEjpxqWiWfmlaAnmkn2 d5CMw8MG/P01nL6e9ES9mtkxx0S21kq8CEmJn/SPPL2fwlSyUCMJlDu/aCnNANwtTwg1 3DmDoP6QpvXYsORY/Ci3Kcd65u5WlFpvCP84qZACol4kooF1sXyGwjtZ301iFlrNHIQD H5CbeNglAuBEHkUbMStcWNVM+vl3cXh7OA5g/GinJQdbnASCrwuzZn39DwBIwQf9fcuD igPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qeOxVkJAOFfBnItScMZDLP48mfJL+DGH/yjNJXVDpn8=; b=PzuQpVPUyQIX7p/mNtQ2Tx61EKLWA2t4Brb8a4GSYkpSiVBH4cdThzhyGY/zertS0k UoOD8BURrOGJGki8sU5xvVXLBpl7cEXWqyTCx3wUApUIt3YQB5TW9cUUhr/unLfAzrbp ZHkRmPXzxa4VSVQ8fGRDyqRN9q5PVX5mraqTiTbuH18eUyjsG54bRospnMByJm5AF4Av 4/1KaU8NPOw9cJsWQ4SN1isLuiYQrRQvnqXodwGNSUZSmEmac/Nfm5wA+4OtfIqZ5708 3GmlYbGzYbxTM8af4M5HBpTj7qaJ/DQdEDj94/vr0TNvSH0zeY0Lw367mifghuCslUdq egQQ== X-Gm-Message-State: APjAAAVxTVaUiG+wNE3IydMUtNhFpy4G41whITN1qhQm69aFjbXwfH7h 8QoYYLqIlMNCKFaMcUOaX0RTQHDKz5jCQvgwLL0= X-Google-Smtp-Source: APXvYqyzEmnoHh4t12QqQdCuMJ0bARyQGuhgPsTqsLzmNsYdYBy/EXD+YW4fxgVJ2J7Jfo8hUuYlktZ8yRhNopqZ3EI= X-Received: by 2002:ac2:4add:: with SMTP id m29mr10690102lfp.190.1582034473056; Tue, 18 Feb 2020 06:01:13 -0800 (PST) MIME-Version: 1.0 References: <16481aca-93f4-43f5-5ec2-413d19ade318@gmail.com> In-Reply-To: <16481aca-93f4-43f5-5ec2-413d19ade318@gmail.com> Date: Tue, 18 Feb 2020 15:00:56 +0100 Message-ID: To: Rowan Tommins Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000c9fb61059eda1af9" Subject: Re: [PHP-DEV] Allow null variables to be decremented From: nikita.ppv@gmail.com (Nikita Popov) --000000000000c9fb61059eda1af9 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 15, 2020 at 6:44 PM Rowan Tommins wrote: > Hi all, > > There is currently an odd inconsistency when using the decrement > operator on a null variable: > > $a = null; $a=$a+1; // int(1) > $a = null; $a+=1; // int(1) > $a = null; ++$a; // int(1) > > $a = null; $a=$a-1; // int(-1) > $a = null; $a-=1; // int(-1) > $a = null; --$a; // null > > I would like to propose changing this behaviour for PHP 8, so that --$a > would give int(-1), as I believe it is simply a long-standing bug. > > > This has been raised as a bug at least three times [1][2][3] but closed > as documented behaviour / too much of a BC break. It is documented in > the manual, but with no explanation of why it should work that way. [4] > > I would be interested in any explanations of why it might be intended > behaviour, or ways in which people might be relying on the current > behaviour. > > A proposal to change the behaviour was included in a wider RFC about > standardising increment and decrement behaviour, but it never got beyond > draft status. [5] I would prefer not to reopen that wider debate, but > focus on this single issue. > > As far as I can see, the change would be to add a "case IS_NULL" branch > to decrement_function in zend_operators.c to match the one in > increment_function. [6] > > > I will happily write up an RFC to formalise this, but wanted to gather > people's immediate thoughts first. > Principally in favor of this change, I do think that ++ and -- should behave consistently if nothing else. We might want to consider giving the same treatment to false/true as well, which should be interpreted as 0/1. That is $foo++ / $foo-- should behave the same ways as $foo+=1, $foo-=1 for null, true, false. It seems odd to single out only "null" here. Additionally I would suggest a notice when trying to increment arrays, resources and objects, rather than just silently doing nothing. As long as it's just a notice, this should have minimal BC implications. Nikita --000000000000c9fb61059eda1af9--