Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108808 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 85338 invoked from network); 2 Mar 2020 16:27:41 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Mar 2020 16:27:41 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5DE821804D8 for ; Mon, 2 Mar 2020 06:46:35 -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,RCVD_IN_MSPIKE_H2,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-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 ; Mon, 2 Mar 2020 06:46:34 -0800 (PST) Received: by mail-io1-f54.google.com with SMTP id m22so5410108ioj.7 for ; Mon, 02 Mar 2020 06:46:34 -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=WGpvuD/hmykQ6ZtxVjkWKp2RV13/jBmFQ1W0U3MdCcA=; b=Wy8eBoL7Ty+whgqdZQavKrCqxOymH60BuyzU4/V5YRldtPvn4flWzlB7NuzdJ3njEG CD3JEh4jkRO6ESNEkhNBKwUcAHFT/AJ2JUd90ZlRoFUBHpl3MkqDkas9vvUzgfnNz3hK +Zq8K/hrZNJIA2z46dIKiANRrLH2gH/0tIaDoFQYLbAwhL7gqschjNurJX6P3D75jI+G dQXRTF5dIIcfQVs6P58SqbCgRYt/sU32xQpmwdvc3Pa7lals7chg2Wqnu2w33f3ZjNYb IxYYL3nZuPqQNIv2+KkKK3P/5T0HPqVmCF+Q+dUHpun0qzfN7hHLm7uay7/y9uVtSmBj kd1g== 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=WGpvuD/hmykQ6ZtxVjkWKp2RV13/jBmFQ1W0U3MdCcA=; b=bBwQryhFywyCT4m5SpO815/O63zNGIm69A1uKtSWJn4MnkCAQN+5xDDnoIkKchpsuG g11vJt9o7ovchpQ5P2288mc7m8nCS8r4q+d/Pk3DuoTx9C/cfIksAtXOQprLhvKx5NXN SkJWWdhl60ZEBt9/JEttalekj1iNv+K51ladGoOVJctkVVJewmTHg8/Zna/4cnE+y7As ei/iU1KwBCD6bSOT8U2SxFYmY3uNYNxA0r8LthAfgVrrsSTT37Ans1GUhDq5V4dBStUB CVHwPdDvaLAuLCGaWy+S0nwdW8UkxFUeZzI6H2EdD8Zr/KkZIJSwOQAJQeFkAqwhu16O OKog== X-Gm-Message-State: APjAAAWEHHR+3CtlYkOSNX5KGFxR8o8shIn5grvd0TFb6i7gjKlQI+WP W0o/FO1rgHKWgivWw2F7WmUJE11tEqJmPheZDHxUkTDC X-Google-Smtp-Source: APXvYqycixwv1urpVSJgIFn32SjakF2dT2dihRbDW1HGrNfLB+MBetvn/36T8wg81eQJDTp4XfEqvavTl7Nzi4T1r3k= X-Received: by 2002:a5d:9c95:: with SMTP id p21mr12744600iop.282.1583160391831; Mon, 02 Mar 2020 06:46:31 -0800 (PST) MIME-Version: 1.0 References: <3f615d82-a84b-697b-5c02-8d915270f92c@gmail.com> In-Reply-To: Date: Mon, 2 Mar 2020 15:46:20 +0100 Message-ID: To: Rowan Tommins Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000c715f2059fe0409f" Subject: Re: [PHP-DEV] [RFC] Increment/Decrement Fixes From: ocramius@gmail.com (Marco Pivetta) --000000000000c715f2059fe0409f Content-Type: text/plain; charset="UTF-8" Hey Rowan, On Mon, Mar 2, 2020 at 3:39 PM Rowan Tommins wrote: > Hi Marco, > > On Mon, 2 Mar 2020 at 14:00, Marco Pivetta wrote: > > > > > Overall against the RFC: `++` and `--` (prefix and suffix) are supposed > to > > be used with numeric values, not with other types, as that makes > everything > > only more confusing. > > > > > While I'm generally sympathetic to that principle, it could also be said of > the + and - operators, which currently silently handle both nulls and > booleans. I would be open to changing *all* arithmetic behaviour, > particularly on booleans, but don't think a vague ambition for that > justifies inconsistent behaviour between different arithmetic operators. > Yes, I'm indeed not suggesting to change them: my comment is explicitly about turning the BC break (in this RFC) into an useful and *loud* BC break. > > Code written (intentionally) to use `++` and `--` against non-numeric > > values should **NOT** pass a code review, and I am sorry for those that > > have to maintain it if that happens. > > > > > I think you're taking simplified examples too literally here, and assuming > that all affected code would be obvious at a glance. > > Take for instance this innocent-looking patch: > > function foo($bar) { > - $bar -= 1; > + $bar--; > // more code here > } > > With the current behaviour, any inadvertent calls to the function passing > null, true, false, or an array will change behaviour when this patch is > merged. In particular, the variable $bar would previously have been > guaranteed to be an integer, and will now retain the original type passed > in. > > I completely agree that such code has a bug, but the difference in > behaviour is still a massive WTF. > The code in the above example cannot be accepted without an `int` type declaration, or an `(int)` cast (or similar number) applied before the first arithmetic happens. For older code that needs to respect BC due to LSP, a docblock type declaration would suffice. The code above is NOT going to pass a code review. The asymmetry of ++ and -- is even more confusing. Consider this patch: > > function repeatThing($extraTimes) { > - for ( $i = 0; $i <= $extraTimes ; $i ++ ) { > + for ( $i = $extraTimes ; $i >= 0; $i -- ) { > doThing(); > } > } > > Again, this looks like a safe change - but if passed a value of NULL, the > old code will call doThing() once, and the new code will enter an infinite > loop. > Same as above: types are not optional, and `$extraTimes` is not usable in its form. This code cannot pass a code review either. > > > > Changing the current behavior, regardless in which way, is a BC break: > > might as well make the BC break useful: > > > > RFC Proposal: `$a = null; $a--; $a === -1`. Let's make this an explicit > > TypeError instead. > > RFC Proposal: `$a = null; --$a; $a === -1`. Let's make this an explicit > > TypeError instead. > > > > > And what about `$a = null; $a++;` / `$a = null; ++$a;`, which currently > has behaviour consistent with other arithmetic operations (in particular, > is identical to $a+=1) and this RFC does not propose to change? > Leave unchanged. If a BC break is to be introduced, make it go with a bang (throw error) If we change the ++ case to throw a TypeError, would we also change null+1 > to throw one? And would we then also examine all the other operators and > utility functions which silently coerce null to zero or an empty string? > Can also not change it: I'd throw an error, if I were to propose it, but the BC break must bring active value. Right now, psalm & phpstan catch these, luckily. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --000000000000c715f2059fe0409f--