Initialize local variables at declaration

[PeterPanettone 158]

While this is possible:

This is currently not possible:

 

However, this would be a big time-saver and would make the code more compact and easier to read.

 

What do you people think?

[Stefan Glienke 2019]

This was implemented 10.3 via inline variables. It however is not possible to declare the variable in the old way plus initialize it - you have to declare it inline:

procedure DoSomething;
begin
  var MyVar: Integer = 23;
  //
end;

You can even omit the type there and it will automatically be Integer:

procedure DoSomething;
begin
  var MyVar = 23;
  //
end;

See http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

Edited April 1, 2019 by Stefan Glienke

[PeterPanettone 158]

Thanks, Stefan.

 

I would have preferred "the old way" which is more formal.

 

BTW, are there any drawbacks in using inline variables? I am not sure, but I remember having read somewhere that there is still a bug in using inline variables.

[Stefan Glienke 2019]

IDE tooling does not work properly and some of it completely stops,

Also inline variables of a managed type are not always properly initialized.

 

As much as I like this feature syntax wise - I would stay away from it for now 😞

[PeterPanettone 158]

😞 😞 😞

[Dalija Prasnikar 1404]

27 minutes ago, Stefan Glienke said:

IDE tooling does not work properly and some of it completely stops,

Also inline variables of a managed type are not always properly initialized.

 

As much as I like this feature syntax wise - I would stay away from it for now 😞

If everyone stays away, bugs will never be found and fixed...

 

I have used them a lot in various shorter and longer experimental code... so far so good (in spite known bugs)

[PeterPanettone 158]

Is there somewhere a comprehensive list of bugs provoked by inline variables?

[Stefan Glienke 2019]

4 minutes ago, PeterPanettone said:

Is there somewhere a comprehensive list of bugs provoked by inline variables?

https://quality.embarcadero.com/issues/?jql=text ~ "inline variable" and affectedVersion in ("10.3 Rio"%2C "10.3 Rio Release 1") and status not in (Resolved%2C Closed)

Edited April 1, 2019 by Stefan Glienke

[FredS 138]

18 minutes ago, Dalija Prasnikar said:

found and fixed

Those are two different things, but using your release to beta test your tool set isn't really for everyone..

 

[PeterPanettone 158]

Well, if Editor marks inline variables as error is the only bug caused by inline variables then I can easily live with it as I have switched Error insight off:

 

 

Or are there any other bugs caused by inline variables?

[FredS 138]

25 minutes ago, PeterPanettone said:

any other bugs

Stefan's link shows 75 bugs.. then there are those 'secret' internal ones..

Edited April 1, 2019 by FredS

[David Heffernan 2353]

2 hours ago, Dalija Prasnikar said:

If everyone stays away, bugs will never be found and fixed...

Herd immunity springs to mind

[PeterPanettone 158]

So why Embarcadero hasn't fixed these bugs in 10.3.1?

Edited April 2, 2019 by PeterPanettone

[Remy Lebeau 1436]

On 4/1/2019 at 7:25 AM, Stefan Glienke said:

It however is not possible to declare the variable in the old way plus initialize it - you have to declare it inline

Note that FreePascal supports initializing variables in "old style" declarations.  A shame that Delphi does not also support that, seems like something that might have been easy for Embarcadero to add while they were messing around with how variable declarations work.

[PeterPanettone 158]

4 hours ago, Remy Lebeau said:

Note that FreePascal supports initializing variables in "old style" declarations.  A shame that Delphi does not also support that, seems like something that might have been easy for Embarcadero to add while they were messing around with how variable declarations work.

Is there a specific technical reason why FreePascal can do it and Delphi can't do it?

[Remy Lebeau 1436]

1 hour ago, PeterPanettone said:

Is there a specific technical reason why FreePascal can do it and Delphi can't do it?

There is no technical reason that I can think of, Borland/CodeGear/Embarcadero could have expanded on the Pascal syntax, like FreePascal did, but they simply never got around to implementing it that way.  Remember that FreePascal is its own Pascal compiler, it is not based on Delphi, so it is free to do things however it wants to.  It has quite a few Pascal language niceties that Delphi doesn't.  Even Generics and Unicode support are other areas where FreePascal differs greatly from Delphi.  But, FreePascal does have special compatibility modes meant for migrating Delphi code to FreePascal.  In those modes, it tries to closely emulate Delphi 7 or 2009, depending on whether Unicode is being emulated or not.

[FredS 138]

39 minutes ago, Remy Lebeau said:

In those modes, it tries to closely emulate Delphi 7 or 2009, depending on whether Unicode is being emulated or not. 

Check, so the free tool can downshift to accommodate Delphi 🙂

http://wiki.freepascal.org/Helper_types#record_helper

[Rudy Velthuis 91]

On 4/1/2019 at 4:50 PM, PeterPanettone said:

Thanks, Stefan.

 

I would have preferred "the old way" which is more formal.

 

BTW, are there any drawbacks in using inline variables? I am not sure, but I remember having read somewhere that there is still a bug in using inline variables.

Sometimes, type inference can cause an internal error, e.g. when the type is TArray<something>. If you specify the type, it works.

[Lars Fosdal 1793]

This works well in our 10.3 production code, so it is not entirely useless.  The THardAllocList is a TList<T>, though - not a TArray<T>.

Several typeless inline declarations with initialization, and a inline string var with initalization.

procedure TPSDTask_ImportCustomerOrders.ProcessHardAllocations(const aDeliveryId: Integer;
  const HardAllocations: THardAllocList);
begin
  for var Alloc in HardAllocations
  do begin
    var TPack := GlobalTPackList.FindByTPackNo(Alloc.TPackNo, True, True);
    if Assigned(TPack)
    then begin
      var TPQ := TPack.GetQuantityOfArticleOnTPack(Alloc.ArticleId);
      var ArtSum := GlobalArticleSummaryList.FindByArticleId(Alloc.ArticleId);
      if ArtSum.QuantitiesAreEqual(Alloc.Quantity, TPQ)
      then begin
        if TPack.AllocatedDeliveryId = 0
        then begin // Allokér TPack til leveranse
          var AllocMsg: string := '';
          if TPack.AllocateToDelivery(aDeliveryId, AllocMsg, True) = rOK

[Darian Miller 366]

6 hours ago, Lars Fosdal said:

 

procedure TPSDTask_ImportCustomerOrders.ProcessHardAllocations(const aDeliveryId: Integer;
  const HardAllocations: THardAllocList);
begin
  for var Alloc in HardAllocations
  do begin
    var TPack := GlobalTPackList.FindByTPackNo(Alloc.TPackNo, True, True);
    if Assigned(TPack)
    then begin
      var TPQ := TPack.GetQuantityOfArticleOnTPack(Alloc.ArticleId);
      var ArtSum := GlobalArticleSummaryList.FindByArticleId(Alloc.ArticleId);
      if ArtSum.QuantitiesAreEqual(Alloc.Quantity, TPQ)
      then begin
        if TPack.AllocatedDeliveryId = 0
        then begin // Allokér TPack til leveranse
          var AllocMsg: string := '';
          if TPack.AllocateToDelivery(aDeliveryId, AllocMsg, True) = rOK

 

 

I don't have 10.3 installed - so quick question on variables defined inline within a loop.   I assume they uninitialized with each iteration, correct?  (Or initialized exactly the same as normal stack variables) Technically then var AllocMsg :String := ''; in your example the null string default assignment is not needed?  Also the variables TPQ and ArtSum are assumedly interfaces which are automatically released on each iteration?

 

 

[Lars Fosdal 1793]

They would be uninitialized per iteration.

Ref. AllocMsg - what can I say other than old habits die hard 😛 
TPQ and ArtSum are regular objects retrieved from global shared pools and life cycle management happens elsewhere.