> My point here is that a GC-free scheme is not an unambiguous "big selling > point", but presents > programmers with having to decide on tradeoffs, where > they may prefer a GC-ed language instead, > once they consider those > tradeoffs.
I doubt that any knowledgeable programmer would disagree with this statement, or the statement with GC-less and GC-ed switched. Then we have to ask what the goals for Nim are, and also if there's a feasible way to have our cake and eat it. Araq's suggestion of a special GcRef[T] would be one idea to get back some advantages of a GC language into one which is by default not GC-ed. The D community is struggling with this now as well, not just the @nogc attribute, but the --betterC switch which gives a restricted version of D (no GC, classes, exceptions, but templates, RAII) suitable for being linked as a C library with no hassles. Nim appears better suited to handle this as Walter Bright has a strong aversion to having multiple pointer types in D.
