Hello! Anything new?

[LeP]

.........  you use C and/or C++ regularly and, if that is the case, you probably use C/C++ ability to declare variables just about anywhere.  The important point resulting from that, is that you must have noticed that there are many cases where that ability actually results in simpler and easier to understand code, which is one of Pascal's original design purposes.

Personally, I've ported a fair amount of C code to Pascal and I've noticed that being able to have separate blocks of local variables in a function makes the function easier to understand.  In Pascal porting that function requires declaring all the block-scoped variables at the top of the function which makes them global to the function, which is inappropriate because they really are not global to the function, they only apply to a few statements.  Being at the top effectively turns them into annoying noise that only applies to a few statements that are normally in their own scope but, in Pascal must be at the global function scope.

My point is: inline variables are fully consistent with Pascal's design purpose which is to facilitate the production of code that is easy to understand and maintain.  It's just a feature that has been missing in the language, one which enables _locality_ which is extremely important in good programming.    Its presence in Pascal would make the language easier to use and the code easier to understand.

While I use inline variables often in Delphi, I have to say that this doesn't always improve code readability.
It's an opportunity that should be used wisely.
And the comparison with C/C++ is apt: in many C/C++ source files, you see scattered variables defined almost randomly, and reading the entire set isn't always easy.
This doesn't happen in Pascal, and the ability to use inline variables could lead to this "drift."
As always, it's the programmer who decides whether to write good code or not, it's not the novelty itself.

[Thaddy]

In my C/C++ work, inline variables were also forbidden in the development guidelines. (As per the guidelines for the Linux kernel I believe, may I add)

[JuhaManninen]

I also enjoy having a separate variable section when I study code made by others, or even made by myself some years ago.

[marcov]

In my C work, I sometimes use them in case node blocks   In many cases I should have converted those to static inline functions completely anyway.

But I'm mentally still in transition, since I only moved to a compiler that supports such functionality a few years ago.

But while a quick and dirty convenience for myself, I do struggle to read other people's code that uses inline variables, and as said it is usually a smell that procedures are too long anyway.

[440bx]

While I use inline variables often in Delphi, I have to say that this doesn't always improve code readability.

There is no doubt in my mind that inline variables can be misused (particularly in Delphi), resulting in code that is not as easy to understand as could be but, I have not seen that often.

It's an opportunity that should be used wisely.

Agree.  Just like every other feature the language offers, not just that one.

And the comparison with C/C++ is apt: in many C/C++ source files, you see scattered variables defined almost randomly, and reading the entire set isn't always easy.

I _very rarely_ see inline variables abused/misused in C/C++ code, very much unlike the preprocessor that is very often misused/abused... I mention that because misusing inline variables isn't easy (unlike abusing/misusing the preprocessor.)  I believe the misuse of inline variables would be obvious even to a beginner, which is why misuse/abuse of inline variables is very seldom seen (at least in C/C++, I don't really know in Delphi.)

This doesn't happen in Pascal, and the ability to use inline variables could lead to this "drift."

What happens in Pascal is that there are _often_ variables at the global function level that should NOT be at that level, instead they should be _local_.   A very commonly seen example of that are index variables (such as "i"), those indexes should NOT be function global, they should be local to the loop (for _more_ than one reason.) The inability to define those indexes locally is a major deficiency in the Pascal language.

As always, it's the programmer who decides whether to write good code or not, it's not the novelty itself.

That's true but, there are features, in the case of inline variables a structural feature, that _enables_ the programmer to write better, cleaner, simpler code and, that structural feature is missing in Pascal (and poorly implemented in C/C++, of course, that's no surprise but, at least they have something that does the job, even if not as well as could be.)

(As per the guidelines for the Linux kernel, may I add)

And how do they justify that ?   Is that some commandment ordained by a higher power appearing next to a burning hard drive ? or is there a _logical_ solid foundation to justify it ? 

Just in case, are you saying that _nowhere_ the Linux kernel uses something like "for (int i = 1; i < SomeValue; i++) { some code here }" because the declaration of "i" in the "for" itself is an inline variable declaration.  I find it very difficult to believe that's not used in the Linux kernel or any other Linux-related C/C++ program that does something useful.  From what I've seen that type of inline variable in C is probably more common than a Papiermark unit was in the early 1920s.

Dogma is worthless and there is way too much dogma in programming. 

[Thaddy]

This seems to have changed in the past. Simple ones are allowed. More complex ones discouraged.
It used to be the case, though, also because back in the days C compilers did not even allow it.

[jamie]

There was talk about enhancing the WITH operator to open a branch of local variables, whatever happened to that?

Jamie

[marcov]

There was talk about enhancing the WITH operator to open a branch of local variables, whatever happened to that?

Afaik there was only talk. I had some sympathy for it in principle, but that is more from the viewpoint of what I would do in a new language.

Too many seldomly used features make a language baroque and unmaintainable.

[simone]

My opinion on inline variables is uncertain. Therefore, my question should not be interpreted as a provocation, but rather as an attempt to understand the current goals of this project.

If inline variables are conceptually rejected by core developer, given that Delphi implements them, does this mean that compatibility with Delphi is no longer the project's goal? To reconcile fidelity to Pascal's tradition with compatibility with Delphi, could they be implemented only in {$Mode Delphi}?

[PascalDragon]

(As per the guidelines for the Linux kernel, may I add)

And how do they justify that ?   Is that some commandment ordained by a higher power appearing next to a burning hard drive ? or is there a _logical_ solid foundation to justify it ?

Originally the C compilers used for Linux did in fact not allow the declaration of variables after the first statement of a block that isn't a variable declaration. So back then it was in fact enforced by the compiler itself. Nowadays the reasoning is the same as Pascal had ever since: it makes it easier to find what variables are declared.

Just in case, are you saying that _nowhere_ the Linux kernel uses something like "for (int i = 1; i < SomeValue; i++) { some code here }" because the declaration of "i" in the "for" itself is an inline variable declaration.  I find it very difficult to believe that's not used in the Linux kernel or any other Linux-related C/C++ program that does something useful.  From what I've seen that type of inline variable in C is probably more common than a Papiermark unit was in the early 1920s.

You can in fact find both styles inside the kernel, namely with the loop variable declared separately and with the loop variable being declared as part of the loop header. I don't know right now whether the original compilers used for Linux allowed for the loop variable declaration inside the loop header or not. And at least in the kernel's coding style there's no mention regarding the declaration of loop variables (except that they should be named using simple names).

If inline variables are conceptually rejected by core developer, given that Delphi implements them, does this mean that compatibility with Delphi is no longer the project's goal? To reconcile fidelity to Pascal's tradition with compatibility with Delphi, could they be implemented only in {$Mode Delphi}?

Adding them for one mode nevertheless means that they need to be maintained in general. I for one have no desire to maintain that nonsense.

[simone]

These seem definitive words to me. As in all open source projects, whoever writes the code decides the direction. 

Now I'm perfectly aware that FPC/Lazaurs and Delphi are each going their own way.

[440bx]

If inline variables are conceptually rejected by core developer, given that Delphi implements them, does this mean that compatibility with Delphi is no longer the project's goal?

I've wondered that too.

To reconcile fidelity to Pascal's tradition with compatibility with Delphi, could they be implemented only in {$Mode Delphi}?

I'm not an FPC developer but, IMO, it makes little sense to have such a major feature be available in Delphi mode only.  I say that because I feel the ObjFPC mode is the "native" FPC mode, therefore omitting such a significant feature from that mode would pretty much amount to splitting the compiler's development.

Just my $0.02...

Originally the C compilers used for Linux did in fact not allow the declaration of variables after the first statement of a block that isn't a variable declaration. So back then it was in fact enforced by the compiler itself.

IIRC, that was circa mid-90s.  Lots of water (i.e, new features) have flowed under the bridge since.

Nowadays the reasoning is the same as Pascal had ever since: it makes it easier to find what variables are declared.

Actually, I believe it is the opposite of that.  Inline variables make it clear which variables are genuinely global to the function because they are not mixed with "supporting" variables that are used only by a very small number of statements in the function, e.g, loop indexes.  That said, I don't like the way the feature is implemented in Delphi, it's very poor but, I guess, it's better than nothing.

You can in fact find both styles inside the kernel, namely with the loop variable declared separately and with the loop variable being declared as part of the loop header.

Which makes sense, parts of the code reflect the fact that it was written when the compiler did not have the feature while newer code is rather likely to use the feature since it makes for cleaner and clearer code.

[simone]

Actually, I believe it is the opposite of that.  Inline variables make it clear which variables are genuinely global to the function because they are not mixed with "supporting" variables that are used only by a very small number of statements in the function, e.g, loop indexes.  That said, I don't like the way the feature is implemented in Delphi, it's very poor but, I guess, it's better than nothing.

I completely agree.

This is why Delphi, C++, C99, Java, C#, Go, Javascript, Python, Ruby, PHP, Rust, Swift, etc. have this feature.

[Fibonacci]

Upstream said no. FPC Unleashed says yes - inline variables, statement expressions, array equality, no-RTTI mode, and more.

Demo below (screenshot attached):

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

1. program app;
2.  
3. procedure main;
4. begin
5.   // *** INLINE VARIABLES ***
6.  
7.   var s := 'hi there';
8.   var i := 42;
9.   // or
10.   var s2: string := 'hello';
11.   var i2: integer := 66;
12.  
13.   writeln(s, ' | ', i);
14.   writeln(s2, ' | ', i2);
15.  
16.   // *** INLINE VAR IN FOR LOOP ***
17.  
18.   for var j := 1 to 5 do writeln('j = ', j);
19.  
20.   // *** STATEMENT EXPRESSIONS + INLINE VARIABLES ***
21.  
22.   randomize;
23.   var d := if random(20) > 10 then 'less than 10' else 'more than 10';
24.   writeln('d = ', d);
25.  
26.   // *** FOR-IN + INLINE VAR ***
27.  
28.   var a := ['foo', 'bar', 'baz'];
29.   for var z in a do writeln('a[] = ', z);
30.  
31.   readln;
32. end;
33.  
34. begin
35.   main;
36. end.
37.  

This is WIP and experimental. A hobby project - just like FPC. Compiles and runs, see for yourself.


Want to try it?

The project is here: https://github.com/fpc-unleashed/freepascal

Install via fpcupdeluxe.

Open fpcup.ini and add to the top of [ALIASfpcURL]:

Code: INI  [Select][+][-]

1. unleashed.git=https://github.com/fpc-unleashed/freepascal.git
2.  

For Lazarus Unleashed (with autocomplete support for some of the new features), add to the top of [ALIASlazURL]:

Code: INI  [Select][+][-]

1. unleashed.git=https://github.com/fpc-unleashed/lazarus.git
2.  

Optionally enable docked IDE in Setup+, then click Install/update FPC+Lazarus.

[440bx]

@Fibonacci,

I believe that the emergence of a forked/new version of Pascal should have its own thread.

That would make it crystal clear that the posts are specific to the new version and not the existing FPC version.

I suggest you create a new thread where the initial post is the one you posted above to introduce the "FPC Unleashed" version.  (For some people it may be the last post on the previous page.)