Mirror of forum.nim-lang.org

1003 :: Proposal: For seq & string, default init is "init to empty" not "init to nil"

• jboy (orginal) [2015-03-09T10:28:11+01:00] view original

  When you declare a variable of type seq or string without an initializer, it is default-initialized to a nil (zero) value, which is NOT a valid value for a seq or a string.

  This is done to minimise heap allocations, but the tutorial emphasises "most sequence operations cannot deal with nil" and thus recommends that "one should use empty sequences @[] rather than nil as the empty value". Likewise when describing strings.

  • This default initialization to nil seems to be a cause of recurring confusion.
  • And it seems like a predictable source of inexplicable crashes (in code that compiled without warning) for both beginners & tired programmers. A single omission of = @[] or = "" when you declare the variable, and your supposedly-valid code has become dangerous.
  • And it's particularly incongruous, because Nim otherwise goes out of its way to emphasise that strings & seqs are NOT pointers, but values with value semantics.

  Hence, I propose that the default initializer for variables be changed from "init-to-nil" to "init-to-empty". This would change the initializer value for seq from nil to @[]; and for string from nil to "". No other types in this table would be changed (other than the change in meaning for what "default(A)" means for tuples, object, etc.).

  Immediately below that table, there is already the note: "The implicit initialization can be avoided for optimization reasons with the noinit pragma."

  A corresponding nilinit pragma could be added to the language to revert to init-to-nil rather than init-to-empty behaviour. Alternatively, you could explicitly initialize your seq to nil:

  
    var s: seq[int] = nil
  Run

  This change to default initialization won't break any existing code, merely make it slightly less efficient until the declaration has been updated with a nil-assignment. In contrast, any bugs in existing or future code will now be safely initialized to valid (empty) states.

  Further details:

  • Make newSeq[T](len): seq[T] init-to-empty all its entries recursively, unless you use either newSeqNoInit[T](len): seq[T] or newSeqNilInit[T](len): seq[T].
  • new[](T: typedesc): ref T will init-to-empty the allocated object; to avoid this, use either newNoInit[](T: typedesc): ref T or newNilInit[](T: typedesc): ref T.
  • Likewise with new[T](a: var ref T) vs newNoInit[T](a: var ref T) & newNilInit[T](a: var ref T).
  • If desired, a module-wide nilInit pragma could be provided in the language, that tells the compiler that any variables declared in that module, that are not explicitly initialized, should be nil-initialized rather than empty-initialized.

---

• Araq (orginal) [2015-03-09T10:48:18+01:00] view original

  This is what my todo says:

  • make 'nil' work for 'add' and 'len'

  Which addresses this common gotcha with very similar end results. And it's cheaper since the nil tests are faster than heap allocations.

---

• jboy (orginal) [2015-03-09T13:41:35+01:00] view original

  Great! I think that would greatly mitigate the problems I'm concerned about. Thanks!

---