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

[Jonathan M Davis]

On Saturday, October 22, 2011 04:12:36 Sean Silva wrote:
> > 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?).

The built-in sort on arrays is going away. std.algorithm.sort should be used 
instead. I'm afraid that I don't understand what your comments on the STL have 
to do with the GC though. And stuff in Phobos (such as std.algorithm) is very 
much like the STL - only it uses ranges instead of iterators. The main item 
lacking is a comprehensive list of containers, and the main reason that 
std.container doesn't have more yet is because the custom allocator stuff is 
still being sorted out, and Andrei doesn't want to implement them all and then 
have to change them to work with custom allocators. So, once that's done, I 
don't know what the STL would really give you that Phobos doesn't.

- Jonathan M Davis