Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!lexvmc.vnet.ibm.com!schweitz
From: schweitz@lexvmc.vnet.ibm.com ("Eric Schweitz")
Newsgroups: comp.lang.c++
Subject: Re: typesafe downward casting and contravariance
Message-ID: <9104111419.AA08217@ucbvax.Berkeley.EDU>
Date: 11 Apr 91 14:07:21 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 63

cok@islsun.Kodak.COM (David Cok) writes:
>
>The case you give is complicated by the automatic conversions among
>numeric types.  It isn't even proposed by me as something allowed under
>"contravariance on function return type", which sticks with derived classes
>returning X*, base classes returning Y*, and X being inherited from Y.
>The case you have, assuming everything is user defined rather than numeric
>types, is simple overloading, already present in C++, and succumbs to the
>rules for overload resolution -- the context of the function call is
>ignored, only the parameter types are used:
>
>What I mean by contravariance is this:
>
>class Base {
>        ...
>        virtual Base* clone();
>};
>
>class Derived {
>        ...
>        virtual Derived* clone();
>//              ^^^^^^^^  C++ currently requires this to be a Base*
>};
>
>I have a previous post on implementation which I'll send by e-mail to
>any interested person.
>
>David R. Cok
>Eastman Kodak Company -- Imaging Science Lab
>cok@Kodak.COM

Sigh. Sorry for my poor example. It seems to have clouded rather than
clarified my point.  I should have wrote:

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

or even better just used something generic:

   base func (base);
   derived func (base);
   morederived func (base);

I apologize for my poor example (which, as pointed out wasn't "contravariant").
(Gosh, I hate when my fingers think for themselves!)

Please note however, that I was NOT referring to "automatic conversion of
numeric types."  "Automatic conversion" is and can be understood and wasn't
the real issue.  I just thought that someone was suggesting ``Surprise'' con-
versions which could be harder(?) to understand.

After looking at your implementation again, it seems that you did in fact
disallow what I was suggesting by proposing that only virtual functions
returning type "base*" or "base&" (in the base class) be contravariant.
(Does this impose the restriction
that sizeof(derived*) == sizeof(base*)?  Note: This isn't an attack,
I'm just curious. :-))

So I guess my original fear was without grounds (maybe?).

Thanks,
Eric