# [VOTE] Strict operators directive - Thread: https://externals.io/message/106189 - Original archive: https://news-web.php.net/php.internals/106189 - Started by Arnold Daniels on 2019-07-09T01:55:57+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #106189 — Arnold Daniels — 2019-07-09T01:55:57+00:00 URL: https://externals.io/message/106189#106189 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 — me@jhdxr.com — 2019-07-09T07:12:36+00:00 URL: https://externals.io/message/106189#106190 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 > Sent: Tuesday, July 9, 2019 9:56 AM > To: PHP Internals > 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 --- ## #106193 — Marco Pivetta — 2019-07-09T09:30:06+00:00 URL: https://externals.io/message/106189#106193 On Tue, Jul 9, 2019, 03:56 Arnold Daniels 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 — Christian Schneider — 2019-07-09T10:06:39+00:00 URL: https://externals.io/message/106189#106194 Am 09.07.2019 um 11:30 schrieb Marco Pivetta : > 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 — Andreas Heigl — 2019-07-09T10:09:58+00:00 URL: https://externals.io/message/106189#106195 Am 09.07.19 um 12:06 schrieb Christian Schneider: > Am 09.07.2019 um 11:30 schrieb Marco Pivetta : > > […] > > 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 | +---------------------------------------------------------------------+ --- ## #106196 — Marco Pivetta — 2019-07-09T10:12:00+00:00 URL: https://externals.io/message/106189#106196 On Tue, Jul 9, 2019, 12:06 Christian Schneider wrote: > Am 09.07.2019 um 11:30 schrieb Marco Pivetta : > > […] > thought, > > […] > > 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. --- ## #106197 — Nikita Popov — 2019-07-09T10:12:33+00:00 URL: https://externals.io/message/106189#106197 > 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 > > […] --- ## #106198 — Claude Pache — 2019-07-09T10:21:56+00:00 URL: https://externals.io/message/106189#106198 > Le 9 juil. 2019 à 12:09, Andreas Heigl a écrit : > > > > Am 09.07.19 um 12:06 schrieb Christian Schneider: > > […] > > 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 — Arnold Daniels — 2019-07-09T11:30:00+00:00 URL: https://externals.io/message/106189#106199 > > > > […] > thought, > > […] > operators suddenly change, e.g. > > […] > it) then make sure you keep in mind which mode they are programming in. > > […] > > 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 > -- > > > > 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 --- ## #106200 — Stephen Reay — 2019-07-09T12:22:34+00:00 URL: https://externals.io/message/106189#106200 > > > 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.