C operators and shift

[Okoba]

With {$COPERATORS ON}  you can write:

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

1. I *= 2;
2. I := I >> 1;

But you can not write

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

1. I >>= 1;

Why?

[alpine]

Are you sure you can write:

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

1. I = I >> 1;

?

[Okoba]

Sorry for the typo. Should be fixed now.

[MarkMLl]

Because the compiler developers are still engaged in collective flagellation over the presence of /any/ of += -= *= etc. in the language, so don't even dream of it.

Also remember that you get into trouble with shifts > 31... not directly related, just a reminder.

MarkMLl

[Okoba]

Thank you.

[marcov]

The C operators were meant for lower risk on errors while converting C (typically compression) code. It was never meant for new code.

[Thaddy]

They are also not without risk on their own because not every construct - like operator overloads - works with them.
My personal opinion is to drop the "feature" or consider to implement it in full.(Which core already decided many years ago they won't do)
With that I mean, not only pre, but also post - like =+ , use value first, then increment - operators and all operators.
There was quite a discussion to implement them at all.

I tried a feature request about 10-12 years ago, don't even try it again.
To be fair: at the time I knew it would be refused. It was merely a request for completeness of the feature, not that I used it myself. More along the lines of:if you implement it half then finish the other half too.

[alpine]

About the semantic differences in C and FPC: https://forum.lazarus.freepascal.org/index.php/topic,55338.0.html

[Thaddy]

Yes, I know: but the biggest problem with these compounds is that if either left or right is overridden with a custom operator -e.g. either + or = -  it is broken anyway. In the compiler itself compound operators are not used, but I believe they are used in Lazarus packages.

[PascalDragon]

Why?

Because that is simply not supported and there is no interest to support it.

[Curt Carpenter]

All of the compounds made sense when we were punching cards and paper tapes and development environments were seriously resource-limited.  But that's not the case now, and the compounds reflect an emphasis on writer-efficiency when in the long run it's reader efficiency that matters most.  IMHO of course. 

[Warfley]

I'd argue that c style operators are better than writing the expression out because it reduces complexity and can avoid errors:

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

1. x *= a+b;
2. // VS
3. x := x*(a+b);

When you read the expression left to right after reading the second symbol you already know that x will be multiplied by some value. In the second example you may think you only need to read 2 more tokens, but thats also oversimplified. Consider the following:

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

1. x := x*(a+b)+c;

Now the whole semantic changed, this is not just multiplying x with something, it does a multiplication plus addition.
Thinking about graphical development *= clearly indicates scaling while an arbitrary expression can combine scaling (multiplication) with translation (addition). So you always need to parse the whole expression to know whats going on.

Also note that this requires bracketing due to operator precendece, which makes the expressions more complex and easier to make errors.

C style operators reduce complexity and thereby cognetive load.

[marcov]

I'd argue that c style operators are better than writing the expression out because it reduces complexity and can avoid errors:

There is always a con, if only the added complexity in language and compiler. 

[Thaddy]

Currently it simply does not work, only for very simple cases.
write a + operator
write a := operator

try to use +=

You can't. You can't write an operator for +=, or compound shifts for that matter. Remove it.
(+= should resolve to +:=)

[Aistis]

C style operators reduce complexity and thereby cognetive load.

I have to disagree with this. When skimming through, I've read x *= a+b; as x := a+b; While the other x := x*(a+b); was clear as day what it is, and it is why I had to go back and reread the first statement that I had misread. I think that the problem is the way Pascal uses := instead of = for assignments makes <whatever symbol>= just look like a := when skimming through code.

I personally don't like reading cryptic code like x /= -x-- + ++y / -y++;