[fpc-devel] Const optimization is a serious bug

[Hans-Peter Diettrich]

Chad Berchek schrieb:

> Some might say that it doesn't matter whether it is passed by value or
> reference: if you pass it as const, either way you promise not to modify
> it. See, that is my concern: what is IT? People have used other words,
> but it ultimately comes down to: if you say the programmer promises not
> to modify the thing passed as const, what thing *exactly* is that? A
> variable, reference, or instance? With const, we don't really know.

IMO we know that then the data, passed as immediate values on the stack, 
shall not be modified by the subroutine. The only confusion was about 
const records (and ShortStrings?), when passed by reference. In this 
case the content of the referenced record cannot be changed.

When alias are of concern, don't use "const".

> With
> constref, it means you promise not to modify the memory location
> (instance) pointed to by that reference.

Quite useless with objects, which typically are modified by method 
calls. Otherwise same as above.

> With constval it means
> that you can change the memory location/instance that was
> passed into the procedure, since the procedure is now using it's own
> copy anyway; you just can't modify the instance that the procedure now
> has it's own copy of.

IMO that's the normal (non-const) procedure, so far. Any changes to the 
passed arguments are invisible after exit from the subroutine.

> One additional problem does arise. Constval implies that the
> implementation is pass-by-value. However in many (I'd say most) cases it
> is quite possible that we could be interested only in the semantics of
> pass-by-value, not the implementation. So for AnsiStrings, neither
> constref nor constval would be suitable. Constref would mean it must be
> by reference, but we want by-value semantics. Constval would mean that
> the string has to be copied to a separate memory location, which we
> might not really care about, and is slow and wasteful.

That's why copy-on-write was invented. As soon as the data is modified, 
a (local) copy is created.

> So, I propose: don't have constval literally mean it is passed by value,
> i.e.,
> pushing the string onto the stack or copying it to a new memory
> location. Instead, have constval defined as by-value *semantics*. In other
> words, constval would indicate the meaning of the language, not the
> implementation. It would not be a calling convention. It would not mean
> the call would be by value; it would mean the semantics would be by
> value. This is essentially what I originally thought const would mean
> with AnsiStrings, though it turned out hazy.
> 
> The programmer must know the language and the compiler must implement the
> language. How the compiler does that should not determine how the
> program behaves.

IMO that's such a weak definition, that it gave birth to this never 
ending thread :-(

In the tradition of Wirth, it should be possible to describe the 
language semantics by a few implementation details. The implications 
*resulting* from the implementation, like alias, are already discussed 
in common literature.


> See regarding const:
> http://www.freepascal.org/docs-html/ref/refsu58.html
>> The main use for this [const] is reducing the stack size, hence
>> improving performance, and still retaining the semantics of passing
>> by value...
> 
> (Thanks for the link Alexander!)
> This is undoubtedly the most conclusive statement I've seen regarding
> this issue. If this documentation were correct, my initial claim that
> there is a bug would be correct.

Aliasing is not considered a bug, it's a fact. When a pointer is passed 
to a subroutine, it should be clear to every coder that the referenced 
memory *can* change during the lifetime of the pointer, even if the 
pointer (address) is never changed; the same for all references. When a 
coder allows to pass a data structure byref instead of byval, by using 
"const", he'll have to accept all the consequences. Since this 
difference was the only rationale for introducing "const" into the 
language, it has to be accepted as defined, and the documentation should 
be updated accordingly.

Effectively the "...semantics..." statement should be dropped from the 
docs, and instead the effects of the "const" modifier on *all* affected 
datatypes have to be added.

DoDi