🚀 go-pugleaf

In article <1992Dec31.170854.21696@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
>In article <1992Dec31.053242.3376@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>> Proposal: 
>> 
>> 1) for the purposes of computing the signature of a function,
>> the symbols 'const', 'volatile' and any trailing '&' are ignored.
>
>> 2) As usually, attempting to define two functions with the same
>> signature results in a duplicate defintion.
>
>The worst effect of this idea would be that
>
>	void f(int&)
>and	void f(const int&)
>
>could not be overloaded.  This is useful and I don't think bad design.

	However, it *is* the intention of the proposal as it stands.
Similarly,

	f(int*);
	f(const int*);

would not both be allowed. The argument in favour of this
is that overloading is for two purposes:

A)	families of semantically equivalent operations on different types
	e.g. sin(float), sin(complex)

B)	convenience for accidental overloading
	e.g. draw(gun); draw(picture)
	or   sin(float); sin(priest);

In case (A) overloading is desirable because the associated
'transparency' renders the program more readable and amenable
to change of the types (float->complex). 

Addition of extra overloaded functions may cause re-binding,
say sin(double) is added, but it doesnt really matter
because this doesnt affect the overall semantics.
(Just precision and efficiency in this case)

In case (B) it is hoped the context will supply sufficient
context so that the reader does not imagine that the sin of
a priest is mathematical.

In the case that two functions

	f(int&);
	f(const int&);

are desired, their use in a program would be extremely sensitive
to the exact nature of the actual arguments, and the consequences
dramatically different. I would argue it is better style to have
two functions with different names:

	func_f(const int&); // proper function
	proc_f(int&);  // procedure--warning side effects!

and the loss of overloading is in fact desirable.
In particular, if a program had the function:

	f(const int&);

and the function

	f(int&);

were added, the meaning of the program would change: the call

	f(i);

may suddenly allow 'i' to be modified yielding unexpected results.

The prinicpal disadvantage of disallowing overloading on int& and 
const int& is I think restricted to their use in operators,
since these are not conveniently renamed.

For named functions, why is transparency of semantically distinct
functions desirable?

I also remain confused about

	f(const volatile int&);
	f(volatile int&);

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------