On Mon, Aug 1, 2022, at 06:16, Frederick Virchanza Gotham via Std-Proposals wrote:
> 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.

 Fair enough, one thing I observe in the real world is nobody has a good way to track files/libraries compiled with different incompatible changes. As such before I can consider anything that requires a compile flag is you either need to show that for all implementations and ABIs that any combination of code and flags can be mixed and matched and everything works.

Alternatively you need go standardize some sort of system compile flags system database so that a library that needs this flag will never build on a system without it, or something like, just the obvious problems I can see with that would take me several pages to write (and there are people on this list who understand that problem better than me who i'm sure can think of many more objections). If you can make it work anyway I guess you can do that.