> 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.

see the object hierarchy A, B, & C
https://godbolt.org/z/qjbx5Wqr5
make sure to read both Foo(A& a) { a. ...} & main() { C c; ...}

//'c' is not commutative across .Fun1() & .Fun2() & .Fun3()
c.Fun3().Fun2().Fun1();

//This is how a compiler reads a call chain
( (( c.Fun3() ).Fun2()) .Fun1() );
// --------
// --------------
// -------------------

//aka auto unnamed;auto unnamed;auto unnamed:
auto& unnamed1 = c.Fun3();
auto& unnamed2 = unnamed1.Fun2();
auto& unnamed3 = unnamed2.Fun1();
//you don't know.care what the unnamed are, if they are of same type and if
they are even the same instance


On Fri, Apr 7, 2023 at 2:51 PM Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Yes, contrary to what I first said, this is not a case that would get
> optimized.
>
> This proposal only prevents re-virtualization in call chains, which
> means you are free to write:
> devirtualized.a().b().c()
>
> instead of:
> devirtualized.a()
> devirtualized.b()
> devirtualized.c()
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>