Problems with case statement [SOLVED]

[MarkMLl]

No, there is no $mode at the top of my file. The only significant difference between my code and yours is, possibly, that mine is being compiled as a Lazarus project, with the source code being held in the `Search_Replace.lpr` file. Otherwise my code is exactly as in the message labelled "The final working code...".

And the insignificant differences? :-)

If you manage to get anything like that happen again then freeze it: zip the entire directory tree without deleting anything. My suspicion is that you'd found a way to trigger a subtle problem- and I'm not sure whether this is the IDE or compiler- where something was not recompiled when it should have been and having the various intermediate files might enable the developers (poor dears!) to track it down.

But I would emphasise that this is not common, the only time that I've seen it was when there was a combination of conditional compilation and include files.

MarkMLl

[Curt Carpenter]

Line 60 in your console app is different than line 18 in your original post if it matters.

[carl_caulkett]

Thanks! It's okay. There were quite a few improvements over the original post, eg. the use of +=.

[carl_caulkett]

If you manage to get anything like that happen again then freeze it: zip the entire directory tree without deleting anything. My suspicion is that you'd found a way to trigger a subtle problem- and I'm not sure whether this is the IDE or compiler- where something was not recompiled when it should have been and having the various intermediate files might enable the developers (poor dears!) to track it down.

Yes, you're quite right, I should have kept a frozen copy. I was more concerned with getting it working, but I appreciate that capturing these, thankfully rare, glitches is the only way they're going to get fixed.

[Thaddy]

Thanks! It's okay. There were quite a few improvements over the original post, eg. the use of +=.

Almost all core developers regret that they ever implemented it and it is prone to errors. Do Not Use.
It is also incomplete in its implementation: it does not allow e.g =+
This advice is not by me, but by the core developers.

[MarkMLl]

Almost all core developers regret that they ever implemented it and it is prone to errors. Do Not Use.
It is also incomplete in its implementation: it does not allow e.g =+
This advice is not by me, but by the core developers.

I don't like criticising the core team in public, but if they are aware of problems with specific use cases then those should result in compilation errors or warnings.

I've seen far too many idioms which are assumed to exist by people with experience in other languages rejected because "they aren't Pascal". It's all very well refusing to implement something which results in ambiguous syntax or unreliable semantics (notably, ++ etc.), but in the vast majority of cases += is applied to a simple scalar and anybody who doesn't like that should have their objections properly documented.

MarkMLl

[Thaddy]

Mark, if they did not implemented it by accident, there would be no questions.
One of those things that are hard to withdraw. I am sure you experienced similar in your carreer.
Some users still insist on it, against all warnings over the years and this is a non-feature that is the least likely to get much attention for improvement. Duely so.

[carl_caulkett]

Thanks! It's okay. There were quite a few improvements over the original post, eg. the use of +=.

Almost all core developers regret that they ever implemented it and it is prone to errors. Do Not Use.
It is also incomplete in its implementation: it does not allow e.g =+
This advice is not by me, but by the core developers.

Yikes 

I'll remove them forthwith...

[alpine]

Sorry for being off topic ...

I've seen far too many idioms which are assumed to exist by people with experience in other languages rejected because "they aren't Pascal". It's all very well refusing to implement something which results in ambiguous syntax or unreliable semantics (notably, ++ etc.), but in the vast majority of cases += is applied to a simple scalar and anybody who doesn't like that should have their objections properly documented.

Isn't that the same as saying that IfThen(Boolean,Arg1,Arg2) can be used in exchange for the ternary operator as it will be applied only to constant/simple Arg1,Arg2 expressions?
 
Just to refresh your memory a bit:
https://forum.lazarus.freepascal.org/index.php/topic,55338.msg411546.html#msg411546
https://gitlab.com/freepascal.org/fpc/source/-/issues/39206

Consider:

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

1. function PostIncInl(var I: Integer): Integer; inline;
2. begin
3.   Result := I; Inc(I);
4. end;
5.  
6. function PostInc(var I: Integer): Integer;
7. begin
8.   Result := I; Inc(I);
9. end;
10.  
11. var
12.   A: array of Integer = (0, 0, 0, 0);
13.   B: array of Integer = (0, 0, 0, 0);
14.   I: Integer = 0;
15. begin
16.   A[PostInc(I)] += 1; // A[I++] += 1;
17.   A[PostInc(I)] += 1; // A[I++] += 1;
18.   I := 0;
19.   B[PostIncInl(I)] += 1; // B[I++] += 1;
20.   B[PostIncInl(I)] += 1; // B[I++] += 1;
21.   // A = (1, 0, 1, 0)
22.   // B = (0, 1, 0, 1)
23. end.

Can you see the effect of a single inline directive?

Lazarus 2.2.4 (rev lazarus_2_2_4) FPC 3.2.2 x86_64-linux-gtk2

[MarkMLl]

Isn't that the same as saying that IfThen(Boolean,Arg1,Arg2) can be used in exchange for the ternary operator as it will be applied only to constant/simple Arg1,Arg2 expressions?

No, it's the same as saying that the compiler will reject any attempt to use it for other than simple expressions.

I believe that IfThen()'s behaviour is well documented, but in any event it can be inferred from the fact that it's a standard function which can be expected to evaluate its parameters in the same way as any other function.

The developers have- at various times in the forum etc.- told us why they don't like += . However I do not believe that these objections have been marshalled into any of the manuals, and there is definitely nothing that says "Don't use these" (which could include a deprecation or portability marker).

"In addition to the standard Pascal assignment operator (:=), which simply replaces the value of the variable with the value resulting from the expression on the right of the := operator, Free Pascal supports some C-style constructions ... These constructions are just for typing convenience, they don’t generate different code."

In what way does that constitute a "there are conditions under which this fails" warning?

MarkMLl