C++ Logo

std-proposals

Advanced search

Re: [std-proposals] this return type

From: Jan Schultke <janschultke_at_[hidden]>
Date: Sat, 8 Apr 2023 02:35:57 +0200
>> This proposal only prevents re-virtualization in call chains, which
>> means you are free to write:
>> devirtualized.a().b().c()

> It can not prevent re-virtualization in call chains
> It would be wrong to break the polymorphic mechanism just because it is in a call chain.

But why would that not be possible? I see how the Compiler Explorer
example breaks the call chains down into these temporary references
that are re-virtualized, but we can prevent that.

A "this" return type guarantees that not only the return type is the
same as the type of the called object, but the returned reference also
refers to the called object. It acts like std::integral_constant in
the sense that the type conveys value information.

> auto& unnamed1 = c.Fun3();
> auto& unnamed2 = unnamed1.Fun2();
> auto& unnamed3 = unnamed2.Fun1();

With a "this" return type, we can turn this sample into:

auto& unnamed1 = c.Fun3();
__builtin_assume(std::addressof(unnamed1) == std::addressof(c));
auto& unnamed2 = unnamed1.Fun2();
__builtin_assume(std::addressof(unnamed2) == std::addressof(unnamed1));
auto& unnamed3 = unnamed2.Fun1();

Although we would have to guarantee that not only the address is the
same, but also that the dynamic type was not altered by ending and
beginning the lifetime of c in any of the member functions.

Received on 2023-04-08 00:36:10