> That's something that can always happen without breakage. Let's focus on > language/stdlib changes that need breakage :)
The problem is that it won't happen _ever_ if not someone who knows the compiler actually does it... It may not be a backward-breaking change, but it certainly is a **back-breaking** labor unless you know the ins and outs of the compiler (I've gotten the impression you worked on the compiler once upon a time). These are my 5 cents. It's your free time but if you want to help Nim the most for the long-term, I think refactoring the compiler is a better way than implementing a random backward-breaking feature. It will both reduce the number of bugs (assuming the refactoring is good of course ;)) and make future contributions from _non-core_ members easier if the compiler gets a refactoring to become less of a band-aid on band-aid mess (that's my impression of it from the outside at least). Of course it is waaayyy more boring than implementing something new and fresh. But it will be needed sooner or later and I haven't got the impression that Araq will volunteer to do it anytime soon. So it doesn't leave very many potential people who knows how the compiler is supposed to work who haven't already left...
