<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 April 2014 19:03, JN 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I don't believe users hesitant to use D will suddenly come to D now that there is a @nogc attribute.  I also don't believe they want to avoid the GC, even if they say they do.  I believe what they really want is to have an alternative to the GC.<br>

</blockquote>
<br></div>
I'd have to agree. I doubt @nogc will change anything, people will just start complaining about limitations of @nogc (no array concat, having to use own libraries which may be incompatible with phobos). The complaints mostly come from the fact that D wants to offer a choice, in other languages people just accept what they have. You don't see C# developers complaining much about having to use GC, or C++ programmers all over the world asking for GC. Well, most of the new games (Unity3D) are done in C# nowadays and people live with it even though game development is one of the biggest C++ loving and GC hating crowd there is.<br>

<br>
Another issue is the quality of D garbage collector, but adding alternative memory management ways doesn't help, fragmenting the codebase.<br>
</blockquote></div><br></div><div class="gmail_extra">I don't really have an opinion on @nogc, but I feel like I'm one of the people that definitely should.</div><div class="gmail_extra">I agree with these comments somewhat though.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I have as big a GC-phobia as anyone, but I have never said the proper strategy is to get rid of it, and I'm not sure how helpful @nogc is.<br></div><div class="gmail_extra">
I don't <i>mind</i> the idea of a @nogc attribute; I do like the idea that I may have confidence some call tree doesn't invoke the GC, but I can't say I'm wildly excited about this change. I'm not sure about the larger implications for the language, or what the result of this will do to code at large. I'm not yet sure how annoying I'll find typing it everywhere, and whether that's a worthwhile tradeoff.</div>
<div class="gmail_extra">I have a short list of things I'm dying for in D for years, and this is not on it. Nowhere near. (rvalue temp -> ref args pleeeease! Linear algebra in D really sucks!!)<br></div><div class="gmail_extra">
<br></div><div class="gmail_extra">The thing is, this doesn't address the problem. I *want* to like the GC... I want a GC that is acceptable.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I am convinced that ARC would be acceptable, and I've never heard anyone suggest any proposal/fantasy/imaginary GC implementation that would be acceptable...</div>
<div class="gmail_extra">In complete absence of a path towards an acceptable GC implementation, I'd prefer to see people that know what they're talking about explore how refcounting could be used instead.</div><div class="gmail_extra">
GC backed ARC sounds like it would acceptably automate the circular reference catching that people fuss about, while still providing a workable solution for embedded/realtime users; disable(/don't link) the backing GC, make sure you mark weak references properly.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">That would make this whole effort redundant because there would be no fear of call trees causing a surprise collect under that environment.<br></div><div class="gmail_extra">
<div><br></div></div><div class="gmail_extra">Most importantly, it maintains compatibility with phobos and all other libs. It doesn't force realtime/embedded users into their own little underground world where they have @nogc everywhere and totally different allocation API's than the rest of the D universe, producing endless problems interacting with libraries. These are antiquated problems we've suffered in C++ for decades that I _really_ don't want to see transfer into D.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I'd like to suggest experts either, imagine/invent/design a GC that is acceptable to the realtime/embedded crowd (seriously, can anyone even _imagine_ a feasible solution in D? I can't, but I'm not an expert by any measure), or take ARC seriously and work out how it can be implemented; what are the hurdles, are they surmountable? Is there room for an experimental fork?</div>
</div>