Description
The toCritBitTree
func (from the critbits
module) doesn't work with non-string values.
Example
import critbits
echo {"a": 0, "b": 1}.toCritBitTree
Current Output
Error:
/home/<censored>/Projects/Nim/testing/src/testing.nim(17, 25) template/generic instantiation of `toCritBitTree` from here
/home/<censored>/.choosenim/toolchains/nim-#devel/lib/pure/collections/critbits.nim(538, 28) Error: type mismatch: got <CritBitTree[system.string], string, int>
but expected one of:
proc incl[T](c: var CritBitTree[T]; key: string; val: T)
first type mismatch at position: 3
required type for val: T
but expression 'item[1]' is of type: int
3 other mismatching symbols have been suppressed; compile with --showAllMismatches:on to see them
expression: incl(result, item[0], item[1])
Expected Output
{"a": 0, "b": 1}
Possible Solution
Currently, the signatures of the toCritBitTree
funcs are as follows (https://github.com/nim-lang/Nim/blob/devel/lib/pure/collections/critbits.nim#L534):
func toCritBitTree*[A, B](pairs: openArray[(A, B)]): CritBitTree[A]
func toCritBitTree*[T](items: openArray[T]): CritBitTree[void]
If the result type for the first version is changed to CritBitTree[B]
, the bug is fixed (since A
is the key type and B
the value type). However, the generic type parameter for the keys (A
and T
) is unnecessary in both versions, since CritBitTree
s always have string
keys. So the fixed signatures should be (the actual implementation doesn't need to change):
func toCritBitTree*[T](pairs: openArray[(string, T)]): CritBitTree[T]
func toCritBitTree*(items: openArray[string]): CritBitTree[void]
This both fixes the bug and produces better error messages when someone attempts to use non-string keys.
Additional Information
This is not a regression, since the code didn't change since it's addition in #15444.
$ nim -v
Nim Compiler Version 1.5.1
git hash: 297c8e403d110dd872e070563328f4e0c734cd01