As a somewhat rude demonstration: From the help for module system
proc GC_ref[T](x: ref T) {...} # empty
proc GC_ref[T](x: seq[T]) {...} # empty
proc GC_ref(x: string) {...}
marks the object x as referenced, so that it will not be freed until it is
unmarked via GC_unref. If called n-times for the same object x, n calls to
GC_unref are needed to unmark x. Source Edit
proc GC_unref[T](x: ref T) {...} # empty
proc GC_unref[T](x: seq[T]) {...} # empty
proc GC_unref(x: string) {...} # "see the documentation of GC_ref." i.e.
basically empty, too
Run
This, ladies and gentlemen is what I would call a major clusterf_ck and it
doubtlessly results in _many_ unnecessary problems, bugs, and trouble as well
as to people seeing that, turning around, and walking away from Nim.
It's also an example of what I meant recently: it's next to worthless toying
when ever new gadgets are worked on and being introduced while significant
parts of the bloody vital core of Nim are between unusable and a lottery due to
poor, ridiculously minimal, or even absent docu.
Unless, for instance, the C FFI is _sufficiently_ (interpretation on the
generous side, please) and _properly_ documented (e.g. -> GC_[ref|unref]()) we
have no right to truthfully assert that Nim has a good C interface. (Hint: Araq
recently said that the manual on GC_ref/unref is basically wrong).
Simple rule: if something isn't _well_ documented it should be regarded as
non-existing.
Finally, allow me to bring up another aspect in that context. "We don't do XYZ
yet" is not nice but at least honest. "We do XYZ and we even do it well!" but
then failing the user giving Nim a chance is an invitation to wasted time,
disappointment, and sooner or later a seriously tainted reputation. Recently
there was discussion here re. How to attract new users. Hint: Not pissing them
off by making them waste their time and having to walk all over the place
(official docu, forum, other web sites, source, etc) to find bits of (hopefully
correct) information would seem to be a good start.
