Generic parameters `void` and `not void` clash about nimskull

[zerbina]

This is a general problem not strictly related to void. Generic parameters are ignored when comparing routine signatures for the purpose of disallowing re-definitions (refer to searchForProcAux). For example:

proc test[T: int]() = discard
proc test[T: float]() = discard
# error: re-definition of test

proc test2[T: int](): T = discard
proc test2[T: float](): T = discard
# error: would lead to ambiguous calls

[saem]

I think discriminating based on generic parameter constraint types is reasonable, but looking for more input on that as well. Does it make sense that we differentiate based on generic parameters, in some fashion?

---

Assuming the above is true, then my mind turns to more practical concerns wrt implementation. I'm not sure if the current implementation can handle the weirder cases all that well, such as those involving type operations e.g.:

proc test[T: int]() = discard
proc test[T: float or int and not int]() = discard

proc test2[T: int](): T = discard
proc test2[T: float or int and not int](): T = discard

Perhaps we could start by swapping generic parameters for their constraints when considering signatures, that would mean test would still result in a redefinition, as no parameters would take the constraints of their respective T, and test2 would now work. At least the test scenario veers into the whole aliases vs phantom types (branding).

[disruptek]

I would feel better about the branding situation if I could figure out how to .borrow. distinct generics. I mean, I know that's already two sides of the pentagram of pain, but still...