[fpc-devel] Variable can not be initialized by named constant

[Alexander Klenin]

On Mon, Mar 2, 2009 at 07:34, Daniël Mantione
<daniel.mantione at freepascal.org> wrote:

> This is a debate that has been held quite a few times :) If you look at
> typed consts from the point of view what a mathematical constant is, yes,
> it's completely absurd that you can write to them.
>From _mathematical_ point of view assignment to a variable is
just as nonsensical as assignment to a constant, but this is ok since
programming language is not a math notation.
To write to a constant is absurd from _programmer's_ point of view,
which is much worse in this case.

> But... you need to look at typed consts what they do, and not how they are
> named.
[skipped explanation]
I know this, but this is backwards reasoning.
Implementation details should not affect semantics.

> The compiler cannot prevent you writing to data in memory, since at runtime,
> the coder is the boss. All you need is to cast them into a pointer.

It can, it just currently chooses not to. This C++ code:

const int x = 1;
int main() {
  *(int*)&x = 2;
  return 0;
}

compiles, but causes access violation at run-time.

> Works flawlessly, regardless of the $J state. From this point of view of the
> function typed consts form, allowing writes to them isn't that illogical.

By using pointers, you can access private fields of an object,
change local variables of calling procedure, ignore variable types and
array boundaries.
Does this mean that Pascal should abolish variable scopes, type
safety, range checking?
No, this would turn it into an assembler language with Pascal-like syntax.
I believe "const-correctness" (to borrow a term from C++) is as
important as type safety,
and should not be abolished as well.

> const x:longint=1;    {Defines a location in memory large enough to
>                       hold an integer, which contains value 1.}
>      y=longint(1);   {Defines a compile-time symbol that is equavalent to
>                       writing longint(1) somewhere in the code.}
>
> ... do completely different things inside the compiler.
Yes, they do now, this is what I think is wrong.
What I am trying to say is that they should do (almost) the same thing.

> It will affect code generation, since typed consts are stored in memory.
This is the only difference that should remain -- to allow passing of
(read-only) typed constant and a const parameter.

> There exists no constant folding for typed consts, because they need to be
> layed out in memory exactly as the programmer describes, the compiler cannot
> mess with that unlike with real compile-time constants.
I am not sure what you mean here. How does compiler "mess" with constants?

> Basically code has
> to be generated that reads the typed consts from their fixed position in
> memory and copied into the variable.
Why? What prevents the compiler from inlining constant value just like it does
with untyped constants?

> Of course disallowing writing to typed consts is problematic because of
> people making use of this functionality. After all, typed consts existed
> long before initialized variables were invented and I'm sure people are
> still using them.
Borland did this long ago, in Delphi 6, and I do not recall large problems with
that change. Of course in Turbo Pascal mode they should stay on by default.

-- 
Alexander S. Klenin