Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110172
MIME-Version: 1.0
Date: Sat, 16 May 2020 00:03:05 +0200
Message-ID: <CANZOY=AHs40Dzo_G44Q9byDbJ7emu5yDpmBMTSQ2uCXSARG_Dw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fd237505a5b6fa1e"
Subject: [RFC] Strict operators directive
From: arnold.adaniels.nl@gmail.com (Arnold Daniels)

--000000000000fd237505a5b6fa1e
Content-Type: text/plain; charset="UTF-8"

Hi all,

I'd like to restart the discussion for the strict_opterators RFC (
https://wiki.php.net/rfc/strict_operators).

A number of changes have been made to the RFC since the last discussion.
These are aimed at limiting the situations where `strict_operators` will
change the behavior rather than throwing a TypeError.

1. Comparison operators >, >=, <, <= and <=> with string operands will
throw a TypeError instead of behaving as `strcmp`. String operands on
comparison operators are likely to result in unexpected behavior. However,
the use case of comparing strings as numbers is too common to change the
result of this comparison. Additionally, there may be issues with locales.
Users should use `strcmp` or `Collator::compare` instead.

2. All comparison operators (excluding ===) on array operands throw a
TypeError. This means it will not be possible to compare an array as an
unsorted hashmap. While this distinction is useful, it's not well
understood by most. The major issue is that it's tied into strict vs loose
comparison. Allowing this would result in many cases where the operation
results in `false` with strict operators while resulting in `true` without
it. The alternative of throwing a TypeError based on the contents of the
two arrays goes against the principles of the RFC and brings a lot of
complexity.

3. Concatenation operation (using .) on null will not be affected. The
operator will be cast to an empty string and no TypeError is thrown.

4. Variable parsing in strings specified in double-quotes and with heredoc
is also affected. This removes the distinction between using the
concatenation operator and variable parsing. With `string_operators` a
TypeError is thrown when using a boolean, array, or resource in variable
parsing.

Arnold

--000000000000fd237505a5b6fa1e--