<div dir="ltr">On 9 October 2013 08:58, ponce <span dir="ltr"><<a href="mailto:contact@gmsfrommars.fr" target="_blank">contact@gmsfrommars.fr</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Eh, not necessarily. If it expands to static assert(!__traits(<u></u>hasAnnotationRecursive, uses_gc));, then the only ones that *need* to be marked are the lowest level ones. Then it figures out the rest only on demand.<br>

<br>
Then, on the function you care about as a user, you say nogc and it tells you if you called anything and the static assert stacktrace tells you where it happened.<br>
<br>
Of course, to be convenient to use, phobos would need to offer non-allocating functions, which is indeed a fair amount of work, but they wouldn't *necessarily* have to have the specific attribute.<br>
</blockquote>
<br></div>
But is it even necessary? There isn't a great deal of evidence that someone interested in optimization will be blocked on this particular problem, like Peter Alexander said.<br>
<br>
GC hassle is quite common but not that big a deal:<br>
- Manu: "Consequently, I avoid the GC in D too, and never had any major problems, only inconvenience." <a href="http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccnefe7" target="_blank">http://www.reddit.com/r/<u></u>programming/comments/1nxs2i/<u></u>the_state_of_rust_08/ccnefe7</a><br>

- Dav1d: said he never had a GC problem with BRala (minecraft client)<br>
- Me: I had a small ~100ms GC pause in one of my games every 20 minutes, more often than not I don't notice it<br>
<br>
So a definitive written rebutal we can link to would perhaps be helpful.<br>
</blockquote></div><br></div><div class="gmail_extra">I might just add, that while my experience has been that I haven't had any significant technical problems when actively avoiding the GC, the inconvenience is considerably more severe than I made out in that post (I don't want to foster public negativity).</div>
<div class="gmail_extra">But it is actually really, really inconvenient. If that's my future with D, then I'll pass, just as any un-biased 3rd party would.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
I've been simmering on this issue ever since I took an interest in D. At first I was apprehensive to accept the GC, then cautiously optimistic that the GC might be okay. But I have seen exactly no movement in this area as long as I've been following D, and I have since reverted to a position in absolute agreement with the C++ users. I will never accept the GC in it's current form for all of my occupational requirements; it's implicitly non-deterministic, and offers very little control over performance characteristics.</div>
<div class="gmail_extra">I've said before that until I can time-slice the GC, and it does not stop the world, then it doesn't satisfy my requirements. I see absolutely no motion towards that goal.</div><div class="gmail_extra">
If I were one of those many C++ users evaluating D for long-term adoption (and I am!), I'm not going to invest the future of my career and industry in a complete question mark which given years of watching already, is clearly going nowhere.</div>
<div class="gmail_extra">As far as the GC is concerned, with respect to realtime embedded software, I'm out. I've completely lost faith. And it's going to take an awful lot more to restore my faith again than before.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">What I want is an option to replace the GC with ARC, just like Apple did. Clearly they came to the same conclusion, probably for exactly the same reasons.</div><div class="gmail_extra">
Apple have a policy of silky smooth responsiveness throughout the OS and the entire user experience. They consider this a sign of quality and professionalism.</div><div class="gmail_extra">As far as I can tell, they concluded that non-deterministic GC pauses were incompatible with their goal. I agree.</div>
<div class="gmail_extra">I think their experience should be taken very seriously. They have a successful platform on weak embedded hardware, with about a million applications deployed.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">I've had a lot of conversations with a lot of experts, plenty of conversations at dconf, and nobody could even offer me a vision for a GC that is acceptable.</div><div class="gmail_extra">As far as I can tell, nobody I talked to really thinks a GC that doesn't stop the world, which can be carefully scheduled/time-sliced (ie, an incremental, thread-local GC, or whatever), is even possible.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I'll take ARC instead. It's predictable, easy for all programmers who aren't experts on resource management to understand, and I have DIRECT control over it's behaviour and timing.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But that's not enough, offering convenience while trying to avoid using the GC altogether is also very important. You should be able to write software that doesn't allocate memory. It's quite hard to do in D today. There's plenty of opportunity for improvement.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I'm still keenly awaiting a more-developed presentation of Andrei's allocators system.</div></div>