[RFC] Strict operators directive View as Markdown

On Fri, 15 May 2020 at 23:03, Arnold Daniels
arnold.adaniels.nl@gmail.com wrote:

I'd like to restart the discussion for the strict_opterators RFC (
https://wiki.php.net/rfc/strict_operators).

Hi Arnold,

That RFC is quite big, and I'm finding it hard to fit it all in my head.

I know it's annoying when people ask for more work to be done, but
would it be possible for you to make a php file and chuck it as a gist
somewhere, that contains the complete set of things that are currently
undesirable, and what the new proposed behaviour would be?

I think people being able to download a complete code example, and
read it in the editor they use everyday, will make it easier to grok
the current problems and why the proposed changes are appropriate.

btw the "Proposed Voting Choices" section currently doesn't have a
proposal of voting choice in it.

cheers
Dan
Ack

Hi all,

I'd like to restart the discussion for the strict_opterators RFC (
https://wiki.php.net/rfc/strict_operators).

I think this kind of change will have a long term positive impact, but
it will require a lot of work to update code.

IMHO we need to know what is happening with editions, as I think this
would be an ideal candidate for that rather than another declare

It would would give people <x> years warning that they've got that long
to add their correct castings etc before the old behaviour is removed.

Hi all,

I'd like to restart the discussion for the strict_opterators RFC (
https://wiki.php.net/rfc/strict_operators).

I’m having trouble wrapping my head around this statement:

To compare two numeric strings as numbers, they need to be cast to
integers or floats.

As an example, the RFC shows:

"100" == "1e1";               // false
(int)"100" == (int)"1e2";     // true

But this is identical to how PHP works today.

I think the identity operator is more expressive in this case,
especially to show intent.

The function of the === and !== operators remains unchanged.

So, while true != 0 throws a TypeError, true !== 0 continues to
function as it does today, without a TypeError? I find this behavior
confusing and unintuitive.

I can see the value in what the RFC proposes (strict type comparisons),
but I think the behavior proposed still needs work. While I understand
it’s opt-in on a file-by-file basis, I don’t think changing the meaning
and behavior of existing operators is the right approach.

Maybe if we could introduce new comparison operator symbols? But I’m not
sure what those symbols would be.

Cheers,
Ben

Am 16.05.2020 um 16:56 schrieb Max Semenik maxsem.wiki@gmail.com:

IMHO we need to know what is happening with editions, as I think this
would be an ideal candidate for that rather than another declare

On the other hand, a declare would allow a gradual upgrade path where
people can use strict mode for new code and convert file after file at
their own pace, taking their time to fix all the problems - while already
taking advantage of new features where possible.

The problem originally discussed (and among other things leading to the P++ proposal) remains:
We would have two semantically very different languages in one with just a little line at the top of the file to distinguish between them.

I cannot look at code like
function same($a, $b)
{
return $a == $b;
}
and know how if it works with my usage of types.

In a way having this on a per-file-basis makes things even worse.

• Chris