It seems that the method call is being ambiguous ... Any other examples? I am learning looming for other potential gotchas...
import sequtils
var x = repeat("ab", 3)
echo x.type, ": ", x # seq[string]: @["ab", "ab", "ab"]
echo("\n *** now import both sequtils and strutils ***")
import sequtils, strutils
## now proc "repeat" is ambiguous - should we have a compiler warning in this case?
var y = repeat("ab", 3) # whoops: string: aaaaaaababab, method "repeat" is ambiguous
echo y.type, ": ", y, " <== whoops, 'string' repeat is used!?"
var z = sequtils.repeat("ab", 3) # add sequtils before repeat
echo z.type, ": ", z, " <== now it works"
It's just how the Nim overloading works, the most specific procedure is taken unless that is ambigous. A simple example to showcase this is:
proc echo(a: int) =
for x in 0..a:
echo "hmm"
echo 10
system.echo 10 # Force it to use the less specific `echo`
proc echo(a: int) = system.echo a
proc echo(b: int) = system.echo b
proc echo[T: int](c: int) = system.echo c
echo[int](30) # We only have one generic
proc echo[T: int](d: int) = system.echo d
echo(b = 30) # Named parameter overloads
echo(a = 30)
echo[int](c = 30)
echo[int](d = 30)
echo(30) # Ok now we're lost
Looks like a bug. You should report it on GitHub Issues.
I have seen compilation errors for ambiguous cases, but this one somehow does not show up
Looks like a bug. You should report it on GitHub Issues.
Yes, @masiarek2 is right. It's not a bug. In Nim manual, you can read that "If multiple routines match equally well, the ambiguity is reported during semantic analysis." Since repeat from sequtils is a generic match, it has a lower priority than a strutils' exact match. They are from different categories, so they aren't matching equally well - you won't get ambiguity error.