On Sun, Jul 31, 2022 at 2:57 PM Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:

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


This is a minor technicality. It's like saying that cars manufacturers
like Honda have nothing at all to do with tyres -- even though every
car gets 4 tyres.

There was a time when people said "C++ doesn't know anything about
threads", and we changed that to reflect reality.

The C++ Standard already acknowledges the existence of a compiler and
how it should behave (e.g. issue a diagnostic), and so it wouldn't be
a big deal for the Standard to say that we can specify options to the
compiler (since we're all doing that already anyway).


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


The real world is already like this though. "-pthread" is just one
example. Part of the evolution of the C++ Standard is observing how
people in the real world are working with the Standard as it changes.