Question ?!!!!

[Warfley]

In my opinion there is (at least in pascal) only one argument in favor of inline variable declaration, which is scoping.

When using scoped variables you can have different types for the same variable name, not access variables outside their scope (i.e. you know exactly where each variable belongs) and managed variables would only be initialized when the scope is entered (i.e. on an if, only if that branch is taken) and destroyed when the scope is left (which could lead to better performance and a fine grade of control over how and when memory is used e.g. by arrays).

That said all of these points are not really strong arguments because:
1. using same name for different types means you name is meaningless, this is more a symptom of bad naming
2. If you have to many scopes so you loose track of your variables, probably your function is to big and you should outsource some scopes to (nested) functions
3. If you need the performance of managed types, you can still call finalize and initialize by hand for memory areas, or use functions (which through inlining most certainly will not add overhead). And for the memory usage, one can always free managed types, e.g. Strings or Arrays by setting them to nil

So In a clean code base I don't see any reason why this would be required. Things like being able to use the same name for different types makes the code even worse in my opinion. The only thing where I can see real advantages imho is the for and for-in loops. While looping variables should be recognizable by their naming, I've already had this code:

Code: Pascal  [Select][+][-]

1. for i:=0 to len -1 do
2.   foo(i);
3.   bar(i);

Where I forgott the begin/end (because it was a oneliner at first and then I've added more lines), and in this cases a compiler error that I'm accessing the loop variable outside it's scope would be nice

[Thaddy]

That last part is python syntax... by indentation...

[Warfley]

That last part is python syntax... by indentation...

Yes, but my point was that I've already had the situation that I brainlessly added a line line to a for loop, but because it was previously a one liner, I had no begin-end and  therefore the next line was not part of the for loop.

I now try to use begin-end everywhere (except where it will only be one liners like raising errors or calling exit/break/continue), but in such a case a warning (or compilation error) by the compiler would have been nice. Or in general, if you use a loop variable after the loop

[PascalDragon]

So In a clean code base I don't see any reason why this would be required. Things like being able to use the same name for different types makes the code even worse in my opinion. The only thing where I can see real advantages imho is the for and for-in loops. While looping variables should be recognizable by their naming, I've already had this code:

Code: Pascal  [Select][+][-]

1. for i:=0 to len -1 do
2.   foo(i);
3.   bar(i);

Where I forgott the begin/end (because it was a oneliner at first and then I've added more lines), and in this cases a compiler error that I'm accessing the loop variable outside it's scope would be nice

Optimally the compiler would warn you that i in the call to bar is undefined. At least with -O3 in trunk (don't know if in 3.2.0 as well) it already does:

Code: Pascal  [Select][+][-]

1. program tforvar;
2.  
3. procedure Foo(aArg: LongInt);
4. begin
5.  
6. end;
7.  
8. procedure Test;
9. var
10.   i: LongInt;
11. begin
12.   for i := 0 to 20 do
13.     Foo(i);
14.   Foo(i);
15. end;
16.  
17. begin
18.   Test;
19. end.

Code: [Select]

PS E:\fpc\git> .\compiler\ppc386.exe -n -Furtl\units\i386-win32 -viwnh -FEtestoutput -O3 .\fpctests\tforvar.pp
Target OS: Win32 for i386
Compiling .\fpctests\tforvar.pp
tforvar.pp(3,15) Hint: Parameter "aArg" not used
tforvar.pp(14,8) Warning: Local variable "i" does not seem to be initialized
Linking testoutput\tforvar.exe
19 lines compiled, 0.0 sec, 29120 bytes code, 1316 bytes data
1 warning(s) issued
1 hint(s) issued
It's a work in progress however.

[440bx]

It's a work in progress however.

Nice that the compiler is keeping track of "no initialization" across "for" loops.

[Thaddy]

Really nice, given -Sew : treat warnings as errors (which the compiler demands from compiling itself!)

[Blade]

They are not really problems for the compiler side. But as I stated many times that I find it important that declaration and implementation are separated. Such constructs as I presented are cleaner though, because of inference and there is less wrong with that.
I'd rather see only inference for those kind of instructions than explicit declarations in an implementation part: that is NOT Pascal.
IF such things are implemented, try to keep the separation, is more or less my way of thinking.
Many C and C++ programmers agree, btw, - e.g. Linus Torvalds - inline declarations are evil. Perhaps apart from loop variables as intrinsic.
Not from a point of convenience, but from a point of maintainability and team work.
People tend to focus on convenience..., which is wrong for large code bases.

I agree with this, and such things as greater code readability and maintainability should not be taken lightly.  Looking at many of the attacks and criticisms of the Pascal language, a significant category of such is that Pascal is different from C-family languages.  It's amazing to see some from C/C++/C# get all hot and bothered simply by Pascal's "with", "begin", or "end". 

Taking a moment to declare variables and functions, or to think about their purpose and necessity can be asking too much.  Code fast and impatiently at the start, worry about the problems and ramifications later, sneak off into the night before the titanic sinks, pass the buck on to the next programmer to maintain a disaster, and/or flip off disappointed customers/users/companies.

If you read various forums on the web, the antagonism against non C-family languages and syntax appears to go back to the 1970s, and has been instilled into the culture.  Pascal is a particular focus point for it, which is partially why some such people have been gleefully claiming that somehow it's dead/wishing for its death (or hoping to remove non C-family alternatives) for over the past 20 years.  So I can only imagine what goes through the minds of C++ advocates at Embarcadero.  "Why not make Pascal just another flavor of C/C++?"

Additionally, Embarcadero is about IDE/compiler sales, not what is the best design or in the best interest of the Pascal language.  Whatever is a neat trick or fad can be on the table, not producing higher quality programmers nor good programming practices.  If they think creating havoc with "Frankenstein Pascal" might just slightly bump the sales needle by removing "with", turning "begin/end" to "{ }", and removing "declarations" and "implementation" all together then their management might give it a try.  Then if there is nothing left but C++ Builder, after having torpedoed and destroyed Delphi with incompetence, they then may give C# Builder another shot or for a quick buck introduce an unasked for Python Builder.

[lainz]

Just a quick question to don't read all the pages. What is the current state of this?

In mode Delphi should be supported or that is not important anymore?

[Bart]

AFAIK the fpc team is NOT going to implement this, regardless of language mode.

Bart

[marcov]

AFAIK the fpc team is NOT going to implement this, regardless of language mode.

Afaik it was more diplomatic and more along the lines of "not in the coming 5 years, never say never".

[Thaddy]

I got some private response regarding type inference for loops, though.
In general inline declarations are evil imho.

[MarkMLl]

AFAIK the fpc team is NOT going to implement this, regardless of language mode.

Afaik it was more diplomatic and more along the lines of "not in the coming 5 years, never say never".

Trying to be diplomatic, that's not really the impression that many if not most of the rest of us have of this long-term debate.

"You are not the first with such suggestions and you're also not the first we're shooting down, because there simply will not be any modifications added to the compiler that changes syntax/language fundamentals." -- https://forum.lazarus.freepascal.org/index.php/topic,53721.msg397816.html#msg397816

My own take on it is that a local variable declared in a "for" clause is less evil than the current situation where the index variable is still in scope but has an undefined value upon exit from the controlled statement.

The bottom line is that if we don't like it, we're at liberty to fork the compiler... which is a viable option for those of us using it for business purposes, who have little incentive to worry about putting code on Github etc. where it would be incompatible with the mainstream.

My own preference would be to migrate to an ALGOL-based language which is extensible in a controlled fashion, and if this had been designed with reasonable input from the C/C++ community it would almost certainly allow local declarations. However I don't relish losing the mature FPC/Lazarus libraries: to that extent the developers have the users over a barrel and I sincerely hope that they're never caught gloating over it.

MarkMLl

[marcov]

However I don't relish losing the mature FPC/Lazarus libraries: to that extent the developers have the users over a barrel and I sincerely hope that they're never caught gloating over it.

There is no barrel. It is a new feature. Just don't start using it on the Delphi side and you are fine. Most 3rd party libraries/components won't anyway because of compatibility with older Delphis.

And no, gloating is not a worth of it. Intense regret over wasted time discussing bullshit features is more like it.

[PascalDragon]

AFAIK the fpc team is NOT going to implement this, regardless of language mode.

Afaik it was more diplomatic and more along the lines of "not in the coming 5 years, never say never".

Trying to be diplomatic, that's not really the impression that many if not most of the rest of us have of this long-term debate.

For this specific feature that is indeed the impression I personally am shooting for. I won't implement it and I also won't integrate any patch that implements this feature, because I don't support this functionality. I can't and don't speak for the other core devs however.

[munair]

I got some private response regarding type inference for loops, though.
In general inline declarations are evil imho.

I couldn't agree more.

My own take on it is that a local variable declared in a "for" clause is less evil than the current situation where the index variable is still in scope but has an undefined value upon exit from the controlled statement.

Declaring variables in and implicitly limiting them to the "scope" of a for-loop or other control block as various languages support is bad language design. The only clean way to implement this is by allowing explicit scope-block definitions, but for some well-defined and established languages even that wouldn't be an option as it could easily mess up existing scope rules.

An undefined iterator after a loop should not be an issue as the very purpose of its existence is iteration only.

Don't blame a well thought-through language design for bad programming behaviour.