Re: Overring function and its returned type

["Peter C. Chapin" <pcc482719@gmail.com>]

On 11/09/2012 02:57 PM, sbelmont700@gmail.com wrote:

> More generally, you are talking about 'covariant return types', which
> is a feature only a handful of languages support (notably C++).
> IMHO, i don't really see the need for it; a type is either a child
> (and matches the parent, as in P3) or it doesn't and it's not (as in
> P2).

I realize this thread is dead but I found it interesting and looked into 
the topic a little. It is true that C++ supports covariant refinement of 
return types as does, for example, Scala. In theory it should also be 
type safe to allow contravariant refinement of parameter types. Scala 
does not allow that... which surprised me considering Scala's reputation 
of having a very expressive type system.

I talked with some people in the Scala community and it turns out the 
reason for the restriction is related to overload resolution and 
ambiguity. In the case of C++ there is no overloading on return types 
and thus allowing covariant refinement of return types is straight 
forward there. However, since Ada does allow overloading on return 
types, complications arise.

To illustrate let me start with a simple derivation class:

package Vehicles is
   type Vehicle is interface;
   type Car is abstract new Vehicle with null record;
   type Sports_Car is abstract new Car with null record;
end Vehicles;

Now consider:

with Vehicles;

package Animals is
   type Animal is interface;
   function F(A : Animal) return Vehicles.Vehicle'Class is abstract;
   function F(A : Animal) return Vehicles.Car'Class is abstract;

   type Cat is abstract new Animal with null record;
   overriding function F(C: Cat) return Vehicles.Sports_Car'Class is 
abstract;
end Animals;


Suppose covariant refinement of return types was allowed in Ada. In that 
case which F is being overridden here? Since Sports_Car <: Vehicle and 
also Sports_Car <: Car the overriding is ambiguous.

I suppose rules could be written to clarify these things but it probably 
wouldn't be worth the additional language complexity.

Peter