[fpc-devel] "Blank slate" next version of FPC

[Martin Frb]

On 20/02/2019 14:36, Paul van Helden wrote:
>
> So the argument against is: (1) split your long functions, because you 
> should; and (2) Wirth didn't do it, so good it is not.
>
> Long functions *might* be an indication of bad design, but you know, 
> sometimes I have a long function that doesn't make sense to split.
>
> Here is a good article about inline vars: 
> http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html
>
> What's not to like about for var I:=0 to Count-1 do.. ?
>
> Or var MyDict:=TDictionary<Integer,String>.Create;
>

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 
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.
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;

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190220/1c7edd3d/attachment.html>