Mirror of forum.nim-lang.org

9849 :: Why Nim does not support comparison between different types?

• Luethlee (orginal) [2023-01-27T08:43:18+01:00] view original

  Hi, I recently started learning Nim. Nim is an excellent language, but I worry about less support of types. Even primitive types are not well supported by basic functions.

  For example, I can't compare two different types of integers.

   Nim
  var
       x = 100'u64
       y = 100'i32
  
  if x == y:
      echo "x eq y"
  Run

  This code fails because it's comparing two different integer types. However, in C,

   C
  int main(){
  unsigned long long x = 100;
  int y = 100;
  if (x == y){
      printf("x eq y");
  }
  }
  Run

  This code works as expected.

  Why does Nim not support different types of comparison?

---

• Araq (orginal) [2023-01-27T09:00:26+01:00] view original

  There is no reason it should compile as promoting int32 to uint64 is impossible (uints don't have negative numbers) and likewise uint64 has many positive numbers that don't fit an int32. C's rules work so poorly in practice that every production compiler has an elaborate set of warnings in order to detect these problems.

---

• Luethlee (orginal) [2023-01-27T09:07:14+01:00] view original

  Okay, because I am from Python, it was a little inconvenient for me. However, other typed language such as Rust does not allow such comparison, so it is natural. I am going to use i64 mainly rather than u64 for compatibility. Thank you.

---

• shirleyquirk (orginal) [2023-01-27T09:37:24+01:00] view original

  char a = 0x80;
  char b = a << 1;
  printf("%s equal\n",b == a << 1 ? "" : "not");
  Run

  What will that print?

  integer promotion is evil.

---

• mratsim (orginal) [2023-01-27T10:09:18+01:00] view original

  This code works as expected.

  No this is one of large source of bugs in C codebases, and why everyone is promoting safer languages.

  The whole point of a type system is avoiding mixing apples and oranges and ducks unless you explicitly ask for it.

---

• Luethlee (orginal) [2023-01-27T10:42:45+01:00] view original

  I expected "equal" to print, but it was "not equal." Is that due to implicit type conversion..?

---

• dlesnoff (orginal) [2023-01-27T11:54:41+01:00] view original

  a << 1 is an integer while b is a char. The first a << 1 is converted back to a char.

---

• cblake (orginal) [2023-01-27T18:24:52+01:00] view original

  There is also a problem in @shirleyquirk's example of whether unmodified char is signed or unsigned: https://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-by-default

  Basically char a could be either +128 or -128 before it is promoted to a C int. So, a << 1 can be either + or -256. Both those values happen in this case to get implicitly truncated to 0 by being stored in char b.

  It's subjective what is most confusing about all this, of course. ;-)

---