LRM 4.1.3 paragraphs 17-19

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

In article <009442AE.D4BD5E20@uno.edu> jncs@uno.edu writes:
>In article <2715@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
>>In article <1991Feb12.154418@riddler.Berkeley.EDU> yow@riddler.Berkeley.EDU (Billy Yow 283-4009) writes:
>>>  
>>
>>Another is the parameter passing scheme, in which reference semantics can
>>be used to pass arrays to IN parameters with no danger that the actual
>>will be changed (because IN parameters can't be written to).
>>Less copying (though a colleague of mine pointed out that the extra
>>indirection could actually make the program _slower_.)
>>
>The LRM leaves to the implementor to actually decide on the method of parameter
>passing IMPLEMENTATION in the case of structured types and IN parameters. I
>may use IN for arrays hoping for the COPY-semantics, but the LRM tells me not
>to trust it!

Well, there are two reasons for desiring copy-semantics. The first is to
guard against alteration of the actual. But this is automatic with an IN
parameter, since an attempt to write into the IN parameter is caught by
the compiler. The other only applies to OUT or IN OUT -  if the procedure
propagates an exception, the old values are still in the actual. Since IN
parameters aren't written to (by definition), this is a moot point.

For an IN OUT scalar, you are always safe in assuming copy. For a structured
type, as you point out this is up to the implementer. In fact, most pass
large structures by reference, to save copying time and space. So you're
out of luck on the exception issue, but on the alteration issue you are
_still_ safe, because even if the array is passed by reference, you
cannot change an IN parameter. IMHO this is NEAT.

So tell me - why do you care if an IN parameter is passed by copy or reference?

Mike Feldman