On Fri, Nov 25, 2022 at 12:00 AM Mehmet Kayaalp via Std-Proposals <std-proposals@lists.isocpp.org> 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