A syntactic change: blocks as statements

[Peter H]

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

1.   procedure ()
2.   var a: TBar;
3.   begin
4.   end(); // invoke here
5.  

I know anonymous functions are really useful, but this syntax is so ugly and cluttery. I still believe that this was an April Fools joke by someone at Embarcadero, but he forgot to tell anyone so it was integrated into the language.

At least current Delphi does not support this syntax with appended brackets.
This is a unique Free Pascal feature, SCNR.
Edit: C++ supports it too, but Delphi does not.

It can be written like this in Delphi:

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

1.   const someproc = procedure ()
2.               var a: TBar;
3.           begin
4.           end;
5.   someproc();  // invoke here
6.  

Inline variables and inline constants and type inference make this possible.
This is more versatile.
In Free Pascal it is not possible to declare an anonymous procedure as a constant.

The purpose of this construct is not immediately clear, at least it was not clear to me, until I learned it:

This construct can be used in functional programming to capture outer variables into a local context. 
(Local visibility, but global lifetime, until the context is not referenced anymore and released)

[Warfley]

But why is this only possible with inline definitions?

There are two types of const, there are untyped and typed consts. Untyped consts are compile time only constructs, basically macros. They cannot have runtime implications. E.g.

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

1. const
2.   C = 42;
3. begin
4.   WriteLn(C);
5.   WriteLn(C);
6. end;
7.  
8. // Is runtime translated to
9. begin
10.   WriteLn(42);
11.   WriteLn(42);
12. end;

The constant does not exist after compilation anymore and can therefore not exerpt any runtime behavior. If what youve wrote is an untyped  constant, the following would happen:

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

1. const someproc = procedure ()
2.               var a: TBar;
3.           begin
4.           end;
5.  
6. someproc();
7. someproc();
8.  
9. // Would be translated to
10. procedure ()
11.   var a: TBar;
12. begin
13. end();
14.  
15. procedure ()
16.   var a: TBar;
17. begin
18. end();

Note that because at runtime those are two completely different instantiations, there is no connection between the two "A" variables here, so no state is captured in between.

The alternative are typed constants, which is a misnomer, as in reality they are just static (global) lifetime local scope variables, and then what you posted is in reality just them in combination with type inference, so

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

1. const someproc = procedure ()
2.   var a: TBar;
3. begin
4. end;
5.  
6. // is just
7. const someproc: reference to procedure = procedure()
8.   var a: TBar;
9. begin
10. end;

But then there is absolutely no difference from doing that:

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

1. const
2.   someproc: reference to procedure = nil;
3. begin
4.   if not Assigned(someproc) then
5.     someproc = procedure()
6.     var
7.       a: TBar;
8.     begin
9.     end;
10. end;

This construct can be used in functional programming to capture outer variables into a local context.
(Local visibility, but global lifetime, until the context is not referenced anymore and released)

Thats not from functional programming but from prototypical programming, which is often clustered together, due to it's reliance on runtime function manipulation, but there is a big difference, functional programming is stateless ("pure") and there is no concept of variables or variable lifetime. A real functional program is so pure that it doesn't even require your computer to be powered to run.

But thats just on a side note. More importantly, this is used in such languages to emulate the behavior of static lifetime variables (such as writable consts in pascal), which those languages are usually lacking. So you are currently introducing a hack to emulate a hack that tries to emulate a feature we already have.
Just skip the middle man:

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

1. const
2.   GlobalLifetimeA: TBar = nil;
3. var
4.   a: TBar;
5. begin
6.   if not Assigned(GlobalLifetimeA) then
7.     GlobalLifetimeA := a;
8. end;

What I think pascal is truely missing is truely constant typed consts that can be assigned later, something like this:

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

1. const
2.   MyConst: Integer; // Note no assignment here
3. begin
4.   WriteLn(MyConst); // Not assigned yet, compiler error
5.   MyConst := 42; // first assignment, will be unchangable from now
6.   WriteLn(MyConst); // Works because already defined
7.   MyConst := 32; // Compiler error: trying to reassign const
8. end;

Maybe even with a special keyword to make this more clear:

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

1. const
2.   MyConst: Integer; unassigned; // Note no assignment here
3. begin
4.   assign MyConst := 42;
5.   MyConst := 32; // error
6.   assign MyConst := 32; // error
7. end;

But a real notion of consts is what is defenitely lacking

[PascalDragon]

You are right it is undocumented, which makes it actually even worse for such cases (if it's documented it's at least predictable), but I remember from my own tests a few years ago that FPC would call it at the end of the function. At least when used as such:

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

1. with FileOpen do // Returning a Managed Record Filestream
2.   WriteLn('Hello File');

It's not documented, so don't rely on it. The behavior might be changed to improve optimization. Delphi recently changed that behavior as well to be more like FPC's behaviour because it allows for better optimizations.

Now fpc needs it too for Delphi compatibility

Delphi compatibility is more important than syntax penchants

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.

[kupferstecher]

What I think pascal is truely missing is truely constant typed consts that can be assigned later, something like this:
[...]
Maybe even with a special keyword to make this more clear:

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

1. const
2.   MyConst: Integer; unassigned; // Note no assignment here
3. begin
4.   assign MyConst := 42;
5.   MyConst := 32; // error
6.   assign MyConst := 32; // error
7. end;

But a real notion of consts is what is defenitely lacking

I think its really not a good idea to have runtime stuff in consts. Because one couldn't use this const to define the value of an other const, also it uses memory even if it isn't used (But could be optimized away).

So the later-assigned-const should rather be a special variable. E.g.:

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

1. var
2.   MyConst: Integer; const; // can only be assigned once
3. begin
4.   Assign MyConst := 42;
5.   MyConst := 32; // Error: Constant variables can not be assigned in a statement, use 'assign' instead
6.   Assign MyConst := 32; //Error: Dublicate initialization of constant variable
7. end;

[hypothetical code]

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 [...] are against this feature.

Thats good to hear!

[marcov]

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.

[wp]

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.

Great! I wonder whether other programming languages are bombarded in the same way as Pascal to add foreign features which partly even contradict its basic concept.

[VisualLab]

So the later-assigned-const should rather be a special variable. E.g.:

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

1. var
2.   MyConst: Integer; const; // can only be assigned once
3. begin
4.   Assign MyConst := 42;
5.   MyConst := 32; // Error: Constant variables can not be assigned in a statement, use 'assign' instead
6.   Assign MyConst := 32; //Error: Dublicate initialization of constant variable
7. end;

[hypothetical code]

If read-only variables are to be declared as in the code above, then I'm all for this solution. You can still see that it's a variable, but you only need to read it.

[marcov]

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.

Great! I wonder whether other programming languages are bombarded in the same way as Pascal to add foreign features which partly even contradict its basic concept.

Languages like C,C++,Java and C# are managed by companies or committees that act as stewards. Probably they have several levels of filtering to filter out nonsense proposals, but we never see them

The fact that we allow nearly any feature request to linger indefinitely in the bugtracker probably also plays a role.

But yes, in general it is way too much about language features, and not other parts of the project.

The one assignment const proposal of Warfley reminds me a bit of a comment on a discussion about micromanaging visibility of identifiers, that eventually identifiers will need ACLs :-)

IMHO strict private is already over the top.

[VisualLab]

IMHO strict private is already over the top.

You mean the class scope specifiers introduced in Delphi some time ago: strict private and strict protected? If that's what you're talking about, then yes, it's redundant (and therefore unnecessary).

[Thaddy]

Marcov's comment is a bit funny, since what the tp/Delphi designers were trying to achieve at that moment in time with private and protected, was actually meant to be strict private and strict protected.
The fact that some side effects in their unit layout did not fit the terms was basically a design flaw that later was corrected by introducing the strict modifier.
Tying code to a class and nothing but the class or heirs is a very good thing.
Allowing code in the same unit over different classes or variables is a bad thing and an unwanted side effect.
(for that matter, blame it on "implementation detail". FPC devels are rather good at that  )

[marcov]

Marcov's comment is a bit funny, since what the tp/Delphi designers were trying to achieve at that moment in time with private and protected, was actually meant to be strict private and strict protected.

True.

The fact that some side effects in their unit layout did not fit the terms was basically a design flaw that later was corrected by introducing the strict modifier.

And two things to do nearly the same thing because of some stylistic nitpicking is exactly what is over the top.  So by fixing one problem, you created another that is just as bad IMHO.

[Curt Carpenter]

Does this item from Marco Cantu's Object Pascal Handbook (Berlin) reflect the current state of inline variables in Delphi, or am I confusing two different issues?

Differently from C and other curly-brace languages, in Object Pascal you cannot mix variable
declarations with programming statements, but you need to group them in specific sections (like at
the beginning of a method). Since this is not always handy, the IDE code editor let's you actually
type the var keyword followed by the actual declaration within your method or function code, but
it will immediately move it up to the correct position. This is one of the predefined Live Templates,
a very nice coding helper in the IDE that you can customize and extend.

[marcov]

Does this item from Marco Cantu's Object Pascal Handbook (Berlin) reflect the current state of inline variables in Delphi, or am I confusing two different issues?

Yes, you are confusing things. That is the state in Lazarus currently, but Delphi changed after Delphi Berlin