converter gives inconsistent ambiguous call error with openarray

[timotheecour]

The behavior below seems inconsistent in 2 ways:

• why would there be ambiguity error for fun_bug but not for fun1? (ie why would openArray[T] vs seq[T] make a difference here)
• why would there be ambiguity error for fun_bug but not for fun2? (ie proc fun2(o: object) is implicitly generic and so is proc fun2(o: object|tuple) so I don't follow why there'd be a difference)

proc fun1[T](elements: seq[T]) =
  echo "ok1"

proc fun1(o: object|tuple) =
  echo "ok2"

proc fun2[T](elements: openArray[T]) =
  echo "ok1"

proc fun2(o: object) =
  echo "ok2"

proc fun_bug[T](elements: openArray[T]) =
  echo "ok1"

proc fun_bug(o: object|tuple) =
  echo "ok2"

type
  Obj1[T] = object
      v: T

converter toObj1[T](t: T): Obj1[T] = return Obj1[T](v: t)

proc main()=
  block:
    var x = @["hello", "world"]
    # no ambiguity error shown here even though this would compile if we remove either 1st or 2nd overload of fun1
    fun1(x)

  block:
    var x = ["hello", "world"]
    # ditto
    fun2(x)

  block:
    var x = ["hello", "world"]
    # Error: ambiguous call; both t0065.fun_bug(elements: openarray[T])[declared in t0065.nim(17, 5)] and t0065.fun_bug(o: object or tuple)[declared in t0065.nim(20, 5)] match for: (array[0..1, string])
    fun_bug(x)

main()

links

• related to Converters with openarray #2652 but doesn't seem the same issue
• should rules be changed so that converter is only looked up in case there is no match (consistent with fun case above)?

[narimiran]

In the mean time, instead of proc fun_bug(o: object|tuple), you can use proc fun_bug[T: tuple|object](o: T).

[krux02]

I marked it as low priority, because this seems to be a very special use case of converter usage and the workaround is really trivial in this case.

[metagn]

Works now according to #24082 (comment)