[RFC] Strict operators directive

From: Date: Fri, 15 May 2020 22:03:05 +0000
Subject: [RFC] Strict operators directive
Groups: php.internals 
Request: Send a blank email to internals+get-110172@lists.php.net to get a copy of this message
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

« previous php.internals (#110172) next »