On 04/30/2015 01:30 PM, Mike wrote: > While this may seem simple to achieve, I think it will raise a few > questions that will need answering. > > * Can ModuleInfo be leveraged, without introducing overhead, to call > module constructors and static constructors? They might be useful for > hardware initialization.
Currently D sorts modules by initialization order,which requires every moduleinfo to contain an array of imported modules. Quite a lot of RAM for a nice to have feature, so we should drop it or at least provide a -fno-moduleinfo switch. > * Is dynamic memory allocation a requirement of D, or a library feature? Definitely a library feature, though many language features, like array appending, won't work without it (delegate closures won't even work without a GC). > * Does D need the C runtime, or can it init on its own? It shouldn't need a C runtime. > * Should the C standard library bindings be part of the runtime, or > exist as an external Deimos library? Either way they can still be used > by the runtime, I'm just suggesting that they should be encapsulated. It doesn't cost you anything to include the bindings in a release, they could be maintained in a separate project if that helps. > * What will be done about TypeInfo for now? It's causing me some > serious code-bloat problems. See > http://forum.dlang.org/post/[email protected] Implement a -fno-rtti switch for GDC. > * Is data and bss initialization part of the runtime, or delegated to > toolchain, silicon, and BSP vendors? We should provide appropriate linker scripts and do the initialization.
