Question ?!!!!

[Joanna]

Variables declared all over the place is a sloppy mess. 

I’ve also noticed that the amount of enthusiasm for this idea seems to be inversely proportional to forum history, participation and most likely pascal usage.

I do have a suggestion which could sort of emulate delay in declaring variables. Why not make procedures inside of your procedure and declare local variables inside of those?

[Thaddy]

@440bx

About inline types:

They have always been allowed in Delphi.
Screenshot D7 on Windows 11. (also tested D5, which implies that D4 also supports it)

Note that even I did not know that, or used it, for that matter...
I knew for a long time that FreePascal supports it. (and use it)

Maybe your D2 also supports it 

[Thaddy]

Why not make procedures inside of your procedure and declare local variables inside of those?

That has already been mentioned, and also mentioned as one of the reasons that inline vars will not be implemented.

[440bx]

@440bx

About inline types:

They have always been allowed in Delphi.

That's not an inline type.

[Thaddy]

Then I do not understand the question and its purpose. The type is local a.k.a. inline.

[MarkMLl]

Since the forum has no facility to unsubscribe from a thread, and at the risk of being accused of knowing nothing about Pascal by Joanna, I'll volunteer my position on this.

Mandatory declaration of variables before use is non-negotiable, and there are good reasons to keep declarations grouped together.

There are two use cases where being able to declare a variable other than at the start of a function (or procedure, unit etc.) would be useful:

* In a for statement, to eliminate the "becomes undefined after use" problem.

* In a with statement, so that it is no longer necessary to "guess" the implied record.

In both cases the scope of the declaration is the single statement (including the begin-end delimited block possibility) that immediately follows, and assignment to the locally-declared variable is an error.

Some might argue that being able to declare variables with scope over the statement/block that immediately followed would be useful. However on reflection I feel that that cannot be defended /except/ in the case of inline functions since it would break the Pascal structure philosophy which is

Code: [Select]

<header>

<declarations>

<code>

i.e. there is always a recognisable syntactic element which indicates that declarations might follow. That element is currently FUNCTION (or PROCEDURE, UNIT etc.) but could potentially also include FOR and WITH without contravening the philosophy of the language.

MarkMLl

[Joanna]

When a variable has been declared it can’t really become undeclared.
Out of morbid curiosity, after an in-line variable is declared in delphi it is available until the end of procedure? Or just the end of code block?

[440bx]

When a variable has been declared it can’t really become undeclared.
Out of morbid curiosity, after an in-line variable is declared in delphi it is available until the end of procedure? Or just the end of code block?

Generally, a variable in Pascal is valid/visible in the scope in which it is defined and any "child" scopes, e.g, if a variable is defined in function A and function A contains function B then the variable will be visible/accessible in function B (as long as function B is defined after the variable.)

In normal Pascal the pair begin/end does _not_ define a scope but, they do when implementing inline variables (because some mechanism is needed to link these variables to a scope and the begin/end pair is the choice that requires the fewest changes to the language syntactic structure.)

In a Pascal compiler that supports inline variables and a variable is declared inside a begin/end pair, the variable is non-existent/undeclared after the "end".

This is just like variables declared at the top of a function/procedure, they are undeclared/non-existent outside the function/procedure in which they are declared.  function/procedures define the scope in which the variable exists, with inline variable it is the begin/end pair that determines the variable's existence.

HTH.
 

[MarkMLl]

When a variable has been declared it can’t really become undeclared.

Hmm. I'm not sure if this really qualifies as "undeclaring", but arguably, Rust departs from the ALGOL/Pascal/C model by having the compiler mark a variable inaccessible after it's been passed to a function etc.

There's also, in the general case, the situation where a variable is "captured" by a closure, resulting in its remaining accessible even when the original control flow has exited the scope relevant to its declaration (this obviously implies that the variable has to be allocated on the heap, even if that would not normally be indicated by its type).

(Please could somebody correct me if my understanding above is wrong).

I'm not really happy with the above cases, since IMO there's far more to be gained by teaching (and adhering to) a robustly-scoped and strongly-typed language such as Pascal or its close relatives than there is by inventing yet more "computer science crap".

But equally, I'm not happy with the situation which has been discussed ad-nauseam over the last week or so where a variable possibly /should/ be undeclared since its content can no longer be relied on if it has been a for loop's control variable.

MarkMLl

[alpine]

When a variable has been declared it can’t really become undeclared.
Out of morbid curiosity, after an in-line variable is declared in delphi it is available until the end of procedure? Or just the end of code block?

You could just read this: https://blogs.embarcadero.com/introducing-inline-variables-in-the-delphi-language/. Out of morbid curiosity.
And it's not so simple as it sounds, sometimes there is no begin/end as with:

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

1. for var I: Integer := 1 to 10 do
2.   writeln(I);

It comes out that every statement can be a 'block', not just the compound one (begin/end). Not to mention the possible complications with managed variables, exception blocks, and stack frame management. 
Last but not the least comes the type inference. I'm not thrilled and I don't think it's an advantage, even if it is presented as such. Rather it is a veer towards scripting languages

[Joanna]

When a variable is declared inside a program or procedure it happens before any begin. But these things inline variables are completely inconsistent with pascal language. I don’t know what the implications are with declaring a variable after execution has started.
Yes it reminds me of a scripting language to where variables can be declared by being used. It really makes the code confusing and hard to read.

[MarkMLl]

When a variable is declared inside a program or procedure it happens before any begin. But these things inline variables are completely inconsistent with pascal language. I don’t know what the implications are with declaring a variable after execution has started.

The stack frame is set up when a function (etc.) is entered, not when the program run starts. Naively, you could consider every begin to mark the point at which a new stack frame is set up and every end to mark the point at which it is discarded (that's what the BP register was originally for). However in practical terms things are complicated a lot by try-finally and try-except blocks, noting in particular that the presence of strings (other than shortstrings) creates a hidden try-finally.

MarkMLl

[Joanna]

Thanks for explaining

[dbannon]

Personally (if I had any influence) I'd really like to see the inline var available to a "for loop". There is, IMHO, a real pressing need to fix the anomalies associated with the for loop. (see other thread).

I can imagine situations where it would be useful to use an in-line var in general code, declared immediately after a 'begin'.  But I don't see the same pressing need and accept the baggage it would bring along would be unacceptable. Delphi comparability maybe the only standout reason ?

I would hate the idea of declaring a var anywhere in the code !

Its very easy to blur the various issues here, the other, very long thread requested a WARNING when a "for loop var" was reused without initialization, thats far more important ! Even a false positive would be better that the false neg we get now.

Davo

[Joanna]

Delphi is probably headed towards destruction if it’s trying to imitate scripting languages. The undefined variable problem seems trivial to fix and didn’t seem undefined at all when I tested it.