Thanks to a reddit thread I stumbled over D and thought I should give it a chance. I'm currently working on project where hard RT requirements matter. In most places the GC is not suitable. I tried to port some core functionaly of an existing application which is currently written in C/C++. I tried to convert some things 1:1 to D, well aware that a better approach may exist.
I think that only "struct" and "scope class" are suitable to create objects. structs have the simple advantage that I don't have to type "scope" in my whole program (can't alias it e.g.), but have the disadvantage that I can't use an interface nor inheritance. The application should have a dictionary which contains values of many different objects. For this example, all objects should support a toFoo method. To make it generic I've to rule out a struct, or to write everything in a more functional style (a everythingToFoo method handles all different types). interface Entry { Foo toFoo(); } scope class EntryNumeric(T) : Entry { T value = T.init; Foo toFoo() { ... } } alias Entry!(int) EntryInt; alias Entry!(float) EntryFloat; setup(Entry[] entries) { scope auto e1 = new EntryInt(); Foo = e1.toFoo(); scope auto e2 = new EntryInt(); Foo = e2.toFoo(); entries[0] = e1; entries[1] = e2; } init() { Entry entries[2]; setup(entries); entries[0].toFoo(); entries[1].toFoo(); } I wonder why I can compile the above piece, because e1/e2 shouldn't be allowed to leave the scope. It obviously crashes. The next thing I tried to solve is some kind of a templated Queue class, which can store anything. In C++ it's easy to write a container class that only works on the stack and uses some uninitialized bytes of memory and placement new to copy construct objects into the Queue. With "scope class" this seems to fail because it seems to be impossible to return a class if it's type uses "scope" class. Missing copy construction one could probably solve manually, by just carefully create an own core class library (or just juse memcpy). struct Queue(T, int N) { } scope class MyClass { } Queue!(MyClass) m; Another problem with my whole, everything on the stack idea, is that D limits my arrays to an internal limit (any paramter to change it?). It's easy to create a stack overflow anyway, so why a limit? That static arrays are stored in the .data section make things even more complicated. That the new core.memory.GC somehow misses a function to analyze if there is any hidden malloc in any used function would be usefull as well, because it's not always obvious which construct had what effect (forgetting scope on a delegate etc...) Thanks for any insight, tips, hints, ...