At this point I don't even know what you're on about. You seem to be throwing objections for that sake alone.
Not at all, or not intentional.
I am not sure, if the comments left by some of the members of the fpc team, indicate that the idea is already rejected. If so, then the argument is indeed moot. Otherwise, I do have a point.
Non sure which part you are not sure about. So below may contain some repeats. Sorry.
First about "optional". And that really is the all defining point. (Despite your initial laughter on this)
*IF* this could be truly optional, then it would never affect me (or anyone who has my view on it). If it would never affect me, then I had no other arguments. (Same as, I am not using language X, so I do not care what people do to it)
But it will (as in: there is a possibility) affect me. My boss may ask me to use a 3rd party lib, that uses it, and I may have to read the code.
So my reason is: I argue about it, because it can affect me.
This is not about how you would use it, you would not be the only one using it.
at how it would be implemented would really find all that much issue.
This is not about implementation. I am not maintaining the compiler, so that does not matter do me. And I wouldn't ever notice, if fpc would change a few millisec in speed (faster/slower), or fpc.exe grew a bit in size. None of that is my problem.
You said, you would use it "reasonable", e.g. only short var names to minimize (IMHO still not avoid) conflict with identifiers in other scopes. But other people will (not "may", definetely "will") use it more aggressive. (And I (or others like me) may/will in future be forced to read there code).
- less typing (IIRC that was dismissed / should be taken care of, by codetool)
a- you might dismiss it, I don't
Ok.This is personal preference. So it cant be argued.
But IIRC on the link to the fpc wiki, it is mentioned that this is not accepted as reason for a feature. (I didnt write that wiki)
- less code to read (apparently not, since hiding/folding is dismissed as solution
Not so much that it is "less code to read" as it is "less clutter in the VAR list"
And as I said, to me personally, this decreases readability of the overall code. (And I am probably not alone on this) So this argument goes both ways.
Beside, if codetools would (for loop vars) insert:
{$region 'loop vars' /hide}
var
i: integer;
{$endregion}
The editor can be patched to entirely hide (like comment) this. So the "clutter" would never be visible. (Yet I could disable region hiding in my options, so it would not affect me).
That leaves automatically follow the type of the bounds if they change.
Using a smaller (word instead of int) type for optimization? ...
In any case the rules for the optimization are the same in both cases.
So, no real issue given sober constraints. If the range is variable, then the variable define the range. ...
I dont understand. You still havent explained what the benefit is (well: less typing, is now on).
- optimization is not, because it can be done, even if the type is declared.
- following the type of the bounds. That could be seen as benefit, but it is extremely rare (as both bounds need to change), and it can also be a danger, as unintended changes to the bound will silently keep compiling. So this evens out (In my book the danger even weighs more than the "benefit")
There is one other point: Having a smaller scope var the loop var. Such scopes where proposed before and rejected. And to me they decrease readability, because they also introduce extra work to find all variables/properties/members/identifiers that are visible to a procedure. (See my comment on "with is bad, because it does something similar).
You didn't miss making the simple into complex, that is for sure.
Sorry, I did not MAKE it complex. I merely pointed out how complex this is (and always was).
Conclusion. In my attempt to learn the benefits:
- I accept that less typing matters to you (But it is not (enough of a) reason to me).
- You find the presence of the loop var in the var section "clutter" (less readable?). To me there absence decreases readability. (I explained that in detail, in previous post)
Both of those are personal preferences. Except the latter (absence) is a fundamental change to the definition of pascal, and would void one of the reasons why I like pascal. So it would be a severe loss.
For all other things, that I could imagine someone might see as benefit, I have explained why they are not.
- optimization of generated machine code: possible in exactly the same way, even if var is declared
- changing type, if boundary changes: can go wrong as easily as it might be helpful / in any case: it is rare to ever happen at all
- micro-scoped var declaration: see argument on "absence in var block"