09-09-2015, 03:03 PM
Actually I agree with ivorget. I also think this could be improved. I only disagree classifying it as a bug, I think it's an improvement, because guessing the datatype the programmer wanted was not supposed to be the compiler's responsibility, and there's no perfect solution for all cases anyway.
However solving this problem is trickier than suggested. When both upperbound and step are constant expressions, type should not be inferred based only on upperbound and step separately (as current implementation) or upperbound+step and step (as ivorget suggested). The compiler must consider all 3. Otherwise some of the following cases won't be identified properly:
However solving this problem is trickier than suggested. When both upperbound and step are constant expressions, type should not be inferred based only on upperbound and step separately (as current implementation) or upperbound+step and step (as ivorget suggested). The compiler must consider all 3. Otherwise some of the following cases won't be identified properly:
Code:
FOR f=x TO 255 STEP 1: NEXT f ' cannot be UBYTE due to upperbound+step = 255+1
FOR f=x TO 256 STEP -1: NEXT f ' cannot be UBYTE due to upperbound = 256
FOR f=x TO -129 STEP 1: NEXT f ' cannot be BYTE due to upperbound = -129
FOR f=x TO -128 STEP -1: NEXT f ' cannot be BYTE due to upperbound+step = -128-1