> I don't believe this. Sorry. Your belief conflicts with Swift, which also disallows assignment in if conditions for this reason [0]. With GCC, that warns abo

> I don't believe this. Sorry. Your belief conflicts with Swift, which also disallows assignment in if conditions for this reason [0]. With GCC, that warns about "suggest parentheses around assignment used as truth value" when compiling with `-Wall` [1]. With the most popular Javascript linter [2]. The tricky part is that "that code isn't going to do what they wanted" isn't always immediately obvious. For example, when I google'd "comparison assignment typo", this is one of the first results: https://gitlab.freedesktop.org/wayland/weston/commit/209e8f177ac9cdc649e9c465571c1c2525e82190?w=1 https://gitlab.freedesktop.org/wayland/weston/commit/209e8f1... If the author was expecting that test to pass with the ==, then = would introduce a subtle but devastating bug. In the future, someone could break that function but it would never get caught by the unit tests. [0] https://docs.swift.org/swift-book/LanguageGuide/BasicOperators.html https://docs.swift.org/swift-book/LanguageGuide/BasicOperato... [1] https://gcc.gnu.org/ml/gcc/1998-07/msg00085.html https://gcc.gnu.org/ml/gcc/1998-07/msg00085.html [2] https://eslint.org/docs/rules/no-cond-assign https://eslint.org/docs/rules/no-cond-assign