Inline var not working this time

[Marsil 4]

This code will not compile:

procedure TfrmMain.ListBox1Click(Sender: TObject);
begin
  if ListBox1.ItemIndex < 0 then
    Exit;

  var TestMethod : TMethod;
  TestMethod.Data := Self;
  TestMethod.Code := ListBox1.Items.Objects[ListBox1.ItemIndex];

  var TestProc : TTestProc;                 
  TestProc := TTestProc (TestMethod);
  TestProc;   // --> Compiler error: [dcc32 Error] UfrmMain.pas(422): E2014 Statement expected, but expression of type 'TTestProc' found
end;

 

But when moving the inline var TestProc to the var section the code compiles!

 

procedure TfrmMain.ListBox1Click(Sender: TObject);
var
  TestProc : TTestProc;
begin
  if ListBox1.ItemIndex < 0 then
    Exit;

  var TestMethod : TMethod;
  TestMethod.Data := Self;
  TestMethod.Code := ListBox1.Items.Objects[ListBox1.ItemIndex];

  TestProc := TTestProc (TestMethod);
  TestProc;
end;

 

and   TTestProc is defined as:

 

  TTestProc = procedure of object;

I'm not sure if this is a compiler bug or its by design or I am missing on something!

 

Edited May 25, 2022 by Marsil

[David Heffernan 2345]

Does it compile if you write TestProc() 

[Marsil 4]

6 minutes ago, David Heffernan said:

Does it compile if you write TestProc() 

 

Yeah it does!

Being a sole Delphi programmer I've never used to use empty brackets like some other languages. Never thought about it.

But, the question remains: Why inline var declaration not compiling as standard var declaration unless brackets used?

 

 

[David Heffernan 2345]

1 hour ago, Marsil said:

But, the question remains: Why inline var declaration not compiling as standard var declaration unless brackets used?

Clearly a bug. Is there a QP report already. If not submit one. 

 

This feature with Delphi where the function call parens can be omitted for parameterless functions was a terrible idea that should never have happened. 

[Marsil 4]

We wouldn't discover this potential bug with those parentheses lol 😀

As long as parentheses are optional everyone should be happy.

 

Also this bug wouldn't reveal itself if I used the brief and favorable way:

  var TestMethod : TMethod;
  TestMethod.Data := Self;
  TestMethod.Code := ListBox1.Items.Objects[ListBox1.ItemIndex];

  TTestProc (TestMethod);

But when testing I like to go in details, It helps to better understand the code and catch any potential bugs.

 

 

Edited May 26, 2022 by Marsil

[David Heffernan 2345]

43 minutes ago, Marsil said:

As long as parentheses are optional everyone should be happy.

I'm not happy.  Optional parens means that a symbol like MyFunc can mean either the procedure or the value returned by a call to the procedure.  And there are times when that ambiguity can't be resolved by the compiler.  Most commonly when MyFunc returns another procedural type.  So when you write SomeFunc := MyFunc are you assigning MyFunc or MyFunc() to SomeFunc?  It sucks that in Delphi there is this ambiguity.  The ambiguity would not exist if () were not optional.  Like they aren't in so many other better designed languages.

[PeterBelow 238]

19 hours ago, David Heffernan said:

I'm not happy.  Optional parens means that a symbol like MyFunc can mean either the procedure or the value returned by a call to the procedure.  And there are times when that ambiguity can't be resolved by the compiler.  Most commonly when MyFunc returns another procedural type.  So when you write SomeFunc := MyFunc are you assigning MyFunc or MyFunc() to SomeFunc?  It sucks that in Delphi there is this ambiguity.  The ambiguity would not exist if () were not optional.  Like they aren't in so many other better designed languages.

As far as I remember this "feature" comes from the original Wirth Pascal in Delphi's anchestry. Dropping it now would break heaps of legacy code, so is very unlikely to happen.