On Sun, Jul 31, 2022 at 6:03 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sun, Jul 31, 2022 at 5:43 AM Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >>
> > > Start with a new syntax, because right now the vtables are in read-only
> > > memory. You must somehow signal the compiler that they should be modifiable.
> >
> > To be clear: you must signal in code.
> >
> > Compiler options are out of scope in this list. If you just want a compiler
> > extension, make a suggestion to the implementations you care about.
>
>
> Well then we should discuss whether this should change.

Um... no. Absolutely not.

C++ is a *language*; the details of how you call a particular program
to process that language are out of scope for the language itself.
Those details are not unimportant to the process of developing that
language, but they are ultimately not part of what C++ is.

We already have problems with compiler switches making C++ code
non-portable (compiler-specific features) or non-interoperable (if
library X is built against certain switches, you must build your
application with those switches to use it). We don't want to encourage
this with special language features that only work via compiler
options.

If a language feature is so burdensome to use, imposes so much of a
performance penalty that you need to have a sanctioned way to shut it
off, then maybe it shouldn't be in the language to begin with. And
yes, I can point to a couple of features where the ship has de-facto
sailed on that point. But the standard should not *encourage* that
kind of thing.

> By the way, C++ programmers writing code today in 2022 have to use
> some compiler options to get their standard-compliant code to compile.
> For example if I want to use "std::thread" in the GNU compiler (g++)
> then I have to compile with "-pthread".

But that's not part of the *language*. That didn't happen because the
standard said that it must. It happened because GCC wants it that way.