Anyways, the compiler should detect that both sides are QWord and promote them to a signed type. Now, the signed version of a QWord is not int64, it is int65 !
There is not an int65. Of course it is possible to create one. But the computation overhead, and that in a potentially big loop. talk about de-optimizing the code.
Loop variables are variables too, they are important too, just as much as any other. (If they were not, that would imply, that the entire loop was not important, and leave the question why I did write the loop at all)
They are not important, if they are only used as index inside the loop. Then the variables are just an abbreviation for the actual data.
"variables are just an abbreviation for the actual data"
How does that differ to none loop variables?
In functional programming languages you use map, and do not even have loop variables for it.
E.g.:
for i := 0 to stringlist.count - 1 do
writeln(stringlist[i]);
would be
map(stringlist, writeln)
Actually, in the above "writeln" is simple a pointer to a procedure, that is declared elsewhere.
"map" is a function (it may be intrinsic, but that does not change anything), inside which you loop over the list, and for that loop there is a loop variable.
That is exactly what I wrote. You can put the loop in a procedure of its own. That works well in current fpc too. (except you cant do @writeln, to get a reference to that procedure).
You are comparing apples and oranges. map has nothing to do with the presence or declaration of the loop var, it simple has something to do with putting the loop into another procedure.
off topic
In functional programming languages
map exists in OO style too.
Also pascal fully supports functional programming too.
"map" has nothing todo with functional programming.
You could have Tstringlist.map(eventProc) // that is OO