# [RFC] Strict operators directive - Thread: https://externals.io/message/110172 - Original archive: https://news-web.php.net/php.internals/110172 - Started by Arnold Daniels on 2020-05-15T22:03:05+00:00 - Messages: 6 - 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 --- ## #110172 — Arnold Daniels — 2020-05-15T22:03:05+00:00 URL: https://externals.io/message/110172#110172 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 --- ## #110173 — Dan Ackroyd — 2020-05-16T09:08:13+00:00 URL: https://externals.io/message/110172#110173 · In reply to: #110172 On Fri, 15 May 2020 at 23:03, Arnold Daniels 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 --- ## #110183 — Mark Randall — 2020-05-16T14:20:43+00:00 URL: https://externals.io/message/110172#110183 · In reply to: #110172 > 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 years warning that they've got that long to add their correct castings etc before the old behaviour is removed. --- ## #110185 — Max Semenik — 2020-05-16T14:56:37+00:00 URL: https://externals.io/message/110172#110185 > 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. -- Best regards, Max Semenik --- ## #110286 — Christian Schneider — 2020-05-27T09:59:27+00:00 URL: https://externals.io/message/110172#110286 · In reply to: #110185 Am 16.05.2020 um 16:56 schrieb Max Semenik : > > > > […] > > > 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 --- ## #110288 — Ben Ramsey — 2020-05-27T16:52:21+00:00 URL: https://externals.io/message/110172#110288 · In reply to: #110172 > > > 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