Here is a better example, not involving subranges. Maybe Nim is working as intended, but as a new user of Nim, it seems strange. # this is a nim test program import tables var map = initTable[int, int]() const print = echo let ani = 0 ani8 = 0i8 ani16 = 0i16 ani32 = 0i32 ani64 = 0i64 anu = 0u anu8 = 0u8 anu16 = 0u16 anu32 = 0u32 anu64 = 0u64 print high(int) # prints 9223372036854775807 # the ## lines cause a type error with Nim 1.2.0 map[ani] = ani map[ani8] = ani8 map[ani16] = ani16 map[ani32] = ani32 ## map[ani64] = ani64 ## map[anu] = anu ## map[anu8] = anu8 ## map[anu16] = anu16 ## map[anu32] = anu32 ## map[anu64] = anu64 Run
It seems like the only statement that should cause a type error is the last one, with an unsigned 64-bit integer, since a uint64 may not fit into an int64. I'll be glad to open an issue if this behavior is not intended.