In article <1993Jan1.161813.1592@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>[...]  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!
>

But you can't do this with (i.e., rename) constructors.

I wish to examine the impact on the language of the following
proposal. I'm not suggesting this proposal be adopted.

Proposal:

1) for the purposes of computing the signature of a function,
the symbols 'const', 'volatile' and any trailing '&' are ignored.

Thus, all the following functions have the same signature:

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

2) As usually, attempting to define two functions with the same
signature results in a duplicate defintion.

3) For the purpose of overload resolution, the 'type' of
the actual argument is similarly reduced by eliminating
'const', 'volatile' and '&'.

As a consequence, 'trivial' conversions can be ignored during
overload resolution.

4) After a single function has been unambiguously selected
as the best match, then, and only then, are the
trivial converions considered to determine if the call is legal.

For example if 'void f(int&)' is the best match for a call f(3),
it might be determined that an 'lvalue' is required and the call
is illegal. Such considerations are explicitly excluded from
the determination of the best match.

5) In addition, at least the declarations involving call by value
totally ignore the 'const' or 'volatile' specifiers, so that
in the following example, the declaration matches the defintion.

 void f(int);
 void f(const int i) { ... }

In particular, the 'const' here is not included in the mangled
name because it is not relevant in a adeclaration.
The same rule should apply to the return of values I believe.

Principal Consequence.
---------------------

It is not possible to use the 'lvalue'ness of an argument
for matching purposes, and it is not possible to define two functions

 f(int);
 f(int&);

one of which might modify its argument and one of which wont.
I believe this is correct: if two such functions are desired,
their semantics are different, and they should be given
different names, so that the semantics of the program
are explicit.

The modified language continues to support families of
functions with the same name operating on different types

 sin(int);
 sin(float);
 sin(complex);

which are intended to have similar semantics so that transparency
is desirable. It also supports accidental overloading:

 draw(gun);
 draw(picture);

where context may indicate the meaning, and which it is desirable to allow
for pragmatic reasons.

There is no question that this proposal will break many C++ programs.
It is intended to. The claim is these programs are poorly designed,
and are better off rewritten. (breaking C++ programs is of much
less importance than breaking C ones IMHO. No C programs should be
broken by the above modifications I think.)

Comments?

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

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.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

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 ------------------