Peter Gerwinski wrote:
[...] It needn't be an explicit assignment; it might be a call to a function which makes the value of `x' change. To pass everything by value *is* the only possibility.
I must admit, I didn't think of these cases.
But I will modify `Const' parameters to pass small things by value and to work with implicit temporary variables when a constant is passed as a `Const' parameter.
You mean, for big things!? I don't think you need any temporary variables for small things that are passed by value, regardless whether a variable, constant or an evaluated expression is passed. For big things passed by reference, you need a temporary variable if a constant or expression is passed, I think.
Then it's up to the programmer to take care that the `Const' parameter doesn't change its value due to side effects.
Then it would be like Borland's. However, speaking from a purist's point of view, I can see the problem that it would be implementation-dependent whether a parameter is passed by value or by reference. This means it is "undefined" whether side-effects can happen or not. Would it be permissible (well, const parameters aren't standard anyway, I mean in the "spirit" of the standard) to leave that undefined, or would it be necessary that const parameters have clear semantics concerning side-effects?
Hmmm ... how to tread `protected Var' parameters???
As far as I understood it up to now (Berend, correct me if that's not what the standard says), "protected" only means that the compiler must make sure that the parameter isn't altered, and never changes the way of passing the parameter.
That would mean:
'const' parameters would be used if the programmer is sure that there can't be any side-effects (which is true in the majority of cases, e.g. if the procedure operates only on local variables and will not be called with the same parameter twice; or e.g. if the procedure reads the value of the parameter only before it writes to any var parameters and/or global variables and/or calls any procedures/functions that do), and wants the compiler to choose the most efficient way of passing and to verify that the programmer doesn't accidentally alter the parameter.
'protected' parameters would be used if there is a danger of side-effects, and the programmer only wants to verify the parameter isn't altered, putting up with a possible inefficiency. (I think it's rare that side-effects become a problem, especially with big structures where the inefficiency would matter.)
'protected var' parameters would be used in the (very rare, IMHO) case that there could be side-effects, and the programmer *wants* these side-effects to influence the parameter. E.g., I could imagine a procedure that watches some variable for changes, but must not change the variable by itself - perhaps in a multi-threaded program where another thread could modify the variable - just fantasizing...