C-style assigments and side effects in FPC

[alpine]

This post is about a bugtracker issue I've just read, https://bugs.freepascal.org/view.php?id=39206.
It seems that the shorthand assignment operators +=, -=, etc.  in FPC have quite different semantics of that in C/C++ and are simply evaluated as a += b <=> a := a + b.
From the Reference manual:

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

At the other hand, for C/C++: https://en.cppreference.com/w/cpp/language/operator_assignment

The behavior of every builtin compound-assignment expression E1 op= E2 (where E1 is a modifiable lvalue expression and E2 is an rvalue expression or a braced-init-list (since C++11)) is exactly the same as the behavior of the expression E1 = E1 op E2, except that the expression E1 is evaluated only once and that it behaves as a single operation with respect to indeterminately-sequenced function calls.

And for C#: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/assignment-operator

For a binary operator op, a compound assignment expression of the form
x op= y
is equivalent to
x = x op y
except that x is only evaluated once.

As a bilingual programmer, I find this quite misleading (see the bugtracker issue). Assignments like a[f()] += b; will evaluate the left-hand expression twice thus doubling f()'s side effects if any.
In C/C++ very common practice is to write things like:

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

1. a[i++] += b[j++];

Personally, I'm avoiding the use of any C-style tricks in my Pascal sources just to maintain a clear distinction between them and the C's. My question actually is why a C-like feature was introduced in FPC but not with the same semantics? Anybody has an opinion? May be the compiler guys?

[PascalDragon]

Personally, I'm avoiding the use of any C-style tricks in my Pascal sources just to maintain a clear distinction between them and the C's. My question actually is why a C-like feature was introduced in FPC but not with the same semantics? Anybody has an opinion? May be the compiler guys?

They were introduced back then by someone (don't know who had the idea) who wanted to simply type less. They are simply syntax sugar, nothing more, nothing less and aren't a favourite among the core devs (we disallow them inside the compiler source for example). Nowadays a feature like that simply wouldn't be added (back then we were a bit less strict). And no, we don't want to "improve" them either.

[alpine]

*snip*
And no, we don't want to "improve" them either.

Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.

[winni]

*snip*
And no, we don't want to "improve" them either.

Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.

Bravo!!!!

Winni

[Kays]

[…] Assignments like a[f()] += b; will evaluate the left-hand expression twice thus doubling f()'s side effects if any. […]

Oh dear, that can be indeed confusing if you, as a C programmer, expect something else.

[…] They were introduced back then by someone […] who wanted to simply type less. […]

Too bad we can’t blame “someone”. According to whatsnew.txt it’s been added in 1.9.8. The migration CVS→SVN apparently occurred at/after 2.0.0 and I don’t find the CVS (if it is even available somewhere).

[…] I think they should be removed.

Well, I think as an intermediate step {$COperators off} should become the new default setting for a grace period before it’s actually removed.

[PascalDragon]

*snip*
And no, we don't want to "improve" them either.

Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.

As much as I'd like to do so, they will not be removed due to backwards compatibility.

[…] They were introduced back then by someone […] who wanted to simply type less. […]

Too bad we can’t blame “someone”. According to whatsnew.txt it’s been added in 1.9.8. The migration CVS→SVN apparently occurred at/after 2.0.0 and I don’t find the CVS (if it is even available somewhere).

The COperators directive was added then, but the C operators themselves are much older. Though due to some hickups in the CVS history it's hard to follow when exactly it was added and by whom and even then this does not mean that it was initiated by a dev, but instead by a user.

[…] I think they should be removed.

Well, I think as an intermediate step {$COperators off} should become the new default setting for a grace period before it’s actually removed.

COperators Off is the default as far as the compiler is concerned. The fpc.cfg includes the -Sc. Also this will not change due to backwards compatibility.

[MarkMLl]

"...the expression E1 is evaluated only once and that it behaves as a single operation with respect to indeterminately-sequenced function calls."

Noting what other people have said about how long this bit of syntactic sugar has been in FPC, I think it's fair to ask when C actually specified that E1 was evaluated precisely once: I don't think it was in K&R, I'm not sure whether it was in late-80s ANSI, and at that point FPC can hardly be criticised for not complying with something which had been slipped into C's specification at about the same time as it was first being written.

Speaking personally, I'm OK with concise operators PROVIDED that everybody understands the extent to which they're effectively a macro as distinct from something with distinct semantics. If FPC defines that E1 may be evaluated more than once or that it's implementation-specific (i.e. dependant on the vagaries of the optimiser) that's entirely fair, and the joke's on the C community and their initially-sloppy design.

MarkMLl

[Blade]

*snip*
And no, we don't want to "improve" them either.

Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.

Sorry, but disagree.  As they have already been around for quite a while, a percentage of people have already used them and are aware to be careful.  I think maybe only a warning or more detailed help explanation should be given.

[marcov]

The COperators directive was added then, but the C operators themselves are much older. Though due to some hickups in the CVS history it's hard to follow when exactly it was added and by whom and even then this does not mean that it was initiated by a dev, but instead by a user.

I think Peter in 0.99.x  with x=10,12,14, which were kind of like the 1.9.x series for 1.0.x.

Motivation was afaik error avoidance while converting C code, not usage in new pascal code, specially while loops. I suspect he was thinking of doing a new zlib port, rather than debugging the paszlib one. (which also supported 16-bit and was kept TP compatible)

It would maybe help to drive the message home if we removed the usage as much as possible. Afaik Lazarus uses it, FPC not so much.

[Thaddy]

FYI

I asked for just this that (increment after use) but it was refused.

[alpine]

"...the expression E1 is evaluated only once and that it behaves as a single operation with respect to indeterminately-sequenced function calls."

Noting what other people have said about how long this bit of syntactic sugar has been in FPC, I think it's fair to ask when C actually specified that E1 was evaluated precisely once: I don't think it was in K&R, I'm not sure whether it was in late-80s ANSI, and at that point FPC can hardly be criticised for not complying with something which had been slipped into C's specification at about the same time as it was first being written.

page 46, Kernighan, Brian; Ritchie, Dennis (1978). The C Programming Language (1 ed.)

2.10 Assignment Operators and Expressions

Expressions such as
i = i + 2

in which the left hand side is repeated on the right can be written in the
compressed form

i += 2

using an assignment operator like +=.

Most binary operators (operators like + which have a left and right
operand) have a corresponding assignment operator op=, where op is one of

+ - * / % « » & ~ |

If el and e2 are expressions, then

el op= e2

is equivalent to

el = (el ) op (e2 )

except that el is computed only once.

AFAIK, it is Algol68 inspired (+:=).

[MarkMLl]

page 46, Kernighan, Brian; Ritchie, Dennis (1978). The C Programming Language (1 ed.)

"except that el is computed only once."

AFAIK, it is Algol68 inspired (+:=).

Thanks for that, and apologies for my earlier misleading statement.

MarkMLl

[alpine]

@MarkMLl
Apologies accepted.

@Blade

*snip*
Sorry, but disagree.  As they have already been around for quite a while, a percentage of people have already used them and are aware to be careful.  I think maybe only a warning or more detailed help explanation should be given.

Until recently, I didn't even know they existed. It's weird that something so C-ish slipped through. (but marcov has already given some plausible explanation)

In my education Pascal came first, and then C, and although now I often use both in a same project, I'd never use x+=1 in Pascal, but rather Inc(x) or even x:=x+1. But that's me. I suspect a C-taught programmer will use a shorthand wherever possible. That is why I think they should work either the same way or be removed.

[marcov]

MarkMLI: note that this situation was one of the reasons I suggested to Benjamin to confine interoperability features to the import modules (the modules directly interfacing to <x>) in R10 .

The problems (usage outside the realm they were meant for, slipping into the general dialect) were not new to him, he already planned to confine them.