> Nim's original design philosophy was to be a lean, simple, powerful, elegant > and efficient garbage collected programming language. ...
Personally I'm relatively new to Nim and have a bit different perspective. Initially was a bit confused by all the "features" and different configurations of Nim. However, I think Nim has been finding more of a theme and direction since 1.0 and especially with ARC/ORC. Overall I still find Nim and the compiler impressively nimble overall, while being surprisingly stable given how flexible it is. > This may have been the wrong "hill to die on", but I'm not going to pretend > this is an isolated incident where the attitude of - let's add feature X, Y > or Z to Nim because it would be cool or for shits and giggles or whatever - > has played out. I actually agree with the Nim team not adding features for the sake of adding features. But from the outside I see something that could be an almost trivial change that _might_ add a lot of value to an existing underused feature. Maybe an "allocation effect" would be usable or maybe not; however tracking allocations _is_ a valuable use case in systems programming, including embedded or most any high performance code (game dev, scientific, graphics, etc). Oddly tracking allocation it is not something most languages are capable of doing, despite many efforts to optimize allocating memory. To rephrase my question, _if_ Nim has an effect system and it's not going away, then it'd be nice to use it to solve problems me and others run into. Or rather enable community members like myself to try out ideas to see if it'd even be feasible or useful. Maybe it's a PR to enable others to discuss whether creating an RFC would even be appropriate. I actually like that Araq's response was a bit skeptical and suggested a non-effects solution which is feedback I wanted on my original question/idea. He didn't block the overall notion and rather suggested an alternative solution. Seems reasonable to me.
