Mirror of forum.nim-lang.org

8844 :: Nim 2.0 and backwards compatibility

• didlybom (orginal) [2022-01-26T09:04:18+01:00] view original

  Hi,

  I’d like to understand how nim 2.0 will (or will not) handle backwards compatibility.

  As nim has become more and more popular, more and more nim packages have been developed. Will all those community packages stop working when nim 2.0 comes along? Or perhaps there will be some way to import nim 1.x packages into a nim 2.x codebase?

  What is the plan for that?

---

• haxscramper (orginal) [2022-01-26T09:38:50+01:00] view original

  Will all those community packages stop working when nim 2.0 comes along

  Unlikely, except in cases where they depend on the explicitly deprecated functionality. Nim 2.0 will mostly focus on the things described in the roadmap https://github.com/nim-lang/RFCs/issues/437

  Or perhaps there will be some way to import nim 1.x packages into a nim 2.x codebase?

  From which you can see there is not a lot of fundamental changes, and treating nim 2.0 as a completely new language that you need to "import packages to" is unnecessary.

---

• Araq (orginal) [2022-01-26T09:51:58+01:00] view original

  The plan is still evolving but here is my idea:

  • Code either still compiles or it doesn't. No secret subtle changes at runtime. (However, this probably assumes that you're already using --gc:orc successfully).
  • If the code doesn't compile you need to change the import list. It's hard to automate this because once you changed the import list, you need to review the places where the compiler produces error messages and investigate how to change the code correspondingly.
  • Source code can be written in a style so that both Nim 1 and 2 can compile it, without too many when statements. There should be a set of guidelines about how to accomplish that.

  I'm very skeptical about tool support -- I'd like you to review the code when the compiler complains, not follow some recipes, a tool can only automate the recipes.

---