<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 September 2014 16:19, deadalnix via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via Digitalmars-d wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I still think most of those users would accept RC instead of GC. Why not<br>
support RC in the language, and make all of this library noise redundant?<br></span><span class="">
Library RC can't really optimise well, RC requires language support to<br>
elide ref fiddling.<br>
</span></blockquote>
<br>
I think a library solution + intrinsic for increment/decrement (so they can be better optimized) would be the best option.<br>
</blockquote><div><br></div><div>Right, that's pretty much how I imagined it too. Like ranges, where foreach makes implicit calls to contractual methods, there would also be a contract for refcounted objects, and the compiler will emit implicit calls to inc/dec if they exist?<br>That should eliminate 'RefCounted', you would only need to provide opInc()/opDec() and rc fiddling calls would be generated automatically? Then we can preserve the type of things, rather than obscuring them in layers of wrapper templates...</div></div></div></div>