"D" parameter passing mechanisms

[David Keppel]

I've been wondering if the following parameter passing mechanisms lose any
possible optimizations:

    const - The value must be treated like a constant locally.  Any "real"
	parameter passing mechanism (value, reference, etc.) may be used,
	but no part of the value may be used as an lhs.

    value - The value is used.  The storage must be distinct from the
	original (unless the caller is happy to have the value trashed).

    inout - The value will be returned to the caller *eventually*.  This
	may be implemented as call by reference, call by value/result,
	etc.  The interaction of aliased variables is *undefined*.  The
	order of returning values (for value/result) is undefined.

    volatile - Call by reference.  All values are guaranteed to be updataed
	immediately, so that if there is shared (aliased) storage, the
	values are always consistant.

I know Ada has an "out" parameter type, but I don't see that it provides
any more optimizations than the inout, rather it provides debugging in
that it won't let you assume that the value is set when you enter the
function.

I'd be curious if anybody can come up with a case when using of one of the
four above parameter passing techniques prohibits some kind of optimization
that could be achieved with another parameter passing technique.

Please "reply" rather than cluttering comp.lang.c with comp.lang.d   Thanks!

	;-D on  ( Pass by left lane ?-)  Pardo