The ever re-appearing /= question.

[Thaddy]

I feel very strongly about this and need your support to get this applied:

I have created a patch such that /= behaves like the C /=.
After all, the +=, -= and *= already worked for both float and integer types, so why would division be an exception?

That means that depending on the result variable the division is either float or integer.

Explanation:
Previously, `a /= b` was unconditionally desugared to `a := a / b`.
Because Pascal's `/` always returns Double, this caused a compile-time
type error when `a` was any integer type, making `/=` unusable for the
most common case.

When the left-hand side of /= is an integer type , emit a divn (integer division) node instead of slashn.
This gives the same truncation-toward-zero semantics as Pascal's `div`
operator and C's `/=` on integers.  Float LHS is completely unchanged.

No new syntax, keywords, or mode guards are introduced.  All existing
compound-operator mechanics (single evaluation of LHS, constant folding,
range checks, division-by-zero checking) are inherited automatically
from the established div/slash code paths.

Since I am always at odds with git's patch mechanism, the patch is a bit longer than necessary, but only a few lines.
The patch is attached.

Follows some test code, I will add more:

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

1. program divtest;
2. {$coperators on}
3. var
4.   a,b:integer;
5.   c,d:double;
6.   e,f:int64;
7. begin
8.   a:=10;
9.   b:= 3;
10.   a /= b;
11.   writeln(a);
12.   c:= 3;
13.   d:= 10;
14.   //fail
15.   //a /= c; // a is integer type
16.   //writeln(a);
17.   // pass
18.   D /= b ; // d is float type
19.   writeln(D);
20.   a := -7;
21.   b := 2;
22.   a /= b;
23.   writeln(a);
24.   e := 1000*1000*1000;
25.   f := 1000;
26.   e /= f;
27.   writeln(e);
28.   c /= f;
29.   writeln(c);
30.   a /= f;
31.   writeln(a);
32.   // note that this never worked:
33.   // writeln( a /= b);
34. end.

I hope for support to apply this, since it is my sincere opinion that this always was meant to work.

To me this has been a very important issue for years, and this provides a (the?) solution.

Please, test and humiliate me when it is wrong (it isn't).

Regards,

Thaddy

p.s.: patch is against trunk from 2026/3/31 9:23 UTC+1


Now zzzzzzzzzzzzzzzzzzzz I go and sleep.

In this case Claude was a big help solving the nitty gritty.

[runewalsh]

a /= b is a shortcut for a := a / b and nothing more (same in C). You’d need to support a := a / b for integer a to have any consistency, but you won’t, because in Pascal integer division is div.

I like the div= (..., mod=, and=, ...) idea btw, even if it looks ugly.

[Thaddy]

No, I don't want to expand the missing operators. All I want to achieve is that all the present - not new - shortcuts work as intended.
That is a common misconception by many.
If you introduce C style shortcut operators, make them work like C.
There are a lot more possibilities, but C has no div whereas the shortcut notation for pascal can easily cater for C style result based on the left-most parameter of the shortcut: there is no div= necessary and the patch is coherent with any "normal" expectations. If the shortcuts were a good idea? Dunno! undecided, but there were and will be many posts - not by me - about the current behavior.
You can either document it, which was not sufficiently clear, but thanx to n7800 better now, or simply correct it so integer results work like C.
I think my patch is an improvement but this matter is highly controversial, I know.

People who don't know about this decades long discussion should inform yourselves a bit better on what this is really about.
Shortcuts were never a good idea, but if you have them make them consistent over all operators present. It is in that sense not a new feature at all. It is a bug-fix.

[Thaddy]

Best point I can make is this, which happens to all of us if you are brave or stupid enough to use {$coperators on}:

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

1. {$mode objfpc}
2. var
3.   a:integer =10;
4.   b:integer = 3;
5. begin
6. // check integer div integer with integer result
7.   a:=10;
8.   b:= 3;
9.   a /= b;
10.   writeln(a);// fails, but in C integer divide.
11. end.

It should print 3, like I suggest.
Not fail. That is half a job.

My work fixes that.

[dbannon]

....
It should print 3, like I suggest.

But you are now redefining the meaning of '/'.   
'/' means one thing in a "a := a / b;" expression and something different in "a /= b;"
Dare I say it, it would make more sense to officially change the meaning of '/' in all usage (good luck with that !).

Davo

[Lauriet]

Hmmmmm,
I'm a bit dubious about adding these sorts of things. Its like converting Pascal into C. Makes it look more obscure. Wirth wanted a clear, consise language.
It may save a small amount of typing, but tends to making things a little less clear, unless you are aware of it.
Even your grany know what a := b / c means.

[MarkMLl]

People who don't know about this decades long discussion should inform yourselves a bit better on what this is really about.
Shortcuts were never a good idea, but if you have them make them consistent over all operators present. It is in that sense not a new feature at all. It is a bug-fix.

Whether or not they're a good idea, they're an established part of the language and the FPC Reference Manual says

"These constructions are just for typing convenience, they don’t generate different code."

Whilst I like the convenience of the += composite and believe that such things need to be supported due to their ubiquity in most extant languages, I'm uncomfortable with either breaking the behaviour described above (i.e. such that /= does a cast while / doesn't) or introducing yet another implicit cast into Pascal (both /= and / cast where necessary).

I admit that I'm also slightly uncomfortable with using this type of composite for non-commutative operators.

MarkMLl

[Thaddy]

If there is merit or not, I have created a new patch that even caters for int /= float which is in normal pascal int := trunc(int / float) which is actually a bit strange because of type inference and you can see from the patch that the compiler already knows that.....

To rephrase the lot:

I have added an additional feature that is accepted by C type languages that was missing, namely the case of int := int / float, which in fpc normally is written as int := trunc(int / float). I mistakenly thought all C compilers refused that, but that is not the case.

The new patch addresses that, again without being intrusive or damaging and tested for side effects (as per the test)
The new patch is by me, based on the previous patch with the comment for that still applied..
The test is written by claude and verified by deepseek.
The test passes fpc's overnight build system.

Mark wrote

I admit that I'm also slightly uncomfortable with using this type of composite for non-commutative operators.

and I have to admit that I share his discomfort.
But the point of this patch is to properly take care of omissions in the implementation of /= so that it behaves like /= means in all cases.
This time I made sure that all cases are covered, still with the least intrusive patch possible and verifying the patch does not have any side effects or otherwise causes any harm.

(Now I only need to take care that the compiler will also accept int := int /float without the truncation: I actually like what I have done for /= in that particular case....comments on that please tar and feathers allowed...)
 

[Thaddy]

Dare I say it, it would make more sense to officially change the meaning of '/' in all usage (good luck with that !).

Davo

Frankly I just did but only for ($coperators on}  ... but only for /= and it was easier than I expected and did not need AI for that, just promotion of the type checks.
What is the meaning of C operators otherwise?

For reference consider:

Code: C  [Select][+][-]

1. #include <stdio.h>
2.  
3. int main(int argc, char **argv)
4. {
5.     int a, b;
6.     float c, d;
7. // result int / int
8.     a = 10;
9.     b = 3;    
10.     a /= b;
11. // result float / float;
12.     c = 10.0;
13.     d =  3.0;
14.     c  /= d;
15.     printf("%f",c);
16. // result int /float
17.     a = 10;
18.     d = 0.333;
19.     a /= d;
20.     printf("%d\n", a);
21.     return 0;
22. }

Which is how fpc behaves with {$coperators on} when the new patch is applied.

[Thaddy]

If the latter 2 posts do not make a compelling case, I am fine with that...

But I won't call it a day just yet.

As long as this is very well understood:

When {$coperators on} was introduced with the explicit purpose of aiding C-to-Pascal translation, the implicit promise to the user was: when this switch is on, C compound operators behave as C programmers expect. The `/=` omission was not a design decision — it was an incomplete implementation of an already-accepted design decision made by whoever introduced {$coperators on} originally.

Feel free to argue against that. 

And yes, I am off the Oramorph.

[dbannon]

Thaddy, I do not generally use the C operators, so, no skin in the game. But I have to admit I have always found Pascal having two divide operators 'div' and '/' confusing.

But your solution makes that confusion worse !  You make '/' work sometimes, but not other times ! How is a new comer to cope with that ? 

As I said earlier, better to change it to work always (although I don't like your chances). It would be possible, no compilable pascal code lets you do "int := a / b" so why not try for it ? It simplifies code and makes your addition (er, division) non controversial.

Go on, suggest it for FPC Unleashed !       

Davo

[Thaddy]

@dbannon

Davo,

Sheer consistency with the design promise of {$coperators on}.
It is not inconsistent with the design contract in any way.
Anyway (sic), @Nitorami et.al are free to use my work.
Note Nitorami's plans and efforts are way beyond fixing a bug, but about introducing new features!

Personally I'd like a feature that I dislike to be implemented in a consistent way. Not half and then complain you don't like it.

All I did was implement an existing feature in a coherent, complete, way.
Thereby fixing existent bugs in that particular feature only.
In principle no new features, just a bug-fix.

PascalDragon seems to think "half is fine with me, I hated it anyway" (with due respect,    and full understanding of the matter, I hate it too, but it is there and needs maintenance)

[dseligo]

Hmmmmm,
I'm a bit dubious about adding these sorts of things. Its like converting Pascal into C. Makes it look more obscure. Wirth wanted a clear, consise language.
It may save a small amount of typing, but tends to making things a little less clear, unless you are aware of it.
Even your grany know what a := b / c means.

I agree.
I suggest that {$coperators on} are deprecated in upcoming FPC 4.0.

[Thaddy]

Hmmmmm,
I'm a bit dubious about adding these sorts of things. Its like converting Pascal into C. Makes it look more obscure. Wirth wanted a clear, consise language.
It may save a small amount of typing, but tends to making things a little less clear, unless you are aware of it.
Even your grany know what a := b / c means.

I agree.
I suggest that {$coperators on} are deprecated in upcoming FPC 4.0.

If that is not clear, I firmly agree with both of you, but bugs need to be fixed in the mean time. (it is NOT a new feature)
(Many people won't like the deprecation, though, unlike us, I am just pleading on behalf of the Devil  and fixing it on behalf of those many  )

[marcov]

Parts of FPC and lazarus itself unfortunately use coperators, so removal is not going to happen.

IMHO code where it is only a "convenience" features shouldn't have been allowed into the repo. So only for direct C translations it was originally meant for (like paszlib or pasjpeg) it should have been allowed.

But that ship sailed before 2000 already.