Mirror of forum.nim-lang.org

5372 :: I dunno what's so hard to understand about it.

• Black_Fox (orginal) [2019-10-19T12:26:29+02:00] view original

  Please, can we, common and not-that-brilliant people, get a better explanation for https://github.com/nim-lang/Nim/pull/12447?

  In my understanding, from that PR it seems that the project leader has a veto right over community. After some discussion, where a proper solution is outlined, the applied solution is to revert from one incorrect state back to previous incorrect state. Maybe it's the lack of sleep on my side, but how did that PR solve anything?

---

• Libman (orginal) [2019-10-19T17:13:05+02:00] view original

  the project leader has a veto right over community

  I just want to emphasize this point. It's Araq's toy, he can do whatever he wants. Choosing to use his Nim is our voluntary choice. If someone's not happy, they can create a fork.

---

• Araq (orginal) [2019-10-19T17:57:16+02:00] view original

  The proper solution is to deprecate csize and that's what we will do. Breaking code nilly-willy wasn't required in order to fix/improve the situation and so that's why it was reverted.

  And yeah, sometimes I have the veto right but it's quite rare that I use it. I also don't understand the downvotes, it's the "Nim devel" version, a mistake was made and it was corrected.

---

• Black_Fox (orginal) [2019-10-20T12:14:26+02:00] view original

  It's Araq's toy, he can do whatever he wants.

  And yeah, sometimes I have the veto right but it's quite rare that I use it.

  Alright, then I understand. I actually don't know how this goes in other programming languages as I don't follow them too closely, so it may be the norm. This explanation kinda helps me to map it to Linux model, where Linus rejects an inadequate change once in a while (even though he's no longer the majority code contributor which Araq may still be is for Nim).

  The proper solution is to deprecate csize and that's what we will do. Breaking code nilly-willy wasn't required in order to fix/improve the situation and so that's why it was reverted. (...) In itself that PR solved the code breakage. Followup PRs will fix the bug in a different way. Please notice that this PR was created automatically by github as an "revert this PR action".

  Thanks for this. It might have been obvious to some, but wasn't to me; this explains it well, especially the part about the way forward.

---

• federico3 (orginal) [2019-10-22T21:13:37+02:00] view original

  I support a smoother deprecation process, like the one Araq suggested, because the abrupt change in #12321 creates conditions where csize has different meaning in Nim 1.0.0 and the next release, making it difficult to maintain backward compatibility in libraries. Also, the deprecation process provides a friendly warning to developers instead of introducing a sudden breaking change.

---