@Araq: > I'm sorry but I really want something that works before announcing it and > documentation follows after a working implementation...
I'm sure **everyone appreciates that** , and it's obvious that we don't want to waste too much time on the documentation until things stabilize. That said, **there are experiments and failed experiments in the code base that are confusing for any programmers that are getting into Nim well after they were considered**. For instance, of the actual ten methods of GC (eight plus "\--gc:stack" \- same as ""\--gc:regions" and "\--gc:none") as per the OP here, which doesn't include "\--newruntime" which is another form of no GC, it would seem that at least two options (as in "\--gc: generational" and "\--gc:v2" have been dropped/depreciated and lead nowhere and there are no plans to advance them. It's true that one needs to read the source code to actually find the dropped ones, as they no longer even show up in "nim --fullhelp". However, of the others, there doesn't seem to be much explanation, even in the "garbage collection" document that seems to be very out-of-date. **When it comes to GC, Nim is getting to the state of too many options to try for someone new to Nim, without any documentation on the advantages and disadvantages of each.** For instance, there isn't any documentation that says that both both the Boehm and Go (i think?) GC options support GC across threads of the older no-longer-advancing methods, what Regions GC does that makes it different, that MarkAndSweep is the more tunable GC as to real time latencies as compared to the default deferred RC (I think?). AFAICT, all of the above methods are stable and have been available for years and are unlikely to change, especially in light of evolving "better" ways such as the new "Destructors" methods of "araqsgc" or "newruntime". **There can also be the issue of somewhat confusing names /switches**: "\--gc:destructors" originally seems to have been conceived as a way of providing some sort of memory management based on the new destructors but with a GC "hook" option, but now the "destructors" part of that has been moved into a separate "\--seqsv2" compiler switch, as the remaining purpose of the "\--gc:destructors" switch seems to be to remove cruft (;-) ) as in by-passing "deepCopy" and various AST types of magic, as well as all forms of built in GC, leaving only whatever can be provided through the GC "hooks". A better name for it might be "\--gc:nocrufthook" ;-) ; in fact it is evolving into something rather nice! **However, I wonder if it is getting ambiguous to do with the "\--gc:none" switch:** if the default for the "\--gc:nocrufthook" were to "hook" the newObj hook to the appropriate allocator (regular or malloc) just as "\--gc:none" does with the traverseObj hood hooked to a discard, then when no "hooks" are provided it would work as if "\--gc:none" had been used but with the guarantee of no cruft; it would also not blow up when no implementation of the "hooks" were provided when ref's (including closures) were used, as "nogc" would then be the default. In order to be backward compatible, the "\--gc:none" compiler switch could just activate this mode. **I can think of no reason that one would want "nogc" with cruft, can you?** I think doing it as proposed might actually decrease the code as in not turning off/bypassing/short-cutting the built-in GC in two places... It's a minor quibble but while I highly applaud the cruft-removing "\--seqsv2" switch, **shouldn 't it be more clear that this applies "destructors" to `string` as well as `seq` and be named "\--seqstrv2"**?
