Hi, 20.02.2019 17:56, Martin Frb:
1) "for" (and other) loops with a long body also exist. So the problem is still there, if I encounter "i" in the middle of a
This is correct. Inline declaration will not be able to solve all problems in the galaxy, it could just help to relieve some of them.
1000 line for-loop, I still do not see its declaration. So far, no loss, but no gain either. 2) Nested loops exist. If in the middle of such a 1000 line for-loop, I want to declare another loop, then I need to find a free identifier for that variable. Today, I can do that by looking at the declaration on top of the procedure (and afaik depending on context, the class fields). With inline declaration, I have to find each of the 10 surrounding for-loops, scattered over a 1000 lines (And that is ignoring any variables declared inline, but not as part of a for-loop). I would say that is definitely worse.
You've probably missed that inline declartaion syntax is optional, not mandatory, and is intended to only be used where appropriate.
But just my 2 cents. Now do not tell me that those loops should be refactored, because they are based on your statement that this is not always sensible. 3) As for duck typing: for var i:= Func1 to Func2 do;
I think it is totally different from "normal" inline declarations and I don't like it actually.
Thank you, Regards, Nikolai
What if that is "QWord to int64(or at some future points changes to that)? What will "i" then be? And why? Or should that be a compile error? (Probably the best) _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
