Small @nogc experience report

Steven Schveighoffer schveiguy at gmail.com
Wed Sep 19 18:35:34 UTC 2018


On 9/19/18 1:13 PM, Shachar Shemesh wrote:

> 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.

I'm running into this coincidentally right now, when trying to debug a 
PR. I found I'm getting a range error deep inside a phobos function. But 
because Phobos is trying to be pure @nogc nothrow @safe, I can do almost 
nothing to display what is wrong.

What I ended up doing is making an extern(C) hook that had the "right" 
attributes, even though it's not @nogc (let's face it, you are about to 
crash anyway).

But it got me thinking, what a useless interface to display errors we 
have! Inside Throwable, there is the function toString(someDelegate 
sink) which prints out the exception trace.

Near the front there is this:

         if (msg.length)
         {
             sink(": "); sink(msg);
         }

My, wouldn't it be nice to be able to override this! And forget about 
the whole msg BS. When an exception trace is printed, there are almost 
no restrictions as to what can be done. We should delay the generation 
of the message until then as well! Not to mention that if we can output 
things piecemeal through the sink, we don't even have to allocate at all.

I'm going to write up a more detailed post on this, but it's annoying to 
throw exceptions without any information EXCEPT what can be converted 
into a string at runtime at the time of exception. All that is missing 
is this hook to generate the message.

-Steve


More information about the Digitalmars-d mailing list