[jakear]

> If you were relying on some edge case and/or buggy behaviour which is now fixed, try if --useVersion:1.0 gives you back the results you expect to see. If that doesn’t work and you need the old behaviour, please open an issue in our bug tracker and we will try to make it work in future bugfix releases

So useVersion doesn't simply checkout the old codebase, but they still promise to maintain all prior version's bugs? Seems like a losing battle to me... why not just tell people relying on version 1.0 behaviour to use version 1.0 and create tooling to make sure switching between versions is easy (a. la. nvm)?

[_0ffh]

My impression was that using "choosenim" switching between versions is easy already, but I might be missing something.

[rayman22201]

choosenim is still supported :-)

The idea is more like the gcc -std flag (gcc -std=gnu++11 for example). to emulate certain versions to ease upgrading.

[jakear]

Do you think the gcc -std flag would exist if every distribution of gcc included a command to easily download alternate versions and swap them out depending on project configuration? -std seems more like a bandaid around a difficult install/config than a feature, in my opinion.

Obviously nim is free to make implement whatever options they want, but it seems to me like every second spent triaging/fixing/etc bugs about not properly maintaining broken things (not to mention the end user time spent experiencing them and debugging them!) is time that could be better spent improving the language.

[tomsmeding]

Yes, the -std flag would definitely still exist: the thing being changed by that flag is a lot of stuff in the parser, some stuff in the standard library, and some semantics bits further towards the backend, but at some point the versions converge and go through the same optimisation pipeline. A pipeline that definitely has seen improvements in more recent versions, so it's totally worth it to use a new compiler with an old language standard on old code: it might very well produce a faster executable. Just using an older compiler would also revert back to the old performance.

Additionally, a C/C++ compiler in an older standard mode would disable certain features, of course, but not completely: it's still able to give diagnistics in the vein of "this thing isn't valid with the current version setting, but it would be valid in C++17", for example. That's useful to a programmer.

[marvy]

Also useful in the other direction: your code works now, but in C++17 that's a keyword so you'll have to rename it.

[yellowapple]

A newer GCC will likely have better optimizations, better safety checks, or what have you that would benefit old codebases using older versions of C's syntax. Similar deal with a newer Clang/LLVM, for that matter.

That is, if we had a GCC version manager that worked the same way things like choosenim or rustup or pyenv or rvm or what have you work, I can guarantee you GCC will ship with an -std flag, because you can bet someone needs to compile a C89 codebase and wants the latest and greatest compiler smarts to do it. Same deal for Clang, or Visual Studio, or `zig cc`, or whatever.

Great example of this (that I just had to deal with this week, lol) is Wine, which mandates C89-compliant code, and yet absolutely benefits from any compiler optimization improvements introduced with newer versions of GCC.

[rayman22201]

Depends on your organization more than tooling. Even if you have the tool, your orgs security policy may not allow using it.

You may not have an environment that allows switching compiler versions for other reasons.

Even Rust has a similar concept that allows gating of features like this. They call it "editions".