You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Between logically identical uses of typeclasses, some work as expected and some lead to mysterious type resolution errors.
Description
whendefined(nodistinct):
# type mismatch: T1 can only resolve to one type per instantiationtypeT1=int|seq[int]
procp1(a, b: T1): int=when a isint: result.inc a else: result.inc a[0]
when b isint: result.inc b else: result.inc b[0]
elifdefined(withdistinct):
# this workstypeT1=int|seq[int]
procp1(a, b: distinctT1): int=when a isint: result.inc a else: result.inc a[0]
when b isint: result.inc b else: result.inc b[0]
else:
# this also works, even though it's an equivalent-looking expansion of the# 'nodistinct' case that doesn't workprocp1(a: int|seq[int], b: int|seq[int]): int=when a isint: result.inc a else: result.inc a[0]
when b isint: result.inc b else: result.inc b[0]
echo"p1: ", p1(1, @[2])
echo"p1: ", p1(@[1], 2)
echo"p1: ", p1(@[1], @[2])
# If you realize you're repeating an implicit typeclass in your code, and# decide to give it a name rather than repeat yourself so much, your code can# suddenly fail to typecheck.# suggestion: make the 'nodistinct' case behave the same as 'withdistinct',# or give a clear error when a call would only typecheck with distinctwhendefined(tupled):
# type mismatch: the implicit typeclass can only resolve to one type per# instantiation - even though very similar code just worked, above!procp2(a: (int|seq[int], int|seq[int])): int=when a[0] isint: result.inc a[0] else: result.inc a[0][0]
when a[1] isint: result.inc a[1] else: result.inc a[1][0]
elifdefined(tupled_distinct):
# type mismatch: the distinct-typeclass workaround also stops workingtypeT2=int|seq[int]
procp2(a: (distinctT2, distinctT2)): int=when a[0] isint: result.inc a[0] else: result.inc a[0][0]
when a[1] isint: result.inc a[1] else: result.inc a[1][0]
else:
# this worksprocp2[A, B: int|seq[int]](a: (A, B)): int=when a[0] isint: result.inc a[0] else: result.inc a[0][0]
when a[1] isint: result.inc a[1] else: result.inc a[1][0]
echo"p2: ", p2((1, @[2]))
echo"p2: ", p2((@[1], 2))
echo"p2: ", p2((@[1], @[2]))
# suggestion: make typeclasses behave the same with tuples as without themimport sets
whendefined(higher):
# Error: undeclared field: 'key' for type sets.OrderedKeyValuePairfuncp4(list: OrderedSet[int|string]): string=for x in list: return$x
elifdefined(higher_named):
# this workstypeT4=int|stringfuncp4(list: OrderedSet[T4]): string=for x in list: return$x
elifdefined(higher_explicit):
# this worksfuncp4[T: int|string](list: OrderedSet[T]): string=for x in list: return$x
else:
# this worksfuncp4(list: OrderedSet[int] |OrderedSet[string]): string=for x in list: return$x
echo"p4: ", p4(toOrderedSet([1, 2]))
echo"p4: ", p4(toOrderedSet(["1", "2"]))
# suggestion: make all of these alternatives equivalent
Alternatives
No response
Examples
No response
Backwards Compatibility
No response
Links
No response
The text was updated successfully, but these errors were encountered:
Summary
Between logically identical uses of typeclasses, some work as expected and some lead to mysterious type resolution errors.
Description
Alternatives
No response
Examples
No response
Backwards Compatibility
No response
Links
No response
The text was updated successfully, but these errors were encountered: