>>just to FORCE everyone to have to specify which language version they're targeting?

There is a thought.

I see a lot of trouble from this proposal because the compilers and supplied libraries have a history of including extra things. Until quiet recently C++ headers would drop in C that nobody asked for. Personally, I was surprised to find that on Windows I could throw std::runtime_error.

At the end of the day a lot of code would break, because nobody is sure exactly what standard they are actually are using.

Is there a technical reason that would prevent the compiler from honoring a per-file pragma that allowed the developer to define how the code was expected to be interpreted by the compiler?

Haskell's GHC is doing exactly that. You can even mix and match pragmas for different extensions.

I find it terribly confusing. It means that Haskell is almost never something I can expect a lot from, but a weird combination of extensions changing to "non-standard" behaviours.

> It means that Haskell is almost never something I can expect a lot from, but a weird combination of extensions changing to "non-standard" behaviours.

I can't think of a weird combination of behaviors from extensions that would change semantics... maybe it's because I don't use that many extensions usually.

When I do they are related to type level programming and all they seem to affect is type inference.

Never confused me. In general, on a bigger project you'll have a bunch of approved extensions, and everything extra goes through very strict code review to see whether it helps more than it confuses.

In a strictly controlled project, fine. But working with three different open source extensions that all use a different setup gets confusing quickly.

Point being the same: Haskell as used is never quite standard Haskell.

> Point being the same: Haskell as used is never quite standard Haskell.

In practice I haven't found this true.

A different setup?

An example would be helpful.

I know Perl has done the same for quite a while now.

there are ABI incompatibilities between the C++98/03 STL and the C++11 and C++14 STLs.

That's unfortunate. I'm not too familiar with the intricacies of C++, but I assume you can't link multiple STL libs in a single binary?

Edit: Added a "can't" that was accidentally omitted...

I don't know whether you can, but it would be asking for trouble. Let's say you call function f in library L and get back a std::list, and then pass it to function g in library M, which linked to a different implementation of std:list. At best, that would lead to a crash.

POSIX mandates c89 and c99 commands. Extend that idea to c++ and the problem is solved.

Exactly - just add something equivalent to

    alias c99="gcc --std=c99"
    alias gc99="gcc --std=gnu99"
    alias c++11="gcc --std=c++11"
    alias g++11="gcc --std=gnu++11"

and so on to the compile distribution, and leave "gcc" and "g++" at their current defaults for legacy code. If the changes between the dialects are different enough to have compatibility issues, then it makes sense to actually treat them as different languages with different compilers.

Your c99 alias is unneeded:

  $ which c99
  /usr/bin/c99
  $ c99 --version
  gcc (Gentoo Hardened 4.9.2 p1.5, pie-0.6.2) 4.9.2
  [snip]