On Mon, Aug 1, 2022 at 3:11 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> Unless you're aiming at getting negative chance of getting your proposal
> through, I suggest you decouple compiler options from it.


I don't actually have a use case for my "proposal". <-- they're scare quotes

I can't think of a good use off-hand for being able to modify v-tables
at runtime.
This is all just a thought experiment -- which I believe is needed to
keep discussion
lubricated.
We can get really comfortable with ideas like "object-orientated" and
"polymorphism",
and how they apply to C++, but irrespective of how comfortable we ever become, I
think we should always be throwing out wild and wacky ideas just to get people's
creative juices flowing.

In the year 2070, the idea of a 'class' might be quite similar to what
it is today. But
then again, someone might come up with a mad idea that nobody had fathomed --
and maybe even everyone will baulk at it at first -- but our previous ideas of
polymorphism might begin to seem very limited when we explore the new idea.

If discussion about adding compiler options to the Standard opens up
new doors of
creativity in people's minds, and brings forth new strange ideas, then
let's talk about it.
I want to evaluate weird, odd, strange ideas and see where it takes us
-- even if it's
talk about editing v-tables at runtime (with atomic pointers in
writeable memory).

Can anyone reading this post right now think of a very good use for
standardised compiler
options?

P.S. In a previous post a day or two ago, I shared some code that
malfunctioned when
compiled with -O2 or -O3 (however it worked fine with -O1). Today I
was tinkering with it
more and I got it to work properly at ever optimisation level by
simply changing the v-table
pointer from "void *" to "void volatile *".