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.