Mirror of forum.nim-lang.org

7362 :: Why proc behavior depends if it defined after or before another proc?

• alexeypetrushin (orginal) [2021-01-09T17:58:48+01:00] view original

  The code below won't compile, but, if order of the init procs are changed - it would work, why?

  playground

  func init*[R, A](_: type[seq[R]], list: seq[A]): seq[R] =
    for v in list:
      result.add R.init(v)
  
  type OptionParams* = tuple
    right:     string
    tenor:     float
    moneyness: float
  
  func init*(_: type[OptionParams], v: OptionParams): OptionParams = v
  
  echo (seq[OptionParams]).init(@[("call", 120.0, 1.2)])
  Run

  If order changed, as in example below, it would work:

  type OptionParams* = tuple
    right:     string
    tenor:     float
    moneyness: float
  
  func init*(_: type[OptionParams], v: OptionParams): OptionParams = v
  
  func init*[R, A](_: type[seq[R]], list: seq[A]): seq[R] =
    for v in list:
      result.add R.init(v)
  
  echo (seq[OptionParams]).init(@[("call", 120.0, 1.2)])
  Run

---

• DeletedUser (orginal) [2021-01-09T18:12:05+01:00] view original

  Because the proc that uses R.init(v) uses what is called a "closed symbol choice" for init, meaning only the init definitions before it are possible symbol choices. To prevent this, use the mixin statement like so:

  func init*[R, A](_: type[seq[R]], list: seq[A]): seq[R] =
    mixin init
    for v in list:
      result.add R.init(v)
  Run

---