bool values and increment operators?

  104932
March 25, 2019 14:43 Danack@basereality.com (Dan Ackroyd)
Hi internals,

So this code:

    
    
  104933
March 25, 2019 15:03 cschneid@cschneid.com (Christian Schneider)
Am 25.03.2019 um 15:43 schrieb Dan Ackroyd <danack@basereality.com>:
> So this code: > > > declare(strict_types=1); > > $i = true; > $i++; > var_dump($i); > $i--; > var_dump($i); > > > $i = false; > $i++; > var_dump($i); > $i--; > var_dump($i); > > outputs: > > bool(true) > bool(true) > bool(false) > bool(false) > > which is quite surprising on multiple levels.
The documentation has a highlighted box stating "Note: The increment/decrement operators only affect numbers and strings. Arrays, objects and resources are not affected. Decrementing NULL values has no effect too, but incrementing them results in 1." I guess bools should be added to the list of things not affected. - Chris
  104934
March 25, 2019 15:08 chasepeeler@gmail.com (Chase Peeler)
On Mon, Mar 25, 2019 at 11:03 AM Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 25.03.2019 um 15:43 schrieb Dan Ackroyd <danack@basereality.com>: > > So this code: > > > > > > > declare(strict_types=1); > > > > $i = true; > > $i++; > > var_dump($i); > > $i--; > > var_dump($i); > > > > > > $i = false; > > $i++; > > var_dump($i); > > $i--; > > var_dump($i); > > > > outputs: > > > > bool(true) > > bool(true) > > bool(false) > > bool(false) > > > > which is quite surprising on multiple levels. > > The documentation has a highlighted box stating > "Note: The increment/decrement operators only affect numbers and strings. > Arrays, objects and resources are not affected. Decrementing NULL values > has no effect too, but incrementing them results in 1." > > I guess bools should be added to the list of things not affected. > > $i = false; $i+=1;
var_dump($i); that outputs int(1) I'd say that 1.) Update the documentation to add booleans to the second list 2.) Update the documentation to remove the second list - anything not in the first list is not affected. 3.) Update the language so that ++ and -- cast booleans to ints. I don't think #3 is actually a good solution.
> - Chris > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  104939
March 25, 2019 15:43 narf@devilix.net (Andrey Andreev)
Hi,

On Mon, Mar 25, 2019 at 5:09 PM Chase Peeler <chasepeeler@gmail.com> wrote:
> > 1.) Update the documentation to add booleans to the second list > 2.) Update the documentation to remove the second list - anything not in > the first list is not affected. > 3.) Update the language so that ++ and -- cast booleans to ints. >
4.) Emit warnings in those cases? I don't see a problem with how it currently works, but I do see a problem with it being silent. Cheers, Andrey.
  105133
April 7, 2019 16:08 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
It there anyone working on this? If not, I'd like to prepare a RFC targeting PHP 8 to address this issue.

In addition, I'm thinking whether it's possible and necessary to add a global strict mode (like "use strict" in js) in PHP 8 to deal with this kind of unexpected surprise. I know we have declare(strict_types=1) but it only works for functions and it's limited to call from current file.

-----Original Message-----
From: Andrey Andreev <narf@devilix.net> 
Sent: Monday, March 25, 2019 11:43 PM
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Christian Schneider <cschneid@cschneid.com>; Dan Ackroyd <danack@basereality.com>; PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] bool values and increment operators?

Hi,

On Mon, Mar 25, 2019 at 5:09 PM Chase Peeler <chasepeeler@gmail.com> wrote:
> > 1.) Update the documentation to add booleans to the second list > 2.) Update the documentation to remove the second list - anything not > in the first list is not affected. > 3.) Update the language so that ++ and -- cast booleans to ints. >
4.) Emit warnings in those cases? I don't see a problem with how it currently works, but I do see a problem with it being silent. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
  105134
April 7, 2019 17:15 rowan.collins@gmail.com (Rowan Collins)
On 07/04/2019 17:08, CHU Zhaowei wrote:
> In addition, I'm thinking whether it's possible and necessary to add a global strict mode (like "use strict" in js) in PHP 8 to deal with this kind of unexpected surprise. I know we have declare(strict_types=1) but it only works for functions and it's limited to call from current file.
I'm not a fan of a generic "strict mode" the way JS has it, because it only works once: if you add more behaviours later, the BC break is just as bad as if the switch wasn't there. I wonder if in 10 years time, someone will propose a "use stricter" mode. Perl's "pragma" system is more flexible, and notably works at the file or block level, like PHP's declare statements. The most common pragmas are "strict", "warnings", and "feature", each of which has a set of sub-categories which can be individually enabled and disabled. You can also opt into all features as of a particular version (and require that version), again within a single lexical scope. The downside is that this leads to a lot of different combinations, in keeping with the Perl motto of There More Than One Way To Do It. The big downside of all this is that even if the compiler understands what all the combinations of flags will do, the human reading the code won't necessarily, so having declare(increment_warnings=1) probably doesn't add much over just documenting the change somewhere. Regards, -- Rowan Collins [IMSoP]
  105135
April 8, 2019 02:18 Danack@basereality.com (Dan Ackroyd)
On Sun, 7 Apr 2019 at 17:08, CHU Zhaowei <me@jhdxr.com> wrote:
> > It there anyone working on this?
I'm planning to. I've just been also thinking about arrays and nulls with pre/post inc/decrement. I'm guessing code that is 'intentionally' doing: $foo = false; $foo++; and $foo = []; $foo++; are going to be relatively rare, and so would be small BCs. Whereas code that is doing: $foo = null; $foo++; e.g. through something like: error_reporting(0); $bar = []; $foo = $bar['bad_key']; $foo++; Are going to be more common, and so would be a large BC break. Though seeing as since PHP 7.0 we have the null coalesce operater, that code can be re-written to have an explicit default, and not emit an error as: $bar = []; $foo = $bar['bad_key'] ?? 0; $foo ++;
> In addition, I'm thinking whether it's possible and necessary to add a global > strict mode (like "use strict" in js) in PHP 8 to deal with this kind of unexpected > surprise. I know we have declare(strict_types=1) but it only works for functions > and it's limited to call from current file.
A global mode wouldn't be good - it would have the same problem as ini settings have; libraries that are written needing one mode, can't be sure they would be used in that mode. An alternative idea of having settings per namespace has been mentioned before with the config settings per library managed through something at the package manager layer, e.g. Composer. cheers Dan Ack
  104937
March 25, 2019 15:25 rowan.collins@gmail.com (Rowan Collins)
On Mon, 25 Mar 2019 at 15:03, Christian Schneider <cschneid@cschneid.com>
wrote:

> The documentation has a highlighted box stating > "Note: The increment/decrement operators only affect numbers and strings. > Arrays, objects and resources are not affected. Decrementing NULL values > has no effect too, but incrementing them results in 1." >
The NULL part of that has always baffled me. Why should ++ not be symmetrical with -- here? In general, documenting what we currently do is great, but is separate from agreeing that it's what we *should* do. Regards, -- Rowan Collins [IMSoP]