Question ?!!!!

[ydd]

5 Reasons to Use Inline Variables in Delphi
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/

[marcov]

5 Reasons to Use Inline Variables in Delphi
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/

1. opinion, not fact. Clear weasel clause "for many people" to make opinion seem fact.   Worse, it seems to be deliberately one-sided, not mentioning the contra argument that in complex code the downside is having to search the definition inside many code lines instead of a clear position (the VAR block). Though at least that can be mitigated with an IDE (jump to declaration) like functionality. But that goes for both cases.
2. opinion, not fact. and again the weasel words "many people". FPC can turn warnings into errors.
3. Not always less typing. E.g. a few loop vars will have multiple extra VAR's, while in the var block the "VAR" is shared.  But this is still mostly stands.
4. Funny, back then they had exactly the opposite reasoning (mass initializing/finalizing at the start/end is cheaper than multiple times one, options to zero multiple local variables with one rep stosb etc).  Also, in cases where the compiler can determine if a block is taken or not it can chose the  most optimal way, so even if it was a netto plus (which I doubt), this only goes for the most a naive implementation.
5. This is the only one that rings somewhat true from my own experience.
(6, not in article) playing into familiarity feelings from other languages in a "100000 lemmings can't be wrong" sentiment.

So 1 and 4 are simply extreme one sided spotlight on this feature just to make a seem worthy.  The option 2 is extreme corner case and mixes in an opinion about warnings and weaselling "many people" again. All three seem to be carefully crafted to not try to find the other side of the story.

5 is true, and not purely hypothetical. Of course a simple IDE macro would solve it (even easier in lazarus that only has tp append {%H-} or {%w-}. 

The true reason to add it is probably language-feature-by-mob-rule fuelled by perceived benefits (3 and 6).  But not with language design as the article seem to imply.

[jamie]

Inline VAR's only good for the FOR LOOP control where the variable is to be secluded to the loop only and there for will not be present to code outside of that loop.

 As for the use of it anywhere else, NO, Inline variables are not a good idea.

[MarkMLl]

Inline VAR's only good for the FOR LOOP control where the variable is to be secluded to the loop only and there for will not be present to code outside of that loop.

 As for the use of it anywhere else, NO, Inline variables are not a good idea.

I think this is another valid case:

Py_BEGIN_ALLOW_THREADS

    This macro expands to { PyThreadState *_save; _save = PyEval_SaveThread();. Note that it contains an opening brace; it must be matched with a following Py_END_ALLOW_THREADS macro. See above for further discussion of this macro. It is a no-op when thread support is disabled at compile time.

Py_END_ALLOW_THREADS

    This macro expands to PyEval_RestoreThread(_save); }. Note that it contains a closing brace; it must be matched with an earlier Py_BEGIN_ALLOW_THREADS macro. See above for further discussion of this macro. It is a no-op when thread support is disabled at compile time.

However, both of these cases have declaration of a variable closely associated with entering a block, and the scope of the variable is (or at least should be) restricted to the code inside that block.

I would go so far as to say that having a locally-declared variable is superior for a FOR loop and is closer to Wirth's original intent, since it avoids the pernicious case where the variable is always (in Pascal as originally designed) undefined on exit from the loop.

Hence we either have the Pascal-style

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

1. var i: integer;
2. for i := 1 to n begin
3. ...
4.  

potentially shortened to something like

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

1. for i: integer= 1 to n begin
2. ...
3.  

or the ALGOL/C/Python style

Code: C  [Select][+][-]

1. {
2.   PyThreadState *_save;
3. ...
4.  

They are both valid cases, with the minor syntactic variation of whether the declaration is immediately before or immediately after the start of the block.

MarkMLl

[alpine]

5 Reasons to Use Inline Variables in Delphi
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/

To me, inline variables cater to programmers laziness. All other "benefits" can be achieved by a feature present into Pascal from the day one (except the 5-th):

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

1. procedure Outer;
2.   procedure Inner;
3.   var I: Integer;
4.   begin
5.     for I := 0 to N do
6.       ...
7.   end;
8. begin
9.   Inner;
10. end;

i.e. the nested subroutines.

They have their scope, promote organization, care for variables creation/destruction and so on.

[ASerge]

To me, inline variables cater to programmers laziness. All other "benefits" can be achieved by a feature present into Pascal from the day one (except the 5-th):
i.e. the nested subroutines.
They have their scope, promote organization, care for variables creation/destruction and so on.

+1.
A block of code is also automatically documented.
And if someone cares about speed, then you can mark the whole procedure as inline.

[Raid]

I've left Pascal for a long time (years) and have now recently come back. I've used C#, and I've enjoyed the choices made in the language coming from the inventor of Pascal (Anders Hejlsberg). I came back to witness Delphi employing some of those features, and now I'm wondering in the spirit of Anders, if he allows and invents inline variables and even type inferred variables, why won't the Free Pascal team implement such? It was one of those, oh my, this would actually be pretty decent.

What stops the Free Pascal Team from implementing it behind the Delphi Compatibility Mode? Whoever wants it can have it on (or a modeswitch)? Who are the core developers? Still Florian? Who makes the final say, is there a board of people? Delphi compatibility would be nice, because the whole point of Delphi compatibility is to bring in a Delphi unit and allow it to compile with {$MODE DELPHI}. If this is not the case anymore, should the Free Pascal team just remove Delphi compatibility entirely?

One of the things that would attract more developers is modern language constructs. The compiler is made for everyone is it not? If the majority would like a feature and it's already in Delphi, why not add it? (I could see the pushback if it were a new feature that Delphi doesn't even have)

[Handoko]

What stops the Free Pascal Team from implementing it behind the Delphi Compatibility Mode? Whoever wants it can have it on (or a modeswitch)? Who are the core developers? Still Florian? Who makes the final say, is there a board of people? Delphi compatibility would be nice, because the whole point of Delphi compatibility is to bring in a Delphi unit and allow it to compile with {$MODE DELPHI}. If this is not the case anymore, should the Free Pascal team just remove Delphi compatibility entirely?

Manpower. I believe if someone adds a new feature by writing it themselves, if that is useful usually it won't be rejected. But if it is a suggestion and waiting others to write it, it needs to go a long process convincing others. Usefulness can be objective subjective. For example Anchor Docking and black themes, some will find them very useful but I personally don't use them. Because someone already write them, I would say cool but I don't need them. Because of having limited manpower, maintaining compatibility with Delphi is important. Also many Free Pascal users also use Delphi.

I am not a member of the core developers. This is just my 2 cents.

[TRon]

What stops the Free Pascal Team from implementing it behind the Delphi Compatibility Mode? Whoever wants it can have it on (or a modeswitch)? Who are the core developers? Still Florian? Who makes the final say, is there a board of people? Delphi compatibility would be nice, because the whole point of Delphi compatibility is to bring in a Delphi unit and allow it to compile with {$MODE DELPHI}. If this is not the case anymore, should the Free Pascal team just remove Delphi compatibility entirely?

Your answer:

With the introduction of inline variables to Delphi we have decided that this might not necessarily be the case considering many of the core devs (especially those that would be able to implement this) are against this feature.

IIRC everybody was nearly universally against it, but it was acknowledged that if it gets too prevalent we might have to change. 

The fact that more and more delphi users are on subscription, and thus the latest version, makes new features migrate through codebases much faster. It is hard to predict how that will work out longer term. In the past the mix in versions was a break on new features use by e.g. open source projects and component vendors.

But to avoid constant discussion and pressure about when, it was decided to park it for at least 5 years and to discourage delphi users of using this feature if they want to be compatible within that period.

And even if it is implemented in trunk at some point, it being in release versions is probably even further away, given current release circles.

But please do read the whole thread.

edit: see also issues 34486 and 34660

[dbannon]

Like Handoko, I am not a core developer (and thats something we should all be grateful for). 

I would like to offer a slightly different answer than Handoko. It may not be applicable here and I offer it as a observation of a pretty normal situation in any open source project.

In any Open Source Software project there are various phases, in the very early stage, the core developers are excited by what they are doing, enthusiastically welcoming new suggestions and users. ("Yeah, thats a cool idea, we can add that.."). Over time, as the project matures, the user base becomes greater and the excitement wears off just a little. More carefully vetted proposals, greater time between releases etc.

Thats neither wrong nor surprising. Development still proceeds, great things happen but stability and time management become more important than trying to satisfy everyone. The developers, quite naturally, then tend to focus more selectively on things that interest them personally, why should they do otherwise ?

This is not necessarily a bad thing, its a mark of maturity of the project, its probably working well and no one wants to risk that hard fought for stability without very good cause.

Is this the case here ?  I suggest, in the most gentle way possible, FPC is a bit further along that time line than, say Lazarus (I suspect Handoko's answer was back grounded by Lazarus rather than FPC). I am aware, in my own microcosm, I've moved my project along that time line a bit too.

Call this nonsense, or say its not applicable here, I will not argue with you.

And note TRon's answer, big difference between FPC and Delphi's model. Delphi needs to make changes to keep those subscriptions coming in, FPC just needs to do a good job.

Davo

[Thaddy]

Although I have always been a proponent of Pascal's strict separation of declaration and implementation, scoped - not inlined - variables may be a good thing provided they are strictly limited to loop counters. Delphi's implementation is a bit on the liberal side, a bit too liberal. Which makes them indeed inlined and not scoped. But indeed, the existing local functions and procedures go a long way in mitigating any advantage of scoped variables.

[Martin_fr]

The technical part has been answered lots of time. And links have been given. And nothing relevant has changed.

Who are the core developers? Still Florian? Who makes the final say, is there a board of people?

There is a page on the wiki, and you can look at who does the commits to git.

As for the organization within the Team, I can not speak for it. I am from the other team (Lazarus).

As for the Lazarus team (and I suspect similar by the FPC team), usually thinks are discussed between team members.
- One reason for that is, that whatever is implemented, the implementation must be maintained in future. And that will be the task of said team.
- Another thing is the difference in interest between Delphi and Fpc. Delphi does not carter to a Pascal community, nor care about the Language. They want to sell a tool to as many people as possible. Fpc has it on their flag to promote Pascal. And for that is has to be Pascal.

[PascalDragon]

I believe if someone adds a new feature by writing it themselves, if that is useful usually it won't be rejected.

Even if someone spends the time to implement something, it is entirely possible that we'll reject it, because we don't consider it in the spirit of Pascal.

Inline variables is one such thing for me. I won't implement it and I also won't merge it should someone implement it.

[simone]

In light of this peremptory statement (with which I agree quite a bit, but not 100%), I reiterate what I said in the recent past (getting contrary reactions): it seems clear that Delphi and FreePascal/Lazarus are following two different paths. Compatibility with Delphi, for which FPC/Lazarus were born, is no longer the main goal. Nothing dramatic, it is enough to know it, so that everyone can make the consequent choices.

Certainly the rigid separation between variable declarations and statements is an essential part of the spirit of Pascal. I wonder how much features such as classes, generics or anonymous functions are faithful to tradition. I think not very much and nevertheless they have been implemented (and I am sincerely grateful to the core developers for this).

[440bx]

The Delphi inline variable feature is basically a copy of the same thing in C.  Unsurprisingly, as in C, it is extremely poorly thought out.

It would be much cleaner and easier to maintain if blocks (similar to inline functions/procedures) could be declared that required the variables and constants to be declared at the top of the block (just as they are in normal functions/procedures), this would also allow for declaring local types (apparently while Delphi also allows inline constants, it doesn't seem to allow local types, if it does, that's not documented.)  That's a problem because if you want an inline variable of a type that hasn't been defined yet, the type must be defined at the top instead of inline as is the variable.

Maybe someone who has the latest Delphi can try defining an inline local type.  It would be nice to know if local types are allowed.

FPC sort of implements something like that using inline functions/procedure but, it's far from what it should be because the inline function/procedure has its own stack frame instead of using the stack frame of the function/procedure that encloses it.

IIRC, Ada implements these blocks/scopes correctly.