These sounds fantastic, it will break a lot of code though but I'm all for it
behind an `{.experimental.}` flag at first.
Assuming this is introduced after 1.0, this would break the usual implicit
assumptions that 1.0 code is "stable" so expectations should be managed
carefully.
Maybe something similar to how Adacore manages Spark with several safety
standards that Nim is moving towards:
* Stone: Nim 0.19+ with GC and not nil guarantees.
* Bronze: Nim 1.0 with destructors, sink and lent borrow checking.
* Silver: Nim 1.2 with deep immutability/write-tracking of reference types.
* Gold: Nim 1.6 with effect system, error handling, strong aliasing,
concurrency and parallelism guarantees even on shared memory
pointers/openarrays.
* Platinum: Nim 1.10 with invariants, contracts or specifications guarantees.
* Iridium: Nim 10.0, all-you-can-eat features buffet including formal
verification.
* * *
I'm not that worried about the returnsNew effect. It can be introduced later.
Also from a optimizer point-of-view, I would love to map Nim effects to [GCC
function
attributes](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html)
later (the `malloc` one) which would help in autovectorizing code without
having to sprinkle `restrict` C pragma. Similarly, mapping aligned allocators
to `alloc_align` which is especially important on non-x86 systems with no
unaligned vectorized loads.
