SV Constraint :: Address must be aligned to the size of the transfer

Yes I do agree but I was curious on how the constraint solver interprets the if-constraint

if( i inside { [0:(axsize-1)] } )

I tried the following

module tb;  
  bit[11:0] axaddr;        
  bit[2:0] axsize ; // Defaults to 0
    
  initial begin
    foreach( axaddr[i] )  
     if( i inside { [0:(axsize-1)] } )      
       $display("i is %0d N (axsize-1) is %0h",i,(axsize-1));             
  end  
endmodule  

I observe “(axsize-1) is ffffffff” i.e result is 32-bit (even though width of axaddr is 12-bit )

LRM 12.7.3 mentions

When loop variables are used in expressions other than as indices to the designated array, they are auto-cast into a type consistent with the type of index. For fixed-size and dynamic arrays, the auto-cast type is int .

Since the iterator argument “i” is int type i.e 32-bit signed type result of (axsize-1) would be FFFF_FFFF.
However shouldn’t this constraint all the bits of axaddr to 0 ? ( as the if condition would be always true )

 rand  bit[11:0] axaddr;  // In reality Address Width is 32 bit i.e [31:0]        
 randc bit[2:0] axsize;

constraint Addr_Aligned1 {      
      
        // Assuming 'axsize' is 0  via in-line constraint                            
           foreach( axaddr[i] )
         {
            if( i inside { [0:(axsize-1)] } ) // Always true as i is inside {[0:FFFF_FFFF] } 
           {
               axaddr[i] == 0; // Shouldn't this constraint all bits to 0's ?
            }  
          }                                                                  
       }

A 2nd possibility I see is that the inside constraint is ignored as range isn’t [low:high] thereby leaving axaddr unconstrained.
However I don’t observe any warning message for the invalid range.

I observe that the o/p is tool depended edalink