<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 February 2014 13:31, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On 4 February 2014 12:57, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 2/3/14, 5:36 PM, Adam Wilson wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You still haven't dealt with the cyclic reference problem in ARC. There<br>
is absolutely no way ARC can handle that without programmer input,<br>
therefore, it is simply not possible to switch D to ARC without adding<br>
some language support to deal with cyclic-refs. Ergo, it is simply not<br>
possible to seamlessly switch D to ARC without creating all kinds of<br>
havoc as people now how memory leaks where they didn't before. In order<br>
to support ARC the D language will necessarily have to grow/change to<br>
accommodate it. Apple devs constantly have trouble with cyclic-refs to<br>
this day.<br>
</blockquote>
<br></div>
The stock response: weak pointers. But I think the best solution is to allow some form of automatic reference counting backed up by the GC, which will lift cycles.</blockquote><div><br></div></div></div><div>I agree, I suggested that a few times, and Adam ignored it each time.</div>

<div>With this approach, performance/aggressive users would be able to disable the backing GC, and deal with cycles manually, taking responsibility for leaking themselves.</div><div>All other users would be able to ignore the problem and have it collected by the backing GC, business as usual.</div>

<div><br></div><div>The advantage here is *choice*. Users would then have a fully automated system and/or have quite articulate control over it's influence on their app.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Oh yeah, and the important detail, that it would apply to phobos and other libraries.</div><div class="gmail_extra">The massive generally un-discussed problem here, is that libraries will almost always use whatever is default and/or most convenient. I have no control over the library code I link; if I can't influence the memory collection routine running behind libraries I'm using, there's a good chance I simply can't use that library.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I tend to think if we had a GC backed ARC system, then phobos would be required to support 'gc-disabled' usage, ie, handle weak references internally (I don't think this is too much to ask for the standard library), making it useful to the 'gc-disabled' crowd, but the GC would remain collecting cycles and such for all the regular D users, who don't want to worry about such troubles. I think the majority of library authors would then follow the phobos standard of handling weak references manually, which would result in those libraries not being excluded from realtime use.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The majority of trivial allocations don't produce cycles; closures, strings, temporary arrays and working sets. These are the allocations that do occur regularly. Major allocations of complex runtime data that may contain cycles don't happen at runtime in realtime apps, but these little trivial/temporary allocations do (and should). Since that sort of transient data doesn't run the risk of cycles, then it will reliably clean up quickly, safely, and immediately under ARC, even with backing GC disabled.</div>
</div>