proc a(s: int) =
echo s
proc a(c: int) =
echo c
#a(1)
Compiles fine for Nim 0.13 as long as a() is not called. That means that wrapper files with conflicting procs compile fine too -- as long an no one is using them.
proc newFile*(path: cstring): GFile {.importc: "g_file_new_for_path",
libgio.}
proc newFile*(uri: cstring): GFile {.importc: "g_file_new_for_uri",
libgio.}
proc newFile*(arg: cstring): GFile {.
importc: "g_file_new_for_commandline_arg", libgio.}
proc newFile*(arg: cstring; cwd: cstring): GFile {.
importc: "g_file_new_for_commandline_arg_and_cwd", libgio.}
proc newFile*(tmpl: cstring; iostream: var GFileIOStream; error: var GError): GFile {.
importc: "g_file_new_tmp", libgio.}
So using Nim proc name style can result in hidden bugs. I tried already to check for such hidden bugs in templates, which was much work already. But I thought that for procs the compiler would detect such problems -- I really think it did for some procs, I really fixed some proc names because the compiler told me to do. But above code gives me no warnings. :-(
[EDIT]
Maybe I should not say "same signature", but identical formal parameter list. When parameters have the same name I get a compiler error as desired:
proc a(s: int) =
echo s
proc a(s: int) =
echo s
Yes, i recall def reported this. If you want to call one or the other, you have to explicitly use a parameter. For example, this compiles:
proc a(s: int) = echo s
proc a(c: int) = echo c
a(s=1)
a(c=2)