🚀 go-pugleaf

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