Looking for documentation of D's lower-level aspects.

[Sean Silva]

> You _can_ use D with no to minimal GC, but you have to be very careful. A good
> chunk of the standard library would be completely unusable without the GC
> (primarily anything which might allocate or append to an array), you have to
> be very careful when using arrays (since appending to them wouldn't work, and
> you have to worry about who owns an array so that slices don't result in
> memory leaks or you using a slice which has already be freed), and there are
> some cases where something might allocate using the GC when you don't expect.
> For instance.
> int[3] a = [1, 2, 3];
> currently allocates a dynamic array which is the copied into the static array.
> It shouldn't allocate like that, and it _will_ be fixed so that it doesn't, but
> for now it does.
> Generally, I'd say that the best way to deal with D is to just not worry about
> the GC until you profile your code and see that it's a problem. If don't need
> inheritance and so are using primarily structs rather than classes, you often
> don't need to allocate much on the heap. If you're not doing a lot with
> classes, the primary thing on the heap would be arrays (including strings).
> But if you're smart about avoiding unnecessary allocations, the abilities that
> the GC gives you with arrays (such as concatenation and the ability to use
> slices without worrying about how many references to it there are) are well
> worth it.
> Essentially, as long as you avoid constantly allocating stuff on the heap, the
> GC shouldn't cause you much trouble.
> - Jonathan M Davis

I don't have anything against GC or just having the GC hang around. In fact, it is GC and D's "nice" dynamic arrays that let it do so much
cool stuff at compile time (since they are safe), which is one of the biggest wins of D IMO.

For me, it's not so much a matter of performance as that I personally prefer to have a coherent interface to all my containers, so even though
it is a bit of syntactic overhead, I would prefer `Vector!int` and `List!int` than `int[]` and `List!int`. Built-in niceties are great, but
for real work I prefer to have a coherent library. E.g. my C++ code using STL has *far* fewer bugs than my Python code, and I'm equally
knowledgeable about both languages, maybe Python a bit more since I've used it longer (that STL achieves raw C performance is another big
benefit). For me, it's the same reason that it's preferable to have `sort()` be a free function (within a coherent algorithms library like
std.algorithm) rather than a method of the built-in arrays (I noticed that D has `array.sort`, but I think it must be a carry-over from the
past before D had std.algorithm; or maybe it is for compile-time programming?).