The ever re-appearing /= question.

[mercurhyo]

c'mon ! I started programming 5mis and a half earlier.
 
{$TROLLMODE ENFORCED}

[Thaddy]

strrepeat/stringofchar()

[mercurhyo]

 
chess-mate
 

[PascalDragon]

@PascalDragon

Frankly I agree with you as you know: but the patch is a bug-fix for something we both did not want and you can't remove it, so why don't fix it? The patch is sound, well tested and has no impact apart from fixing the behavior to be compatible with the contract that it behaves like C.

Meaning I take no for an answer as in the feature should not be there, but I refuse to take it as a bug fix. That is incoherent.
It is a FIX, not a feature. At least try the patch yourself.

Why would you leave in malfunctioning code?
Either remove it (you have my vote!) or apply the fix.

Again, in Pascal integer division is div, not /, so allowing /= for integer division is a no-go from a language point of view. And that is what counts here. Additonally there will also be no div=. The C-operators will simply continue to exist as they are right now. They simply haven't been thought all well enough back in the past and that's how they are.

While I am very tempted to do just that or at least to throw out the -Sc from the default fpc.cfg marcov is also right that this is not very realistic. Keeping them in does however not mean that we'll extend them in any way. They should not have been added in the first place and also shouldn't have been added to the default fpc.cfg.

Would it be feasible to compromise and only allow them to be applied to constants, i.e. /= 2 etc.?

There will be no compromise.

[tetrastes]

And what is about this?
https://www.freepascal.org/docs-html/current/prog/progsu10.html#x17-160001.2.10:

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

1. {$COPERATORS ON}
2. //The following operators are allowed:
3.  
4. Var  
5.   I : Integer;  
6.  
7. begin  
8.   I:=1;  
9.   I+=3; // Add 3 to I and assign the result to I;  
10.   I-=2; // Subtract 2 from I and assign the result to I;  
11.   I*=2; // Multiply I with 2 and assign the result to I;  
12.   I/=2; // Divide I with 2 and assign the result to I;  
13. end;

Note line 12 

[440bx]

Note line 12 

That should not compile because "I" is an integer and "/" applies only to floats.  The compiler should emit an error on that line.

IOW, that wiki example is incorrect.

[tetrastes]

And it's not compiled.
But it's not a wiki, it's official documentation from freepascal.org by Michaël Van Canneyt.
And as this is so, Thaddy is right that it is bug, and if fpc maintainers don't want to correct it, they have to correct documentation, at least.

[440bx]

if fpc maintainers don't want to correct it, they have to correct documentation, at least.

Yes, the documentation is incorrect and should be corrected.  in Pascal "/" applies only to floats not to integers.

[dsiders]

And it's not compiled.
But it's not a wiki, it's official documentation from freepascal.org by Michaël Van Canneyt.
And as this is so, Thaddy is right that it is bug, and if fpc maintainers don't want to correct it, they have to correct documentation, at least.

Has a bug report  been filed (for either)?

[440bx]

Has a bug report  been filed (for either)?

Created a bug report against the documentation:

Ticket:41705
Link: https://gitlab.com/freepascal.org/fpc/source/-/work_items/41705


ETA:

Apparently the above bug report was unnecessary as it is reportedly already corrected.
https://gitlab.com/freepascal.org/fpc/documentation/-/commit/84679dfdfbfe7e9e45decb107b8fe8fc8d243f19

[Thaddy]

My original bug report was either or: either apply the fix or fix the documentation and the documentation example.
I welcome the split to explicit documentation. I will keep the fix in my private branch along with another related one, multiplication int *= float, passes in C like: i = (int)(i * f + 0.5f);  (round instead of truncate), but that one came not with a documentation example). The fix is easy because the /= already provides the codepath.

Th extended patch is a two liner:

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

1.        
2. if (ntyp=slashn) and is_integer(p1.resultdef) then
3.   effective_ntyp:=divn
4. else if (ntyp=muln) and is_integer(p1.resultdef) then // add the two lines
5.    effective_ntyp:=muln
6. else
7.    effective_ntyp:=ntyp;

The rest is already taken care of by the /= patch.

[edit]
But it is still not complete...only for /= and *=

[n7800]

if fpc maintainers don't want to correct it, they have to correct documentation, at least.

Yes, the documentation is incorrect and should be corrected.  in Pascal "/" applies only to floats not to integers.

Just a note - documentation updates can be viewed in the daily version.

[440bx]

Just a note - documentation updates can be viewed in the daily version.

Good to know.  Thank you n7800.

[Thaddy]

The documentation is still incorrect for:
  int +=float
  int -=float
  int *=float;

What is should say in general is that the righthand type needs to be of the same type as the lefthand type, with the exception of float lefthand (result), which will accept both righthand float or integer types.
That is not C, but I have a code patch that handles all of those cases.
Since that will be refused, simply update the docs once again.

Sorry n7800...

[marcov]

What is should say in general is that the righthand type needs to be of the same type as the lefthand type, with the exception of float lefthand (result), which will accept both righthand float or integer types.

In general, it is not allowed to rely on the lefthand side in typing decisions in Pascal. This also causes problems with way more important cases like int64:=integer*integer;