[fpc-devel] Const optimization is a serious bug

[Chad Berchek]

On 7/10/2011 2:40 PM, Daniël Mantione wrote:
> However, for a new calling convention (on an existing or a new
> platform) it's completely up to the compiler designer what will be
> passed as const and what will be passed as reference.

Agreed. That's why I say you can't really make assumptions: if you 
assume a certain platform, you can make a limited set of assumptions 
(very limited as I will show in a moment). However one of FPC's great 
features is its cross-platform power, so I don't want to make 
assumptions about the platform. Without assumptions about platform you 
can make even less assumptions about const.

> Within a certain calling convention, the behaviour of const is
> defined and will not change.

Even if the calling convention does not change, the semantics can, as 
currently implemented. Even within a single platform const is 
ill-defined. Consider the case of AnsiString. There are three cases as 
it is currently implemented:

1) Ref count > 1 when passed as const parameter results in strict 
pass-by-value semantics
2) Ref count = 1 and you modify the original instance in-place results 
in the value of the parameter changing
3) Ref count = 1 and you modify the original reference such that the 
instance's ref count decreases to zero and it may crash or just give 
weird behavior

Although the programmer knows about reference counting, it is not 
expected for the programmer to know the details of the implementation, 
which can change. Therefore you cannot be 100% certain what the refcount 
is at any given time. And therefore you cannot be certain how const will 
be treated. We know the implementation will be pass-by-ref with no 
refcount change. The semantics could be pass-by-value, pass-by-ref, or 
just plain crashing, depending on details we cannot predict.

> You Pascal code should be able to handle both value *and* reference.
>  After all, with const you are leaving the decision to the compiler.
> This is what it means in the end. Then your Pascal code should not
> depend on specific behaviour.

Yes, I agree fully. That is the only choice with const. Constref, as it 
exists, with the addition of constval, provide a more precise form of 
expression on those occasions where one might feel the ambiguity of 
const is insufficient.

And before anyone says something, yes, I also understand that if you 
pass something as a const, you have to be prepared in case it is passed 
by reference, and you have to realize that if it is passed by reference, 
you have to promise not to modify the instance via another reference. 
That's OK.

I am a relative newcomer to Pascal, having used it about 1.5 years now. 
It was disturbing that something so important was not documented 
anywhere, and, in fact, there was documentation to the contrary. Aside 
from the lacking and sometimes incorrect documentation (I refer not only 
to FPC but to Delphi), I was surprised when the semantics of const 
AnsiStrings, which usually turn out to be pass-by-value, actually might 
not be in rare cases that are hard to predict.

Aside from good documentation (which Delphi is in need of too in this 
particular case), I am proposing constval in conjunction with the 
existing constref to provide greater expressive power and precision for 
the programmer.