[fpc-devel] Const optimization is a serious bug

[Chad Berchek]

Martin wrote:
> - See difference to normal "const" is " that it must be passed by
> reference."

I had not read about it before, but I think constref is a huge step in 
the right direction. It eliminates my fundamental grief with the current 
implementation.

Specifically, the way const is now "defined" (or not...) is disturbing 
because it leaves out important details. In C++, you can pass by value 
or reference, or by pointer which is a value but is used to make 
references. But what's important is you _always_ know what it's going to 
do. If you pass something by reference and modify that instance via 
another reference, they're all going to change, because they are the 
same instance. And if you pass by value, it's the opposite. The point 
is, though, you always know what it's going to be.

Imagine if we took C++ and redefined the pass by reference syntax as 
"the compiler might pass by value or reference, depending what it feels 
like". Result? Boom. Tons of carefully written code would suddenly break.

It is OK for implementation details to be unspecified. That is how they 
should be--but only if they are in fact implementation details. If they 
affect the *meaning* of the program, they have to be defined as part of 
the language. That's what bothers me. The behavior of const is something 
that does affect the behavior of the program, but it is undefined. 
/Usually/ when you pass a record as const it will by by reference, but 
maybe not. Ditto for other types.

All the problems we've seen with const used in various contexts with 
different data types--AnsiString, ShortString, records, etc.--are the 
result of one fundamental problem, which is the language design. Const 
is not clearly defined. All problems mentioned stem from this.

If we *knew* that const meant it would be by reference, then that 
immediately eliminates the confusion in the case of ShortString and 
records; modifying one instance through several references affects them 
all, as expected. What the programmer says happens; there can be no 
"bug", except in the programmer's own knowledge.

This precision of language is closely tied with the "testing" approach 
several people have mentioned. The "testing" approach is that you run 
the program with the const optimization on, and, if it works, great, and 
if not, turn the optimization off.

I greatly disagree with this approach. Testing is very important, 
certainly. But you can only ever test a tiny fraction of real world 
scenarios. Ultimately you are much better off if you can mentally verify 
that the program is unconditionally *correct*. That is why I cannot 
accept the ambiguous const feature, because it is impossible to 
theoretically prove that the program is correct, which is something I 
try to do as much as possible.

I applaud the notion of constref. I think it should be used everywhere 
as long as Delphi compatibility is not required.

The difference is slight. In many (but not all--and that's the key) 
cases using const or constref would result in the same assembly, if my 
understanding is correct. What's really important is that it allows the 
programmer to reason logically about a piece of code without mysteries 
popping up.