On Saturday, 30 July 2022 11:56:03 PDT Frederick Virchanza Gotham via Std-
Proposals wrote:
> Like this:
>
> Mammal
>
> |________ Cow
> |
> |
> |________ Sheep
> |
> |
> |________ Canine
> |
> |________ Dog
> |
> |________ Wolf

Fox is missing. This is important, because if you're going to talk about "new
way of speaking", you have to answer "what does the fox say?"

Jokes aside, you seem to have a too simplistic view of what a vtable is.

> 09: int main(void)
> 10: {
> 11: Wolf my_wolf;
> 12:
> 13: virtual Wolf::Speak = New_Way_Of_Speaking;
> 14: }

A vtable may include multiple locations for the same virtual function, when
multiple inheritance is involved. Would the above write to all of the
locations in the Wolf vtable?

If so, how do you propose the compiler write to the vtable locations that
require thunks to adjust the this pointer? You gave a rule of what you
proposed as replacement functions, but you didn't say whether a pointer to
function variables were an allowable solution, or whether only directly-named
functions. If it is the latter, the compiler can generate the thunks on
demand. Allowing variables makes your feature suggestion unimplementable, thus
dead on arrival.

Thunks come in two groups:
 * adjusting the this pointer (by a fixed value or a dynamic one, in the case
   of virtual inheritance)
 * adjusting the returned pointer, in case of covariant returns

Please make sure you've understood all cases.

In particular, you'll want to address the defect MSVC has been carrying for a
quarter century on the size of pointer to member functions and just what
exactly needs to be adjusted.

Other questions your paper needs to address:
* can you update the table while the constructors are running?
* is devirtualisation allowed?
* how does the final attribute modify this, if at all?

And you really, really need to address motivation. Why do we need this? What
other solutions could solve this problem? Why aren't they sufficient, or as
convenient?

Have you looked into virtual variables?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering