<p><br>
On Nov 30, 2013 3:01 AM, "Nick" <<a href="mailto:nmsmith65@gmail.com">nmsmith65@gmail.com</a>> wrote:<br>
><br>
> On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu wrote:<br>
>><br>
>> On 11/29/13 5:43 AM, Manu wrote:<br>
>>><br>
>>> * ARC<br>
>>> * rvalue -> ref<br>
>>> * virtual-by-default<br>
>>> * GC improvements<br>
>>> * AA fixes<br>
>><br>
>><br>
>> These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts.<br>

>><br>
>> We should break each of these down into bite-sized bugzilla issues.<br>
>><br>
>><br>
>> Andrei<br>
><br>
><br>
> A bite-sized GC-related improvement is the @nogc attribute I've been craving for for quite some time. See: <a href="https://d.puremagic.com/issues/show_bug.cgi?id=5219">https://d.puremagic.com/issues/show_bug.cgi?id=5219</a><br>

><br>
> If I had money, I'd be putting it on this for sure. For system and game programmers it's a godsend, and it will put some C++ fanatics at ease with D's GC. With this feature I can protect the critical sections of my code with a firm guarantee that I won't see any unexpected activity from the GC.</p>

<p>But how do you expect this to be implemented? Implicitly putting GC.disable/GC.enable at the prologue / epilogue of a function?</p>
<p>Regards<br>
-- <br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';</p>