🚀 go-pugleaf

In article <27BFE464.3FB9@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to craig@gpu.utcs.utoronto.ca (Craig Hubley):
>>I want the compiler to override the base class's function wherever
>>a derived function is defined that
>>	- accepts a parameter list convertible to one the base would accept
>>	- returns a value of a type convertible to one returned by base
>>my definition of "convertible" is quite restrictive here:  pointers to 
>>derived classes, which are legal substitutes for pointers to bases.
>
>In the abstract, I like this idea.
>
>On the other hand, the fact that this rule has not existed in the
>language to date means that currently unrelated functions, which are
>separated perhaps by several layers of derivation, would suddenly
>become alternative implementations of the same virtual function.
>
>Also, member functions that are separately legal would suddenly
>conflict with each other if they were both valid overrides for a
>virtual function in a base class.
>
>If C++ were still being designed, or were still in use only internally
>to AT&T, this change might have a chance.  But I think it's too late.
>Code that has already been written depends on all definitions of a
>given virtual function being identical.  For the ANSI committee to
>change this significant aspect of the language would be irresponsible.

My original post which started part of this thread asked only for the
second of Craig's requests (including references as well as pointers) -- that
	Given base class B and derived class D and virtual functions
		virtual B* B::f();
		virtual B& B::g();

	that the derived class be able to supply its versions of these
	virtual functions as

		D* D::f(); // these currently illegal
		D& d::g();

	instead of
		B* D::f(); // these currently legal
		B& D::g();

Either (but not both at once) returning D* or returning B* would be legal.
Since returning D* is now illegal, no code would break or have its
semantics changed.

I realize that this proposal does not address all the concerns
of other posters (e.g. Craig Hubley) related to conversions on function
parameters.  However, in my (couple of years) of C++ use being able to do
what I propose for return types would have reduced the number of helper
functions and lines of code significantly (10s of percent), whereas the
restrictions on function argument types have rarely been a problem for me.
I'd be interested in real (I can invent by own) examples where allowing 
conversions on function arguments caused a significant simplification.

David R. Cok
Eastman Kodak Company  cok@Kodak.COM