Everything

php

bool values and increment operators?

php.internals

Dan Ackroyd

7 years ago

Hi internals,

So this code:

<?php

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.

Does anyone know if this behaviour is deliberate, or is it just an
oversight that could have an RFC applied to it?

cheers
Dan
Ack

btw I realised that the behaviour is like it is, from someone asking
for help debugging this code:

<?php
$i=0;
$j=2;
$exit = 0;
while(10-$i++||$i=0||--$j){
echo$i.' - '.$j."\n";
if($exit++ == 30) exit();
}

Christian Schneider

7 years ago

Am 25.03.2019 um 15:43 schrieb Dan Ackroyd <danack@basereality.com>:

> So this code:
>
>    <?php
>
>    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

Chase Peeler

7 years ago

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:
> >
> >    <?php
> >
> >    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

Andrey Andreev

7 years ago

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.

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

7 years ago

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

Rowan Collins

7 years ago

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]

Dan Ackroyd

7 years ago

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

Rowan Collins

7 years ago

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]