[BUG] Unable to override a non-ref-qualified virtual function declared in a Cpp1 library

[fedapo]

Describe the bug
Not sure whether this applies as a bug, but it is a design decision that affects the way Cpp2 interacts with existing libraries and might get in the way of a gradual migration from a Cpp1 codebase to Cpp2.
The scenario is a Cpp2 type (e.g. new migrated code) that inherits from a Cpp1 class/struct (e.g. legacy/library code) with virtual functions declared with no ref-qualifier.

To Reproduce
This is the code in the Cpp1 header file.

struct BaseClass {
    virtual ~BaseClass() = default;

    virtual std::string get_info() const {
        return "base";
    }
};

Then a Cpp2 type is defined.

DerivedClass: type = {
    this: BaseClass = ();

    get_info: (override this) -> std::string = {
        return "derived";
    }
}

Compiling this example gives this error:

/.../override_problem.cpp2:6:32: error: cannot overload a member function with ref-qualifier '&' with a member function without a ref-qualifier
    public: [[nodiscard]] auto get_info() const& -> std::string override;

The reason is clear: Cpp2 emits member functions that have either an lvalue ref-qualifier (const &, when declared with in this; &, when declared with inout this) or an rvalue ref-qualifier (&&, when declared with move this), yet the base class virtual function is declared with no qualifier hence the override is illegal and impossible. AFAIK no mechanism is available to declare the member function with no ref-qualifier to match the base class virtual function declaration and avoid the error.

Additional context
The choice of always using an explicit ref-qualifier for member function is rather recent, the code where I noticed the issue was working fine until a few weeks ago. I'm not sure whether I'm missing something major here and this is a non-problem; perhaps I'm just ignorant of another way to arrange this.
If the problem is real I see a few scenarios to treat it.

1. Ignore it. Inheriting from a base class of a C++ library that has virtual functions declared with no ref-qualifier just won't be possible. The case is rather common, though. It came out while trying to use a popular C++ testing library in Cpp2. Other examples abound, just think of any C++ GUI library, such as wxWidgets, or C++ frameworks, such as Poco.
2. Use another keyword from the ones available to "decorate" this in the member function declaration to avoid the ref-qualifier. I see some problem with the semantics in this case. For instance, say copy this is used, the meaning in common English of the keyword copy would be of no help and forward this is probably even worse. In this respect the choice of C/C++ to stay away from keywords when possible and use operators, such as '&', devoid of any baggage in meaning, posed less problems.
3. Introduce a new keyword. Most probably not a viable solution for design economy reasons.

That's it. Please, forgive me for having taken such a large text to describe it.

[JohelEGP]

The case is rather common, though.

Most common, I'd say.
Enough that this issue might be fixed
by never emitting a ref-qualified virtual function.

[jcanizales]

In C++, how is

struct BaseClass {
    virtual std::string get_info() const;
};

semantically different from

struct BaseClass {
    virtual std::string get_info() const&;
};

?

I guess I have the same question for the non-virtual case.

[fedapo]

Disclaimer: I'm writing down some thoughts I'm having around this topic. Please, express your corrections/extensions if any of these is incorrect or incomplete.

There is a variety of ways member functions can be declared in Cpp1 with respect to ref-qualifiers.
Here's a list with the Cpp2 counterpart, when available.

Cpp1	Cpp2	Ref-qualifier	Free-fuction counterpart
void foo() const		none (const)	void foo(widget const&)
void foo() const &	foo: (in this)	lvalue (const)	void foo(widget const&)
void foo() const &&		rvalue (const)	void foo(widget const&&)
void foo()		none	void foo(widget&)
void foo() &	foo: (inout this)	lvalue	void foo(widget&)
void foo() &&	foo: (move this)	rvalue	void foo(widget&&)

It appears that Cpp2, as of today, lacks a way to express some of these. This might be a Good Thing as the intent is to simplify.

@jcanizales I think there is no difference in semantics between the non ref-qualified member function and the lvalue ref-qualified one. They both have the implicit object type as an lvalue reference, or, put another way, they map to the same free-function counterpart. The difference is that (1) the non ref-qualified one cannot be defined as an overload when either of the ref-qualified ones is defined and (2) in the case of virtual functions (and this is the topic for which I initially created this ticket) overriding one (non ref-qualified) with the other (lvalue ref-qualified) is illegal; same goes for the other way around.
[EDIT]
There's another difference, (3) a non-const non ref-qualified function can bind to an rvalue reference while a non-const lvalue ref-qualified function cannot.

@JohelEGP's proposal to emit non ref-qualified virtual functions would solve the problem I posed, yet I find it odd to have this different treatment between virtual and non-virtual functions and I fear it might hide some other issue. For one it suffers a similar, specular problem when the base class defines an lvalue ref-qualified virtual function, though it can be argued this might be a rare case in current C++ libraries.

What I'd like to understand is whether it's feasible to save the usage of legacy Cpp1 libraries that require to inherit from their base classes and override member functions that have been defined in ways that might not be under Cpp2's control. All this preserving Cpp2's simplicity goal.
In short, the more I dig into the complexity of this in Cpp1 the more I feel Cpp2 is taking the correct approach. If only interaction with existing base classes could be saved...

[AbhinavK00]

Small thought: What if EVERY member function (virtual or otherwise) was emitted without ref-qualifiers? What consequences would that have?

[fedapo]

Small thought: What if EVERY member function (virtual or otherwise) was emitted without ref-qualifiers? What consequences would that have?

A function like foo: (move this, ...) is mapped to a Cpp1 function with an rvalue ref-qualifier, this is unavoidable. Once you have that you cannot overload that function with another non ref-qualified one. So, I'm afraid we need ref-qualifiers, which have been introduced for good reasons. It's coping with the pre-C++11 non ref-qualified functions that is problematic.

[AbhinavK00]

I was under the impression that move this functions were supposed to be destructors. Clearly I was wrong but what I said before was just food for thought.

[JohelEGP]

operator=: (move this); is the destructor.

Not all non-static member functions need to lower with ref-qualifiers.
It's only those with a (move this) overload that need to.
So that could be an alternative fix.
If a Cpp1 base class has a ref-qualified virtual member function to be overridden,
in the Cpp2 derived type you can use a private 𝘧: (move this, …) function
to trigger the actual 𝘧: (override this, …) function to lower ref-qualified.
This is similar to how you disable assignment: #468 (comment).

[fedapo]

Not all non-static member functions need to lower with ref-qualifiers.
It's only those with a (move this) overload that need to.
So that could be an alternative fix.
If a Cpp1 base class has a ref-qualified virtual member function to be overridden,
in the Cpp2 derived type you can use a private 𝘧: (move this, …) function
to trigger the actual 𝘧: (override this, …) function to lower ref-qualified.

Interesting. This sounds promising!
Would you still restrict this rule to virtual functions? Not that it matters for the problem initially raised. I'm trying to get an idea on how it would work.
Thanks!

[JohelEGP]

Yeah, that works regardless of virtual or override.

[AbhinavK00]

So there's the solution!

[hsutter]

In the meantime, it seems like we want to address this compatibility issue, and the simplest way to unbreak this is to not emit &-qualifiers on virtual functions.

That may well even be the right long-term fix, because ISTM that Cpp1 ref-qualifiers inherently don't make sense for virtual functions... those qualifiers apply to this and they express control over value semantics, whereas virtual functions and this value semantics don't mix. Right?