On 08/09/18 11:07, Peter Alexander wrote:
I'd love to know if anyone is making good use of @nogc in a larger code
base and is happy with it. Weka.io?
No, sorry.
Actually, yes.
Well, sortof.
The main Weka codebase hardly uses any annotations of any kind. Not
@nogc nor others. This is in the process of being amended, somewhat, but
is not a high priority. We do use run-time detection of GC use. I.e. -
we've modified the druntime to invoke a callback if a GC allocation
takes place, and we then log that fact (with traceback). We then are
able to search logs for GC allocations and remove them.
So that's the "no" part.
As pointed out, one of the main motivations for running Mecca was to
clear up the strange solutions that have accumulated over the years. As
such, the Mecca code does have @nogc in much more wide use.
So, yes.
There is a catch, though. Writing Mecca with @nogc required
re-implementing quite a bit of druntime. Mecca uses its own exception
allocations (mkEx, just saw it's not yet documented, it's under
mecca.lib.exception). The same module also has "enforceNGC". We also
have our own asserts. This is partially to support our internal logging
facility, that needs a static list of formats, but it also solves a very
important problem with D's @nogc:
void func() @nogc {
assert(condition, string); // string is useless without actual info
about what went wrong.
assert(condition, format(string, arg, arg)); // No good - format is
not @nogc
ASSERT!"format"(condition, arg, arg); // @nogc and convenient
}
So, yes, we do use @nogc, but it took a *lot* of work to do it.
The good news is that mecca is available, and you can just dub it into
your project and use it, so you don't have to repeat that whole set of work.
Mecca was advertised mostly around the reactor. While it is a piece of
work I am very proud of, it is not the only part there, nor is it
necessary to use mecca's reactor if you want just the library. In fact,
nothing outside of mecca.reactor depends on the reactor running.
Hope this helps,
Shachar
