Small @nogc experience report

[Shachar Shemesh]

On 19/09/18 21:35, Steven Schveighoffer wrote:
> 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

Then by all means, have a look at ASSERT inside mecca.lib.exception.