; after then

[BubikolRamios]

No errors, runs as all ok, sure does not do what one wants.
I guess sometimes it would be great if some kind of error/warning would be raised or something.
Years ago had that situation at line going off screen, you can imagine (-:
 

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

1. if circleArray[i].growStop = false then;
2.   circleArray[i].circle.r := circleArray[i].circle.r + 1;
3.  

[Martin_fr]

While it wont really help if fully off screen, there is "user defined markup".

I use that to highlight common mistakes like that.
(Note, I also have "then ;" with a space, and in some cases even with 2 spaces)

[eny]

I use that to highlight common mistakes like that.

You mean comparing a boolean variable with 'true' or 'false'?   

I wouldn't call a semicolon after 'then' a common mistake. It's one of the things that sets Pascal aside from the C-like languages: it's a separator, not a terminator.
Maybe if one comes from a C-like environment switching to (Free) Pascal.

[440bx]

You mean comparing a boolean variable with 'true' or 'false'?   

Indeed, that is the mistake in that code.

[Martin_fr]

I wouldn't call a semicolon after 'then' a common mistake.

Well, you don't need to call it that....

But step by step. Its not an error, its a correct pascal construct. But then, so is any code that compiles. Even if it does not do what you meant it to do.

And yes, you can intentionally write "then ;" if you intentionally want the empty statement. I have actually done that myself.

Yet, then again, codetools has more than once added a semicolon while I was writing a condition for an "if", and that ; hand remained in place after the "then". So it is a mistake that - at least for me, and likely the OT - happens regularly. 

In any case, its a mistake that can happen, and if it does, it can be hard to spot.

[Martin_fr]

Indeed, that is the mistake in that code.

Maybe earlier in that code (missing from the sample) there is something like

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

1. const false = 'OFF';

or

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

1. type TFoo = (foo, bar, false, help);

When you got old properties that RTTI stream from a stringified representation, and you need to change the type,  then you may need to have an enum that contains the old names...

[n7800]

It's hard to say how often users encounter this while coding, but I found a couple dozen instances in the release, including the Lazarus IDE and its packages (already fixed):
* https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/403
* https://gitlab.com/freepascal.org/lazarus/ccr/-/issues/39109

Yet, then again, codetools has more than once added a semicolon while I was writing a condition for an "if", and that ; hand remained in place after the "then". So it is a mistake that - at least for me, and likely the OT - happens regularly. 

Perhaps that the IDE could indeed contribute to this error, there's been an open issue regarding this for a long time:
* https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/37818

[440bx]

Indeed, that is the mistake in that code.

Maybe earlier in that code (missing from the sample) there is something like

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

1. const false = 'OFF';

or

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

1. type TFoo = (foo, bar, false, help);

When you got old properties that RTTI stream from a stringified representation, and you need to change the type,  then you may need to have an enum that contains the old names...

It's true that things like that can be done and they are valid Pascal but, I consider the creation of such code to represent mistakes (even though they compile) caused by rather poor programming.

I will, however, concede that as far as the compiler is concerned those aren't mistakes (at least not syntactical ones) since they compile.  Semantically, I don't consider them mistakes, I consider them atrocities.

IMO, the language should NOT allow the redefinition of quite a number of standard identifiers which it currently allows to be redefined.  Such redefinitions rarely, if ever, contribute to creating better code, on the contrary, more often than not they contribute to mislead the programmers who are left with the unenviable task of maintaining such code.

IMO, some "characteristics" of the language should be immutable, among many, the identifier "FALSE" should always be a boolean type with the value zero (at least in most common architectures.)  If the programmer wants something different then declare a new identifier instead of misleading programmers by making "creative" redefinitions of standard identifiers.

[creaothceann]

"then ;" is usually an error, but it can happen when you use macros that do or do not include some code based on compile-time conditions.

Also, a recent example where I (kinda) had to write an empty statement: I was writing an advanced record that had private variables but public properties. One of the variables was only added for alignment, i.e. padding, it wasn't used in the code. Naturally the compiler noticed that and added a note to the messages window:

<filename>.pas(31,3) Note: Private field "<record type>._padding" is never used

Since I try to keep the number of messages as low as possible, the solution was adding the line "if (_padding = 0) then ;" somewhere.

[n7800]

IMO, the language should NOT allow the redefinition of quite a number of standard identifiers which it currently allows to be redefined.  Such redefinitions rarely, if ever, contribute to creating better code, on the contrary, more often than not they contribute to mislead the programmers who are left with the unenviable task of maintaining such code.

Off topic, but I assume that such capabilities appeared precisely for the purpose of supporting... legacy code. After all, nothing prevents from not using them and rewriting the entire code correctly. That's the programmer's decision.

[440bx]

Off topic, but I assume that such capabilities appeared precisely for the purpose of supporting... legacy code.

I honestly don't think that's the reason but, I cannot prove it.  Fortunately, it is somewhat rare to see standard identifiers redefined in code (likely because doing that really is a programming atrocity.)

After all, nothing prevents from not using them and rewriting the entire code correctly. That's the programmer's decision.

I am definitely a strong supporter of letting the programmer decide most things but, the things that are defined by the language should be immutable, e.g, what FALSE means and its value and, that's just one in a large number of identifiers the compiler allows to be redefined.

IMO, the compiler should NOT give a choice and, if there is legacy code that breaks because of that, then it's time to fix that code instead of forever supporting poor programming for the sake of "backwards compatibility".

IOW, the compiler should be _predictable_ and that _requires_ ensuring its basic types and definitions are immutable, otherwise predictability goes out the window thereby causing all kinds of headaches.

It's a bit like strong type checking.  Forcing the programmer to live by the rules prevents mistakes. 

[PascalDragon]

IOW, the compiler should be _predictable_ and that _requires_ ensuring its basic types and definitions are immutable, otherwise predictability goes out the window thereby causing all kinds of headaches.

The point is that such identifiers are considered part of the namespace of the System unit. And due to ordinary language rules it's possible to redeclare symbols declared in another unit, cause they're still accessible using System.*. It also applies to intrinsics like Length, High, etc. or funnily enough Break and Continue (cause they're not keywords in the language sense).

[440bx]

It also applies to intrinsics like Length, High, etc. or funnily enough Break and Continue (cause they're not keywords in the language sense).

That is the root of the problem.  Many Pascal identifiers should be keywords thus preventing a programmer from getting too "creative".

[Curt Carpenter]

Wonder how many man-hours have been spent trying to find this problem when the ; is off screen?  It's a classic! 

[Hansvb]

there is "user defined markup".

Never used it until now. This is a great option. Another option I shouldn't forget to set up after a new install.