Feature suggestion: in-place append to array

[Mike S]

bearophile wrote:
> Mike S:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
> 
> It's a nice read. I don't see them switching to D soon. If you whisper them that D is based on a GC they will run away screaming :-)
> 
> Bye,
> bearophile

Hah...well, there's a reason I'm still just looking into D rather than 
diving in headfirst! :p  Actually though, I do believe the needs of game 
programmers should be taken seriously while considering D's evolution: 
Right now, D hasn't completely found its niche, but it seems to position 
itself as a sane successor to C++ for systems-level programming.  As it 
stands, I believe there are only two major kinds of programmers who 
still use C++, and those are game programmers and masochists. ;)  Odds 
are, D won't be replacing C anytime soon for operating system kernels 
and such.  It's too low-level for scripting tasks, and most website 
designers and non-real-time applications programmers use higher-level 
languages already (C#, Python, PHP...shudder...etc.), and they're 
unlikely to go back.  I think D will eventually be used for writing 
other heavy-duty non-OS frameworks and software systems, but if it's 
really going to become the successor to C++, it's going to have to 
absorb most of C++'s user base...and that includes game programmers.

You're right that the garbage collector is a major issue - probably the 
biggest one inherent to the language design - but I haven't determined 
it's a dealbreaker, at least not yet.  After all, D also allows manual 
memory management, and freeing memory early apparently helps speed 
things up anyway 
(http://stackoverflow.com/questions/472133/turning-off-the-d-garbage-collector). 
  That part helps ensure control over how much memory is used/available, 
and the only other issue with the garbage collector is reconciling its 
running time with the soft real-time constraint that games have to 
satisfy.  I can think of a few tactics which should help here:
1.)  In addition to permitting better reasoning about memory 
allocations, freeing most memory manually should reduce the load on the 
garbage collector and reduce its runtime, right?
2.)  On the simulation side of the game engine, I believe a constant 
timestep promotes a more robust design, and that means some frames 
(relatively idle ones) will have plenty of CPU time left over.  If you 
can explicitly call the garbage collector to make it run during those 
times instead of at nondeterministic times (can you?), you can maintain 
a smooth framerate without any GC-induced spikes.
3.)  Can user code execute simultaneously with the GC in other threads 
(on other cores), or does the GC halt the entire program for safety 
reasons?  Assuming simultaneous threaded execution is permitted, it 
would also dramatically reduce the GC's impact on multi-core systems.

Assuming these strategies work, the garbage collector by itself 
shouldn't be a showstopper.  In the case of dynamic arrays, resizing 
capacity deterministically is one of those small things that would be 
really helpful to anal game programmers, and it probably wouldn't hurt 
anyone else, either.  Plus, it's easier to implement than "smart 
nondeterministic" resizing anyway. :)