[PHP-DEV] [VOTE] Strict operators directive

  106189
July 9, 2019 01:55 arnold.adaniels.nl@gmail.com (Arnold Daniels)
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
  106190
July 9, 2019 07:12 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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

> -----Original Message----- > From: Arnold Daniels nl@gmail.com> > Sent: Tuesday, July 9, 2019 9:56 AM > To: PHP Internals <internals@lists.php.net> > Subject: [PHP-DEV] [VOTE] Strict operators directive > > 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
  106197
July 9, 2019 10:12 nikita.ppv@gmail.com (Nikita Popov)
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
> > -----Original Message----- > > From: Arnold Daniels nl@gmail.com> > > Sent: Tuesday, July 9, 2019 9:56 AM > > To: PHP Internals <internals@lists.php.net> > > Subject: [PHP-DEV] [VOTE] Strict operators directive > > > > 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 > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  106193
July 9, 2019 09:30 ocramius@gmail.com (Marco Pivetta)
On Tue, Jul 9, 2019, 03:56 Arnold Daniels 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 👍
>
  106194
July 9, 2019 10:06 cschneid@cschneid.com (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. - Chris
  106195
July 9, 2019 10:09 Andreas Heigl <andreas@heigl.org>
--pKARSskMB7U4SHajwu5JDyII0Z6GN970r
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable



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 thou= ght,
>> the worst that can happen is excessive strictness, requiring to drop a=
>> single declaration on top of a file =F0=9F=91=8D >=20 > 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. >=20 > And if you try to read other people's code (or even try to copy/paste i= t) then make sure you keep in mind which mode they are programming in.
But that's the same for `declare(strict_types=3D1);` Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --pKARSskMB7U4SHajwu5JDyII0Z6GN970r--
  106198
July 9, 2019 10:21 claude.pache@gmail.com (Claude Pache)
> 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
  106199
July 9, 2019 11:30 arnold.adaniels.nl@gmail.com (Arnold Daniels)
On Tue, Jul 9, 2019 at 12:22 PM Claude Pache 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
  106196
July 9, 2019 10:12 ocramius@gmail.com (Marco Pivetta)
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.
  106200
July 9, 2019 12:22 php-lists@koalephant.com (Stephen Reay)
> 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.