On Fri, Nov 25, 2022 at 12:00 AM Mehmet Kayaalp via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> [...] I fail to understand why we don’t come up with a version “pragma”
> for each piece of code, indicating which compiler version should compile it
> to produce the intended assembler code (instead of compiling the entire set
> of codes with a single compiler). What would be the unsolvable problem for
> linkers to link those assembler codes produced by different versions of
> compilers?
>

You can already compile totally different TUs with different language
modes, and plenty of people do. Heck, you can compile some of your project
as *C* code and then link it with C++ — not a problem! (Nobody would be
able to use libopenssl, libpng, zlib, libcurl,... if this weren't already
the case.) And you don't need any #pragma to do that, either.

Alternatively, if you're suggesting that we use a #pragma to mix
language standards *within* the same TU, then you'll need to explain what
should happen with things like

    #pragma magic c++20
    #include <compare>
    struct S { auto operator<=>(const S&) const = default; };
    #pragma magic c++17
    int main() {
        S s;
        return s < s;
    };

Should `s < s` be ill-formed here, because according to C++17 `struct S`
has no `operator<` in scope? Or should we somehow bring down the `<=>` from
C++20?
Or again:

    #pragma magic c++20
    #include <string>
    #pragma magic c++17
    int main() {
        std::string s = "hello world";
        return s.starts_with("hello");
    };

Should the last line of `main` successfully compile because name lookup
finds the `starts_with` from C++20's <string> header? Or should it fail to
compile because *this* std::string object is a "C++17" std::string object?

There's simply no way to make a #pragma that works the way you (might) want
it to work.

(Btw, the above aren't even the subtle problems; there are far subtler
problems one could make up. The above are two of the really
*easy-to-understand* problems.)

HTH,
Arthur