Everything

php

[VOTE] Strict operators directive

php.internals

Arnold Daniels

7 years ago

Hi internals,

I've opened voting on the strict operators directive:
https://wiki.php.net/rfc/strict_operators

As promised, a patch and tests have been prepared. This is available on
https://github.com/php/php-src/pull/4375

Regards,
Arnold

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

7 years ago

Although I like this idea, I'm wondering if such a big change should go for php 8 instead of 7.4.

Regards,
CHU Zhaowei

Nikita Popov

7 years ago

On Tue, Jul 9, 2019 at 9:19 AM CHU Zhaowei <me@jhdxr.com> wrote:

> Although I like this idea, I'm wondering if such a big change should go
> for php 8 instead of 7.4.
>
> Regards,

CHU Zhaowei

>

Right. I really wouldn't want to merge this kind of large change on the
very day of feature freeze. I would feel a lot better about this if it
targeted PHP 8 and the vote was in one month, when we're not scrambling to
finalize 7.4 features...

Nikita

Marco Pivetta

7 years ago

On Tue, Jul 9, 2019, 03:56 Arnold Daniels <arnold.adaniels.nl@gmail.com>
wrote:

> Hi internals,
>
> I've opened voting on the strict operators directive:
> https://wiki.php.net/rfc/strict_operators
>
> As promised, a patch and tests have been prepared. This is available on
> https://github.com/php/php-src/pull/4375
>
> Regards,
> Arnold
>

I wasn't sure about the full implications of this, but after some thought,
the worst that can happen is excessive strictness, requiring to drop a
single declaration on top of a file 👍

Christian Schneider

7 years ago

Am 09.07.2019 um 11:30 schrieb Marco Pivetta <ocramius@gmail.com>:

> I wasn't sure about the full implications of this, but after some thought,
> the worst that can happen is excessive strictness, requiring to drop a
> single declaration on top of a file 👍

When you drop the declaration on top of the file the semantics of your operators suddenly change, e.g.
"42" < "7"
changes from true to false and you get subtle bugs.

And if you try to read other people's code (or even try to copy/paste it) then make sure you keep in mind which mode they are programming in.

- Chris

Andreas Heigl

7 years ago

Am 09.07.19 um 12:06 schrieb Christian Schneider:

> Am 09.07.2019 um 11:30 schrieb Marco Pivetta <ocramius@gmail.com>:
>> I wasn't sure about the full implications of this, but after some thought,
>> the worst that can happen is excessive strictness, requiring to drop a
>> single declaration on top of a file 👍
>
> When you drop the declaration on top of the file the semantics of your operators suddenly change, e.g.
> 	"42" < "7"
> changes from true to false and you get subtle bugs.
>
> And if you try to read other people's code (or even try to copy/paste it) then make sure you keep in mind which mode they are programming in.

But that's the same for `declare(strict_types=1);`

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca                                               |
+---------------------------------------------------------------------+

Claude Pache

7 years ago

> Le 9 juil. 2019 à 12:09, Andreas Heigl <andreas@heigl.org> a écrit :
>
>
>
> Am 09.07.19 um 12:06 schrieb Christian Schneider:
>> Am 09.07.2019 um 11:30 schrieb Marco Pivetta <ocramius@gmail.com>:
>>> I wasn't sure about the full implications of this, but after some thought,
>>> the worst that can happen is excessive strictness, requiring to drop a
>>> single declaration on top of a file 👍
>>
>> When you drop the declaration on top of the file the semantics of your operators suddenly change, e.g.
>> 	"42" < "7"
>> changes from true to false and you get subtle bugs.
>>
>> And if you try to read other people's code (or even try to copy/paste it) then make sure you keep in mind which mode they are programming in.
>
> But that's the same for `declare(strict_types=1);`
>
> Cheers
>
> Andreas

No, it’s not the same thing as declare(strict_types=1).

With declare(strict_types=1), you just get additional TypeErrors. It will not actually change the semantics of code that works in both non-strict-types mode and strict-types mode. This is a useful feature when refactoring legacy code.

The worst thing that can happen with declare(strict_types=1), is that code won’t work any more.

The worst thing that can happen with declare(strict_operators=1), is that code will change semantics.

—Claude

Arnold Daniels

7 years ago

On Tue, Jul 9, 2019 at 12:22 PM Claude Pache <claude.pache@gmail.com> wrote:

>
>
> > Le 9 juil. 2019 à 12:09, Andreas Heigl <andreas@heigl.org> a écrit :
> >
> >
> >
> > Am 09.07.19 um 12:06 schrieb Christian Schneider:
> >> Am 09.07.2019 um 11:30 schrieb Marco Pivetta <ocramius@gmail.com>:
> >>> I wasn't sure about the full implications of this, but after some
> thought,
> >>> the worst that can happen is excessive strictness, requiring to drop a
> >>> single declaration on top of a file 👍
> >>
> >> When you drop the declaration on top of the file the semantics of your
> operators suddenly change, e.g.
> >>      "42" < "7"
> >> changes from true to false and you get subtle bugs.
> >>
> >> And if you try to read other people's code (or even try to copy/paste
> it) then make sure you keep in mind which mode they are programming in.
> >
> > But that's the same for `declare(strict_types=1);`
> >
> > Cheers
> >
> > Andreas
>
> No, it’s not the same thing as declare(strict_types=1).
>
> With declare(strict_types=1), you just get additional TypeErrors. It will
> not actually change the semantics of code that works in both
> non-strict-types mode and strict-types mode. This is a useful feature when
> refactoring legacy code.
>
> The worst thing that can happen with declare(strict_types=1), is that code
> won’t work any more.
>
> The worst thing that can happen with declare(strict_operators=1), is that
> code will change semantics.
>
> —Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

After discussing it with Nikita and Derick, I've decided to close the
voting for this RFC for now. The change is too large to merge it this
choose to a feature freeze.

Additionally, it seems that more discussion is required.

I will reopen the RFC at a later moment, targetting it at PHP 8.

Regards,
Arnold

Marco Pivetta

7 years ago

On Tue, Jul 9, 2019, 12:06 Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 09.07.2019 um 11:30 schrieb Marco Pivetta <ocramius@gmail.com>:
> > I wasn't sure about the full implications of this, but after some
> thought,
> > the worst that can happen is excessive strictness, requiring to drop a
> > single declaration on top of a file 👍
>
> When you drop the declaration on top of the file the semantics of your
> operators suddenly change, e.g.
>         "42" < "7"
> changes from true to false and you get subtle bugs.
>
> And if you try to read other people's code (or even try to copy/paste it)
> then make sure you keep in mind which mode they are programming in.
>
> - Chris
>
>
> Hi Chris,

That is already true for `strict_types`: my only worry with this directive
so far is hitting edge cases that I didn't think of yet (requiring
disabling it selectively).

Doing that is pretty harmless if combined with testing and static analysis
(which are an unavoidable assumption).

Another way to restrict this RFC further is to allow this directive only
when `strict_types` is already enabled, reducing the possible permutations
of language behaviour.

Stephen Reay

7 years ago

> On 9 Jul 2019, at 17:06, Christian Schneider <cschneid@cschneid.com> wrote:
>
> When you drop the declaration on top of the file the semantics of your operators suddenly change, e.g.
> 	"42" < "7"
> changes from true to false and you get subtle bugs.

If you OPT IN to strict operators, the onus is on you to check that your code still works, just like it is with every other new feature that you can CHOOSE to use or not.

> And if you try to read other people's code (or even try to copy/paste it) then make sure you keep in mind which mode they are programming in.

It’s disappointing that “I need to copy paste this code and it might not do what I expect” is more important to people than fixing things like the way switch statement does comparisons, which makes zero practical sense right now.