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
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 arnold.adaniels.nl@gmail.com
Sent: Tuesday, July 9, 2019 9:56 AM
To: PHP Internals internals@lists.php.net
Subject: [PHP-DEV] [VOTE] Strict operators directiveHi internals,
I've opened voting on the strict operators directive:
https://wiki.php.net/rfc/strict_operatorsAs promised, a patch and tests have been prepared. This is available on
https://github.com/php/php-src/pull/4375Regards,
Arnold
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_operatorsAs promised, a patch and tests have been prepared. This is available on
https://github.com/php/php-src/pull/4375Regards,
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 ?
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.
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
,,,
(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 |
+---------------------------------------------------------------------+
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.
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 arnold.adaniels.nl@gmail.com
Sent: Tuesday, July 9, 2019 9:56 AM
To: PHP Internals internals@lists.php.net
Subject: [PHP-DEV] [VOTE] Strict operators directiveHi internals,
I've opened voting on the strict operators directive:
https://wiki.php.net/rfc/strict_operatorsAs promised, a patch and tests have been prepared. This is available on
https://github.com/php/php-src/pull/4375Regards,
Arnold
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
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
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
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.