Given proc and type from two different modules named the same thing, Nim prefers the type

[AlexMax]

a.nim

type
  foo* = object
    x: int
    y: int

b.nim

type
  testing* = object
    z: int

proc foo*(t: testing) =
  echo "doink!"

c.nim

import a, b

var x: testing
x.foo

If you then compile c, this results in an error like:

c.nim(4, 2) Error: type mismatch: got <testing> but expected 'foo = object'

It looks to me that given the ambiguous identifier foo, nim prioritizes the type over the proc.

This is unexpected behavior. Usually, if you have a naming conflict between two modules (for example, two procs or two types named the same thing), you get the following error message:

c.nim(3, 9) Error: ambiguous identifier: 'foo' --use a.foo or b.foo

And of course, if you try defining a type and a proc with the same name in a single module, you get another error.

c.nim(6, 6) Error: redefinition of 'foo'; previous declaration here: c.nim(2, 2)

So for consistency's sake, it seems like Nim should error if there's a naming conflict between a type and a proc in two different modules.

EDIT: It's worth mentioning that you don't really encounter this issue if you follow NEP1. Still, not everything does.

[dom96]

This is a bug, but please follow NEP1, it's there for a reason.

[metagn]

Works now and in 2.0

[metagn]

It looks to me that given the ambiguous identifier foo, nim prioritizes the type over the proc.

The opposite is true in case of calls, in this case the foo in x.foo is treated like a regular expression which makes a symchoice since #23123 and overload resolution on symchoices only considers routines (this also happens in normal calls if type symbols are ambiguous). But this isn't mentioned in the spec, this should be done if a test is added for this, or maybe reconsidered.