4 ms·

The problem is not even with "easy to mix up operators" for this, it's about languages without a strong and static enough type system. While the particular prob

by anyfoo 5y ago

The problem is not even with "easy to mix up operators" for this, it's about languages without a strong and static enough type system. While the particular problem Google hit is a bit more subtle (involving undefined behavior), in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they often resolve to different types. In C "if (foo = bar)" and "if (foo == bar)" are both legal, because pretty much any type can be automatically coerced into a boolean. In many modern languages that is not the case. (Of course if you have assignments as expressions you are still screwed if foo and bar are both boolean to begin with, so some languages got away with that, too. And for fairness I should say that C at the very least warns if you don't explicitly put parentheses around the assignment, nowadays.)

crazygringo 5y ago
> in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they resolve to different types. That's not true at all. Whenever you're intending to compare equality, they're usually going to be the same type already unless you're being really slopping in a scripting language like JavaScript or PHP -- but even then they're usually two numbers, two strings, or two booleans. The whole problem here is where foo and bar are both integers, or booleans, or whatever you want, and instead of typing "if (foo == bar)" you type "if (foo = bar)". Strong typing does nothing whatsoever to help in this common situation.
- anyfoo 5y ago
  No. It can help because the result of the expression would have a different type, one that "if" does not accept. If a and b are integers, then the expression "a = b" is an integer too, but "a == b" is a boolean. In a strongly typed language, you can assume that "if" only accepts booleans.
  - tialaramex 5y ago
    Yeah. The direction of modern languages has been away from features like this which are "clever" but don't express anything you couldn't have said by another means - and yet allow programmers to accidentally write something nobody would ever want. Assignment shouldn't have a return type. Compound assignment operators? Likewise. You never need this return value, and sometimes you may use it by mistake. So, abolish it. In C++ not only do operators that shouldn't have a return value have one anyway, the type of that value might be anything. You can even overload both ++ operators to return different unrelated types so that mytype aThing { blah }; auto a = aThing++; // returns a String "Fuck tha police" auto b = ++aThing; // returns a double, 8.63 The Jeff Goldblum GIF is often the appropriate reaction to C++ features: "Your scientists were so preoccupied with whether or not they could, that they didn't stop to think if they should"
bobbylarrybobby 5y ago
In many languages, such as python, assignments are statements, not expressions, and so they don’t evaluate to anything at all.
- anyfoo 5y ago
  Yeah, I covered that at the end.

by anyfoo 5y ago

crazygringo 5y ago

> in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they resolve to different types. That's not true at all. Whenever you're intending to compare equality, they're usually going to be the same type already unless you're being really slopping in a scripting language like JavaScript or PHP -- but even then they're usually two numbers, two strings, or two booleans. The whole problem here is where foo and bar are both integers, or booleans, or whatever you want, and instead of typing "if (foo == bar)" you type "if (foo = bar)". Strong typing does nothing whatsoever to help in this common situation.

anyfoo 5y ago
No. It can help because the result of the expression would have a different type, one that "if" does not accept. If a and b are integers, then the expression "a = b" is an integer too, but "a == b" is a boolean. In a strongly typed language, you can assume that "if" only accepts booleans.
- tialaramex 5y ago
  Yeah. The direction of modern languages has been away from features like this which are "clever" but don't express anything you couldn't have said by another means - and yet allow programmers to accidentally write something nobody would ever want. Assignment shouldn't have a return type. Compound assignment operators? Likewise. You never need this return value, and sometimes you may use it by mistake. So, abolish it. In C++ not only do operators that shouldn't have a return value have one anyway, the type of that value might be anything. You can even overload both ++ operators to return different unrelated types so that mytype aThing { blah }; auto a = aThing++; // returns a String "Fuck tha police" auto b = ++aThing; // returns a double, 8.63 The Jeff Goldblum GIF is often the appropriate reaction to C++ features: "Your scientists were so preoccupied with whether or not they could, that they didn't stop to think if they should"

bobbylarrybobby 5y ago

In many languages, such as python, assignments are statements, not expressions, and so they don’t evaluate to anything at all.

anyfoo 5y ago
Yeah, I covered that at the end.