Mirror of forum.nim-lang.org

1460 :: Better compiler error messages about immutable types

• jrenner (orginal) [2015-07-19T18:59:39+02:00] view original

  I think it's pretty easy to make a mistake like:

  
  let myTable = initTable[int, string]()
  Run

  and not realize your mistake when you try to add something to the table. The compiler error messages don't give you enough hints:

  
  myTable[33] = "cat"
  Run

  
  opcode.nim(64, 12) Error: type mismatch: got (Table[system.int, system.string], int, string)
  but expected one of:
  system.[]=(a: var array[Idx, T], x: Slice[[]=.Idx], b: openarray[T])
  system.[]=(s: var string, x: Slice[system.int], b: string)
  system.[]=(a: var array[Idx, T], x: Slice[system.int], b: openarray[T])
  system.[]=(s: var seq[T], x: Slice[system.int], b: openarray[T])
  tables.[]=(t: var CountTable[[]=.A], key: A, val: int)
  tables.[]=(t: CountTableRef[[]=.A], key: A, val: int)
  tables.[]=(t: var OrderedTable[[]=.A, []=.B], key: A, val: B)
  tables.[]=(t: var Table[[]=.A, []=.B], key: A, val: B)
  tables.[]=(t: TableRef[[]=.A, []=.B], key: A, val: B)
  tables.[]=(t: OrderedTableRef[[]=.A, []=.B], key: A, val: B)
  Run

  I guess a trained Nim user will see the var and quickly know what they've done. But it's not intuitive at all, especially for new users.

---

• Varriount (orginal) [2015-07-19T20:38:23+02:00] view original

  What message do you think the compiler should produce that would be specific to this case? Keep in mind that a procedure taking a var type may not necessarily be modifying it.

---

• dom96 (orginal) [2015-07-20T04:32:12+02:00] view original

  It would be nice if the compiler attempted to give hints on how to fix errors. In this case the compiler could output at the end: "Are one of your parameters not mutable?" or something similar.

  Another nice thing might be getting the compiler to find the closest match and tell the user the differences.

---

• jrenner (orginal) [2015-07-20T05:42:26+02:00] view original

  dom96, Yes I think something along those lines would be nice. As mention in the 2nd post in this thread the compiler can't be sure that that is the case, so it could merely offer it as a suggestion. I think for error messages in general, Clang is really good example to follow, though I can't think of any off the top of my head because I don't do too much C programming.

---

• micks (orginal) [2016-07-05T09:54:28+02:00] view original

  I recently ran into the same problem and as a newbie couldn't see how the output was relevant to my issue. Changing the actual variable definition to "var" solved my issue.

  With the above example the current (nim 0.14.2) error message is just "Error: could not resolve myTable[33]" - and that only when assigning to myTable - when reading that's OK.

  I really like nim as a language and can see its potential, but as a newbie it can get a hell complicated to get it to compile correctly (and I speak with a background of a long-term C and C++ programmer).

---