When class C implements I with method I f(I x), why is there freedom in return type, but not in argument?

Question

Consider this code:

public interface I { I f(I x); }

public class C1 implements I { public I  f (I  x) { return null; } }

public class C2 implements I { public C2 f (I  x) { return null; } }

public class C3 implements I { public I  f (C3 x) { return null; } }

public class C4 implements I { public C4 f (C4 x) { return null; } }

public class C5 implements I { public C1 f (I  x) { return null; } }

If you try to compile, you will see that C3 and C4 fail:

C3 is not abstract and does not override abstract method f(I) in I

C4 is not abstract and does not override abstract method f(I) in I

So I am allowed to specialize the return type, but the argument must remain abstract. In other words, I am allowed to specify the return type of the method (it may even be C2 in the definition of C1 — I can mix), but I cannot restrict the arguments, so f is always polymorphic on the input.

• What is the logic behind this situation?
• Why is it not allowed to specialize the argument?
• Why is it allowed to specialize the return type to the type of this or keep it abstract?
• Why is it allowed to specialize the return type to another implementation of the same interface? (Like in C5.)

 

---

P.S. That other question about covariant return obviously does not cover all the points above, if any.

• I am not asking "what", I am here asking "why".
• Yet again, my question here is about relation of a class to an interface, not subclassing in general (even if we do consider implementing an interface a case of subclassing, which is an open, though philosophical, question in itself).
• And yet once more, that question is general, while my question is specific to Java.
• Finally, the wording is completely different. I do not even know where this "covariant" comes from. Like in "vector" covariant? "Functor" covariant? If there is deep analogy, it has got to be explained.

So please kindly reopen.

Answer 1

Let's see.

public interface I { I f(I x); }
I[] all = { new C1(), new C2(), new C3(), new C4(), new C5() };
I argument = availableArguments[Random.nextInt(all.length)];
I c1 = new C1();
I c2 = new C2();
I c3 = new C3();
I c4 = new C4();
I c5 = new C5();

public class C1 implements I { public I  f (I  x) { return null; } }
I result = c1.f(argument); // ok; argument is an I, an I is returned

public class C2 implements I { public C2 f (I  x) { return null; } }
I result = c2.f(argument); // ok; argument is an I, returned C2 can be assigned to I

public class C3 implements I { public I  f (C3 x) { return null; } }
I result = c3.f(argument); // would fail: argument is not of type C3 as required

public class C4 implements I { public C4 f (C4 x) { return null; } }
I result = c4.f(argument); // would fail: argument is not of type C4 as required

public class C5 implements I { public C1 f (I  x) { return null; } }
I result = c5.f(argument); // ok; argument is an I, returned C1 can be assigned to I

Answer 2

The story goes some way here.

Interfaces are a kind of classes.

It is not immediately obvious, but another fitting name for an "interface" of Java would be an "abstract class". That interfaces are in fact a subset of classes is of course questionable, so we should question it separately. If we find out that it is false, we should revisit this answer as well. But for now, let us assume that it is true.

We also have to assume that Java "classes" are a kind of types. This can, again, be questioned in itself, elsewhere. If we assume this, we can draw some insight from the theory of types. What we need specifically is the notion of subtyping. In short, that C is a subtype of I means that when you have a variable of type I in your code, you can replace it with that of type C and some part of your code will still work.

Side notes:

• Of course, you can never actually create a value of type I, since I is an abstract class — it has no definition; but you may consider a value of which it is known only that it is of some class that implements I.
• Which part of your code will work afterwards depends on the exact definition of subtyping, of which there are some — read on to find out which definition Java is using.

Argument and return types are fundamentally distinct with respect to subtyping.

This is where covariance and contravariance enter. These terms have come to computer science from physics and through category theory. That seems far fetched, but take a look at how subtyping plays with functions and you are sure to see how it all aligns.

Here is an example. It is a bit involved, so take a pen, some paper and check it for yourself.

1. Take a function f: Integer -> Boolean. It takes a number and returns a truth value. For instance, let it tell us whether the number is even.
2. We can subtype this function in the following 2 ways:
   1. Surely, if it works on any number, it will work on primes, so we can use the same function like this: f -- specialize argument --> f1: Prime -> Boolean. (3 still gives False, 2 gives True. All is good.) Where the latter works, the former would work too. So, f1 is a subclass of f.
   2. It is also true that we can use the same function like this: f -- generalize result --> f2 = Integer -> Byte. (We would simply convert True to 0x01 and False to 0x00.) Where f2 is needed, f will do. So, f2 is a subclass of f too!
3. See that Prime is a subclass of Integer: you can still add, multiply and invert them, but you can also use them for cryptography.
4. See that Bool is a subclass of Byte: you can still store it in memory, but you can also store an array of Bool packed, in 8 times smaller memory than an array of Byte.
5. Now observe: when we move the argument of f in the direction of subtyping (specialize it), the function also moves in that direction, while the result type has to be moved in the opposite direction (get generalized) for a function to be subtyped. The reader may actually draw this and see how it aligns with the definition of vector variance in physics.

This is of course not a real proof, just some hand waving. I have no real proof. Do question!

Subclassing in Java aligns with a certain "subtyping" partial order on types.

The famous Barbara Liskov's subtype requirement is one way to define the subtyping relation. That particular definition is called "behavioural" subtyping, and it opens a deep rabbit hole of undecidability which may or may not be of a concern for us. (So again we have a question.) It is here we have to take it on faith that Java is faithful in its rendition of behavioural subtyping. (Habitually question it. One possible way to drive a wedge is look attentively at the relationship between subtyping and inheritance.)

So let us suppose that inheritance is compatible with subtyping in Java. What does it give us?

A function with subtyped argument is not a subtype of the original.

That is, a method of a subtyped item is not a subtype of the original.

So suppose you have this function that performs RSA encryption and it just needs one prime, f: Prime -> X. If you put this function in situation where a non-prime argument can be given to it, then it will likely create a message that is encrypted very weakly. You introduced a bug. So, while you can always put a prime to a place where a number is expected, you cannot put a method invocation that requres a prime to a place where a mere number will be given to it as an argument.

But the object the method is invoked from is itself an implicit argument, you may ask, so subclassing should be forbidden altogether! Indeed, suppose I define a method of Integer that computes a possibly weak RSA key and subclass Prime from this Integer. Now the same method, with the same evident types, computes a strong RSA key, because its implicit argument has been subtyped — and, if I want strong keys, I cannot blindly replace Integer with Prime.

This is the first big question of our fantasy adventure.

(I am very fuzzy at this point.)

Java tries to make sure an implementation of a method is always a subtype of its definition.

One way of ensuring that is to only allow subtyping the result. (Is it the only way? Right way? Is it actually safe?)

For some reason, Java does not try to give type errors at use site, but simply forbids the definition.

What is the reason for that is our big question number two. Possibly because it wants to align subtyping and inheritance.