Why does Free Pascal use a colon in its assignment operator?

[J-G]

In pascal you always need to add brackets around each comparison because 'and' and 'or' have such a high priority.

But dont you think that the same construct having different functions is not confusing? Like

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

1. if (bmp and mask <> 0) and (bmp and mask2 <> 0) then

You have the same operator doing completely different things. I personally think that features that are semantically very different should also syntactically be different.

Sorry @Warfley  -  that starts with a 'mis-quote'. The text you show is yours, not mine - though I have edited it to make the meaning clearer.

Further I cannot see how your code demonstrates the same operator doing different things    <> means 'is not' in my mind and has no bearing on previously quoted operators which were 'Equal to' and 'Greater than or equal to'.  The construct is (to me) perfectly legible.

Unless I'm totally missing some point 

[Warfley]

Yes, you are right, quoting on the phone can be difficult

About the and, there are two different and operations, there is bitwise and and logical and. Both have the exact same syntax but completely different semantics. In other languages that is not the case. That is exactly why other languages solve this by using different operators for that. C with & and &&, python with & and "and" or extended pascal with and and and_then.

Again even pascal developers thought this is a terrible idea, which is why this was changed in extended pascal. It was just not adopted by Borland who instead introduced a compiler switch, which is something I hope we can agree upon to be the worst possible solution

[creaothceann]

you can explicitly target short circuit and full evaluation within code without having to use weird compiler switches. How many times I had to write

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

1. {$Push}
2. {$B+}
3. If ... Then
4. {$Pop}

Is really annoying and in C I can just express this as part of the expression

In what scenarios do you need full evaluation? I always keep it at short-circuit. Very useful when checking if an index is still inside an array, then accessing the array. (EDIT: or dereferencing pointers)

From a recent project:

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

1. type
2.         AnsiChars = set of AnsiChar;
3.  
4. const
5.         Chars_Whitespace = [#09, #32];  // horz. tab, space
6.         Chars_Linebreak  = [#10, #13];  // linefeed, carriage return
7.  
8. var
9.         Src : AnsiString;
10.         x   : integer;
11.  
12. function EOF : boolean;  inline;  begin  Result := (x <= Length(Src));                  end;
13. function EOL : boolean;  inline;  begin  Result := EOF or (Src[x] in Chars_Linebreak);  end;  // check position first
14.  
15. function matching(const c : AnsiChars) : boolean;  inline;
16. begin
17.         Result := (not EOF) and (Src[x] in c);  // check position first
18. end;
19.  
20. procedure Read_Whitespace;  begin  while             matching(Chars_Whitespace)  do Inc(x);  end;
21. procedure Read_EOL;         begin  while             matching(Chars_Linebreak )  do Inc(x);  end;
22. procedure Read_to_EOL;      begin  while not (EOF or matching(Chars_Linebreak )) do Inc(x);  end;

But more importantly, they have different operator precedence [...] In pascal you always need to add brackets

I always add brackets, so I don't have to remember operator precedences.

- - -

But tbh. having different operators for bitwise and logical sounds good.

[Thaddy]

In what scenarios do you need full evaluation?

In all secenario's where you need prevention of timing attacks. Quite common in security and cryptology.
In all scenario's where code may depend on full evaluation. E.g. where the right most operant sets variables for later use, but only the left most operant is directly used in evaluation or if the condition is not met just the right most operant is evaluated.
The first is common, the second is not as rare as you think, but can solve otherwise hard to achieve code paths. Will add example for that later.

[Paolo]

I always add brackets, so I don't have to remember operator precedences.

The same here. I tend to be verbose with brackets if that increases readability

But tbh. having different operators for bitwise and logical sounds good.

It seems reasonable.

[Warfley]

In what scenarios do you need full evaluation? I always keep it at short-circuit. Very useful when checking if an index is still inside an array, then accessing the array. (EDIT: or dereferencing pointers)

A possible scenario where you might need full evaluation is if you do branchless programming, especially when targeting a machine without predictive branching this can make a lot of difference in performance.

But I agree, most of the time it is very useful, but even then the switch is a horrible idea, because you cannot be sure how it is set. If someone sets it to full evaluation in their fpc.cfg then all your code that relies on it being deactivated will fail on that users machine. So if you actually rely on this setting you'd need to write:

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

1. {$Push}
2. {$B-}
3. If CheckIndex(Index, Arr) and (Are[Index] = 42) Then
4. {$Pop}

Which is so annoying no one does this and just assumes the compiler switch to be set a certain way.

There is no scenario in which having essential control flow decided by a compiler setting is a good idea

[creaothceann]

If you're changing someone else's code, perhaps it's possible to call functions in a unit that you wrote yourself and added to the project, and in which you control the short-circuit setting.

For branchless programming I wouldn't use booleans at all... except perhaps setting multiple bits in variables that are at the same address as a ByteBool/WordBool/LongBool/QWordBool variable, and then the combined value is used.

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

1. unit MyUnit1;
2.  
3. interface
4.  
5. function full_or      (const b1, b2 : boolean) : boolean;  inline;
6. function branchless_or(const b1, b2 : boolean) : boolean;  inline;
7.  
8. implementation
9.  
10. function full_or(const b1, b2 : boolean) : boolean;  inline;
11. begin
12.         {$BoolEval on}
13.         Result := b1 or b2;
14. end;
15.  
16. function branchless_or(const b1, b2 : boolean) : boolean;  inline;
17. var
18.         tmp : packed record
19.                 case integer of
20.                         0: (b1, b2 : ByteBool);
21.                         1: (r      : WordBool);
22.                 end;
23. begin
24.         tmp.b1 := b1;
25.         tmp.b2 := b2;
26.         Result := tmp.r;
27. end;
28.  
29.  
30. function branchless_or(const b1, b2 : boolean) : boolean;  // version 2
31. begin
32.         Result := ((ord(b1) OR ord(b2)) <> 0);
33. end;
34.  
35.  
36. end.

[tetrastes]

Yes, you are right, quoting on the phone can be difficult

About the and, there are two different and operations, there is bitwise and and logical and. Both have the exact same syntax but completely different semantics. In other languages that is not the case. That is exactly why other languages solve this by using different operators for that. C with & and &&, python with & and "and" or extended pascal with and and and_then.

Again even pascal developers thought this is a terrible idea, which is why this was changed in extended pascal. It was just not adopted by Borland who instead introduced a compiler switch, which is something I hope we can agree upon to be the worst possible solution

Instead pascal has different operators fo integer and real division