Reference vs. copy semantics in passing parameters

[mfeldman@seas.gwu.edu (Michael Feldman)]

In article <jls.666659373@yoda> jls@yoda.Rational.COM (Jim Showalter) writes:
>There is an unsafe aspect of passing access types as IN parameters in Ada
>that is, sad to say, handled rather better in C++.
>
>In Ada, you can pass an access type to a function as an IN:
>	type Some_Foo...
>        type Pointer is access Some_Foo;
>        function Some_Bar (Some_Param : in Pointer)...
>And then, inside the function, dereference the pointer and modify the
>pointed-to construct.
>
>In C++, you can declare not only the pointer constant but the pointed
>to construct constant as well. This allows passing by reference in a
>read-only manner, which is NOT possible in Ada at present.

Well now I'm curious. Given that only scalars and small structures are
usually passed by copy, why would you want to guarantee reference
passing for read-only parameters in such a kludgy way? Ada provides you
with everything you need:

- parameters large enough to cause performance concerns are passed by
  reference anyway (in any reasonable implementation, anyway);

- IN parameters are read-only, no matter how they are passed.

Am I missing some important other issue here? What aren't you getting
from this combination of features?

Mike Feldman

PS: It seems to me that Ada9x could clarify the issue by simply requiring
that structured parameters be passed by reference (instead of the Ada83
rule that it's implementation-dependent). Since a program whose behavior
depends upon the method of passing is - by definition of the LRM -
erroneous, the only programs that would break would be erroneous ones,
which Ada9x says it doesn't care about. So the clarification would be
upward compatible. Ada9x-ers: what would be the objections?