Mirror of forum.nim-lang.org

7393 :: Call `result.new` automatically in `proc`?

• alexeypetrushin (orginal) [2021-01-16T15:51:48+01:00] view original

  The code below would fail, because result is not allocated.

  Why not allocate it automatically? Compiler knows that there's assignment on result that's nil, and the code is local, shouldn't require complicated analysis and increase compile time.

  playground

  type Unit = ref object
    name: string
  
  proc build_unit(name: string): Unit =
    # result.new - why not call it automatically?
    result.name = name
  
  echo build_unit("Zeratul").repr
  Run

  Output

  
  Traceback (most recent call last)
  /usercode/in.nim(8)      in
  /usercode/in.nim(6)      build_unit
  SIGSEGV: Illegal storage access. (Attempt to read from nil?)
  Run

---

• haxscramper_ (orginal) [2021-01-16T16:17:26+01:00] view original

  I, too, find this someone annoying, but I think it mainly done because of

  • In case someone wants to assign a result from constructor proc this might lead to double memory allocation.
  • It is possible to implement this behavior using custom pragma annotations
  • This might break someone else's expectations - I do think it is annoying, but at the same time it is consistent with how ref variables are initialized.

---

• haxscramper_ (orginal) [2021-01-16T17:53:02+01:00] view original

  @alexeypetrushin I also forgot that it is possible to initialize result using result = Unit(name: name), which is probably the best option for various constructor procs like build_T, or newT

---

• boia01 (orginal) [2021-01-16T19:47:41+01:00] view original

  I would suggest that what we really want here is not implicit initialization with new but rather a warning that a ref is being accessed / assigned into without having been initialized previously.

---

• ElegantBeef (orginal) [2021-01-16T23:34:43+01:00] view original

  You could do as haxscramper suggested and make your own macro to handle that, or you could do the cool thing and use a DSL to make constructors. Atleast for constructors that solves the issue, though not nil might be able to resolve the issue you face, uncertain as I have not used it. Shameless promotion is shameless

---

• Araq (orginal) [2021-01-17T07:16:13+01:00] view original

  {.experimental: "strictNotNil".}
  
  type
    Foo = object
      field: int
  
  proc pr(): ref Foo =
    result.field = 90
  Run

  And I get a nice warning. :-)

---

• ElegantBeef (orginal) [2021-01-17T07:28:16+01:00] view original

  Eh, I was right. Also worth noting that the compiler option`--warningAsError` exists.

---