Generic parameters void and not void clash

[disruptek]

Specification

Generic parameters void and not void clash with Error: overloaded 'test' leads to ambiguous calls

Example

type
  A[T] = object
    when T isnot void:
      x: T

proc test[T: void](): A[T] = discard

proc test[T: not void](): A[T] = discard

discard test[void]()
discard test[float]()

Actual Output

Error: overloaded 'test' leads to ambiguous calls

Expected Output

Possible Solution

Better error message.

Additional Information

Nimskull Compiler Version 0.1.0-dev.21221 [linux: amd64]

Source hash: bd28145a33ab7540d08258b0fd306c65947c3f02
Source date: 2024-02-11

active boot switches: -d:release -d:danger⏎

[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...