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.

Reply via email to