WinterMute wrote: I don't envisage being able to accept patches that involve enabling D until it goes into upstream gcc because of the level of work needed to maintain it with our tools.
That's understandable. D on embedded systems is far from ready and it's more likely that D is merged into GCC (not before gcc 4.9 though) before we actually have some DS support. I don't really want to see D support in official devkitARM releases, what I meant was I need to add D support in my personal devkitARM builds so we can start testing the compiler.
WinterMute wrote: is it really that suited to embedded dev
Of course that's also always a personal taste thing. There are some features in D that are certainly not usable in embedded dev (GC, TypeInfo but for lower level stuff even Classes, Exceptions might be overkill). On the other hand side D can be used as a more modern C-like subset with a proper module system, proper syntax for arrays, better strings, a safeD subset, sane syntax for function pointers, delegates, function overloading, CTFE (compile time function evaluation), templates (to a certain extent, think of binary bloat). See also: http://dlang.org/comparison.html
(but beware that half of that list isn't valid for embedded...)
WinterMute wrote: How much work is needed to allow use of libnds and friends with D and who's going to do that work?
That's the easy part
D can easily interface to C libraries. There are of course no changes to the C lib required. The headers need to be rewritten into D syntax, but as D is very C like that's usually a simple search&replace and we also have some advanced tools to do that translation. Macros have to be translated manually, so here some work is involved, but that's it. Adapting the standard library to support threading and similar OS stuff might be more difficult, but for a simple start we don't need the standard library.
The bigger problem is that D is currently mainly used on x86/x86_64 and desktop computers. The runtime needs to be adapted for embedded needs (or maybe a new runtime should be written) and the compiler should avoid inserting some library calls. For now I'm mainly interested in getting D (better: the Gnu D compiler) work on ARM at all. Then making it work on the DS would be a nice side project.