Covariant return type is not recognized

Question

For some reason, up-to-date versions of both GCC and clang do not recognize return type covariance in this particular scenario. The error message is misleading:

error: return type of virtual function 'foo' is not covariant with the return
     type of the function it overrides ('derived *' is not derived from 'base *')

Here is the code:

class base
{
private:
  virtual base * foo() = 0;
};

template< class T >
class foo_default_impl : public virtual base
{
private:
  T * foo() override { return nullptr; }
};

class derived : public virtual base, private foo_default_impl< derived >
{
};

int main() {
  derived d{}; // error: return type of virtual function 'foo' is not covariant with the return type of the function it overrides ('derived *' is not derived from 'base *')
  return 0;
}

`foo()` needs to return a `foo_default_impl *`, not a `T *`. — Khouri Giordano, Jun 14 '17 at 15:22
did previous versions compile your code? I wonder if this is because `derived` is not yet a complete type when it is passed to foo_default_impl : http://eel.is/c++draft/class.derived#class.virtual-8 — marcinj, Jun 14 '17 at 15:26
@KhouriGiordano : Why? In the particular case we are considering, `T` will be `derived`, and `derived` is publicly derived from `base`. — Martin Bonner supports Monica, Jun 14 '17 at 15:28
@KhouriGiordano: I've just followed the link from marcinj, and see why you said that. — Martin Bonner supports Monica, Jun 14 '17 at 15:30
..... but I am not sure if in this case derived is actually in-complete at that point — marcinj, Jun 14 '17 at 15:30
@marcinj : I think you should write that up as the answer. The problem is `foo_default_impl::foo` is breaking the rules (return type is neither complete, nor `foo_default_impl`). The error message could be better. — Martin Bonner supports Monica, Jun 14 '17 at 15:32
@marcin : It can't be complete. One of the things about a complete type, is that you know it's size. You can't know the size of a class until you know the size of its base classes. We are currently trying to create one of those base classes! — Martin Bonner supports Monica, Jun 14 '17 at 15:35
Possibly you should apply the [Curiously Recurring Template Pattern][https://en.m.wikipedia.org/wiki/Curiously_recurring_template_pattern] — Khouri Giordano, Jun 14 '17 at 15:56
There may be no benefit in returning a covariant type `T *` in my case, so I will be sticking to just returning `base *`. The point of the question was mostly not "how do I overcome the issue" but "what am I doing wrong". — Volodymyr Lashko, Jun 15 '17 at 06:41

StoryTeller - Unslander Monica · Accepted Answer · 2017-06-14T15:40:52.840

Here's the thing. While to us it may appear that the compiler knows everything it needs to know about the types in question, the standard says otherwise.

[temp.arg.type/2]

... [ Note: A template type argument may be an incomplete type. — end note ]

[basic.types/5]

A class that has been declared but not defined, an enumeration type in certain contexts ([dcl.enum]), or an array of unknown bound or of incomplete element type, is an incompletely-defined object type.46 Incompletely-defined object types and cv void are incomplete types ([basic.fundamental]). Objects shall not be defined to have an incomplete type.

[class/2]

A class-name is inserted into the scope in which it is declared immediately after the class-name is seen. The class-name is also inserted into the scope of the class itself; this is known as the injected-class-name. For purposes of access checking, the injected-class-name is treated as if it were a public member name. A class-specifier is commonly referred to as a class definition. A class is considered defined after the closing brace of its class-specifier has been seen even though its member functions are in general not yet defined. The optional attribute-specifier-seq appertains to the class; the attributes in the attribute-specifier-seq are thereafter considered attributes of the class whenever it is named.

The text in bold paints the simple picture that the compilers in question treat the type parameter T as an incomplete object type. It's as though you only forward declared it, like so:

class derived;

They cannot deduce that this forward declaration is a class derived from base. So they cannot accept it as a co-variant return type in the context of foo_default_impl. Like was pointed out by @marcinj in the comments:

[class.virtual/8]

If the class type in the covariant return type of D::f differs from that of B::f, the class type in the return type of D::f shall be complete at the point of declaration of D::f or shall be the class type D.

Since T is neither complete, nor is it foo_default_impl<T> itself, it cannot be a co-variant return type.

I agree. Part of the error message _('derived *' is not derived from 'base *')_ made me think that compiler got confused with this code. — Volodymyr Lashko, Jun 14 '17 at 15:44
The point made in the comments above -- that `sizeof(complete_type)` must work -- also makes it clear why `derived` cannot be complete at that line. We are defining a base of `derived`, how can we know how big `derived` is? — Yakk - Adam Nevraumont, Jun 14 '17 at 19:05

Covariant return type is not recognized

1 Answers1

Linked