Mirror of forum.nim-lang.org

4094 :: questions on proposal to default initializing string, seq to empty ("", @[]) instead of `nil`

• timothee (orginal) [2018-07-31T21:36:38+02:00] view original

  Curious if this was discussed somewhere, if so please point me where.

  The only thing I could find is https://forum.nim-lang.org/t/1003 (Proposal: For seq & string, default init is "init to empty" not "init to nil") however, @araq's response there https://forum.nim-lang.org/t/1003#6079 (make 'nil' work for 'add' and 'len') doesn't mention the plan is to default initialize string, seq to "" and @[].

  Is the plan to have all these?

  • A1: make var a: string initialize to "" (instead of current nil)
  • A2: make var a: seq[T] initialize to @[] (instead of current nil)
  • A3: make var a: string = nil a compile error (likewise for seq[T])
  • A4: make var a:string; if a == nil: discard a compile error (likewise for seq[T])
  • A5: make var a:string; a = nil a compile error (likewise for seq[T])
  • Q1: If so, is it guaranteed that var a: string with "" initialization will NOT allocate? (currently IIRC it DOES allocate, see https://github.com/nim-lang/Nim/issues/8373); likewise for seq[T]
  • Q2: will it still be usable in same contexts, especially at compile time

---

• Araq (orginal) [2018-07-31T23:17:13+02:00] view original

  The nil memory address will mean ""/@[] but cannot be written as nil in Nim, it's just an implementation detail in order to not allocate these.

  Q2: yes.

---

• timothee (orginal) [2018-07-31T23:34:01+02:00] view original

  will Q1 be eventually supported? (ie, no allocation)

---

• Araq (orginal) [2018-07-31T23:59:01+02:00] view original

  Yes, these two statements will be identical.

---

• timothee (orginal) [2018-08-01T03:29:05+02:00] view original

  I'm assuming by "Yes, these two statements will be identical" you also mean "no allocation in these cases". ok. just wanted to be clear on that important point.

---

• twetzel59 (orginal) [2018-08-02T16:19:18+02:00] view original

  This is very exciting!

  @Araq, what about user defined ref types (e.g. ref object)? How will nil be handled for those?

---