Alexander Klenin schrieb:
3) Current documentation
(http://www.freepascal.org/docs-html/ref/refsu58.html)
declares that "const" modifier is "retaining the semantics of
passing by value",
so there is definitely a bug here -- you can declare it to be bug in
specification, but still.
Sorry, I cannot find anything like this statement in the link.
It is a direct quote -- you can use "find on page" feature of your browser
(usually activated by pressing Ctrl+F) to locate it.
The whole sentence applies to the byval/byref modification, nothing is
said about the cases where references are passed even without const. In
this case I agree that aliasing can change the semantics.
On the more constructive note, I have yet another proposal:
1) Leave current "const" implementation broken as-is.
2) Introduce new "constval" modifier which is similar to "const",
but guarantees correct "by-value" semantics.
If you want to introduce different keywords, then please different for
beforementioned cases. E.g.
constval x: integer; //all value-types
constref r: Trecord; //also ShortString
const??? o: TObject; //all references, except following
const??? s: AnsiString; //all managed types
I am not quite sure what are you asking here. Can you elaborate?
To which data type do you want apply your "constval" modifier, with
which concrete effects?
When the meaning of "const"/"constref" is documented as kind of a *calling
convention*, that allows the compiler to optimize the code, no more
discussion is required.
"constref" is a calling convention, but "const" is not, since it is
"optimization hint".
From the user VP both affect code generation only. Both can be broken
by by aliasing.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
