Awesome!
I was able to make some local changes to that pull request so that the types of
the expression parts that were problematic are included also:
...\overloaderrors.nim(9, 43) Error: type mismatch:
Expression: inNanoseconds(t2 - t1) / 1000
[1] int64 : inNanoseconds(t2 - t1)
[2] int literal(1000) : 1000
Expected one of (mismatch at position [#]):
[1] GVec2[/.T] : proc `/`[T](a`gensym156, b`gensym156: GVec2[T]): GVec2[T]
[1] GVec2[/.T] : proc `/`[T](a`gensym156: GVec2[T]; b`gensym156: T):
GVec2[T]
[1] GVec3[/.T] : proc `/`[T](a`gensym156, b`gensym156: GVec3[T]): GVec3[T]
[1] GVec3[/.T] : proc `/`[T](a`gensym156: GVec3[T]; b`gensym156: T):
GVec3[T]
[1] GVec4[/.T] : proc `/`[T](a`gensym156, b`gensym156: GVec4[T]): GVec4[T]
[1] GVec4[/.T] : proc `/`[T](a`gensym156: GVec4[T]; b`gensym156: T):
GVec4[T]
[1] float : proc `/`(x, y: float): float
[1] float32 : proc `/`(x, y: float32): float32
[1] int : proc `/`(x, y: int): float
[2] GVec2[/.T] : proc `/`[T](a`gensym156: T; b`gensym156: GVec2[T]):
GVec2[T]
[2] GVec3[/.T] : proc `/`[T](a`gensym156: T; b`gensym156: GVec3[T]):
GVec3[T]
[2] GVec4[/.T] : proc `/`[T](a`gensym156: T; b`gensym156: GVec4[T]):
GVec4[T]
Run
So the visual exercise becomes pairing up the [1] or [2]. The mismatched type
has been pulled out to immediately follow the `[#]` which prevents the mental
parsing of the type signature, but may be unnecessarily verbose.
Thoughts?
