in inside a template not lowered to contains if called from another module

[timotheecour]

Example

# t12344b.nim:
import std/sets
template foo*[T](a: T) =
# proc foo*[T](a: T) = # works
  var s: HashSet[T]
  # echo contains(s, a) # works
  echo a in s # BUG
when isMainModule: foo(1) # works

# t12344.nim:
import t12344b
foo(1)

nim r t12344b # works
nim r t12344 # bug

Current Output

Error: type mismatch: got <HashSet[system.int], int literal(1)>

Expected Output

works

Possible Solution

lower in to contains in semTemplateDef (in generic pre-pass, it works, so semgnrc does the right thing here)

Additional Information

• similar to for loop invoked from generic procedure defined in another module cant find items iterator #11167 but different; a similar approach could be used for both
• see also for loop invoked from generic procedure defined in another module cant find items iterator #11167 (comment)

[Araq]

There is no bug here, template expansion is well defined.

[timotheecour]

but what is a in b if not operator sugar for contains(b, a) [1]?

this makes in inside public templates not usable unless you expose your internal details and require client code to also import std/sets (etc) whenever you use foo

The situation is similar to for a in b which doesn't work in generics in similar conditions (refs #11167 ), forcing you to use for a in items(b).

How is the suggested lowering worse than the current situation?

[1] refs: https://nim-lang.github.io/Nim/system.html#contains%2Cset%5BT%5D%2CT

One should overload this proc if one wants to overload the in operator.
The parameters are in reverse order! a in b is a template for contains(b, a). This is because the unification algorithm that Nim uses for overload resolution works from left to right. But for the in operator that would be the wrong direction for this piece of code: [...]

[Araq]

How is the suggested lowering worse than the current situation?

A simple language with easy to explain quirks as the result of these simple rules is much better than a language that has many special cases that ends up with just the same amount of quirks. For example, every smart rewrite rule that we do has a direct impact on the understandability of Nim's macro system.

However, if Nim did template expansions eagerly, this would solve the problem too, without special casing for the in shortcut.

The situation is similar to for a in b which doesn't work in generics in similar conditions (refs #11167 ), forcing you to use for a in items(b).

The solution for this gotcha is to deprecate the implicit "items" altogether, not to introduce even more special cases.

[n0bra1n3r]

I wanted to add my 2 cents and mention that a similar thing happens with dotOperators in templates and generic procs. I end up having to do something like cppObject.`.()`(CppMethod) inside a template/generic declared in one module that is called from another module that doesn't import the dotOperator implementations. If this is not intended (or a totally separate issue), I can file a separate bug.

I wanted to mention that I encountered something like this in D, but that language has 'local imports', so I could import things from inside templates. Can't imagine how difficult that would be to implement in Nim given how complex the macro system is, so maybe something like bind could work for cases like this?

[Araq]

I wanted to mention that I encountered something like this in D, but that language has 'local imports', so I could import things from inside templates. Can't imagine how difficult that would be to implement in Nim given how complex the macro system is, so maybe something like bind could work for cases like this?

Local imports were so problematic in D that they had to change the scoping rules just for them, I don't want to repeat their mistakes. The real solution is a bind statement, as you said.