Inconsistent template behavior (bind vs. mixin)

[gmpreussner]

The following setup works:

a.nim

template foo*() = discard

b.nim

template bar*() = foo()

c.nim

import a, b

bar()

However, if we replace the template a.foo with an overload of an existing template, such as system.pop, the code no longer compiles, because the compiler only finds system.pop:

a.nim

template pop*() = discard

b.nim

template foobar*() = pop()

c.nim

import a, b

foobar()

Output:

Hint: system [Processing]
Hint: c [Processing]
Hint: a [Processing]
Hint: b [Processing]
c.nim(4, 7) template/generic instantiation from here
b.nim(5, 6) Error: type mismatch: got ()
but expected one of: 
system.pop(s: var seq[T])

[gmpreussner]

Workaround:

b.nim

template foobar*() =
  mixin pop # force `pop` symbol to be open
  pop()

[Araq]

The compiler and the spec agree. In your first example 'foo' is unbound identifier because system doesn't have 'foo', so it is put into a 'mixin' context. In your second example 'pop' is not unbound, but it is not overloaded either, so it is put into a 'bind' context. The manual needs to be updated with an example like this, but apart from that it works as indented.

[gmpreussner]

I feel that this is problematic though, because module b.nim cannot possibly know all existing symbols in advance. So it either needs to always use mixin for its template usages (which is cumbersome), or it may inadvertently break in the future if c.nim suddenly decided to import some other module that conflicts.

In other words: module b.nim can break by modifying unrelated module c.nim

[gmpreussner]

a.nim

template blah*() = discard

b.nim

template foobar*() = blah()

c.nim

import a, b

foobar()

d.nim

proc blah*() = discard

This will compile, but if we add import d to c.nim, then b.nim will fail to compile.

[Araq]

Yup. It's really bad, but I know of no alternative solution that is as convenient in practice. And also in practice it hasn't come up.

[Araq]

This will compile, but if we add import d to c.nim, then b.nim will fail to compile.

This is a different topic though, IMO. The compiler is right and then it becomes ambiguous.

[gmpreussner]

Well, it came up for me today while writing a library of reusable templates :)

Can't the compiler know that both template foo and proc foo exist, and then pick the best match?

[Araq]

Can't the compiler know that both template foo and proc foo exist, and then pick the best match?

But that is exactly what it does?

[gmpreussner]

No, it doesn't seem to find the mixin template if a symbol exists:

but expected one of: 
system.pop(s: var seq[T])

Should have found a.pop as well, no?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you think it is still a valid issue, write a comment below; otherwise it will be closed. Thank you for your contributions.