On 11 March 2012 16:01, Artur Skawina <art.08...@gmail.com> wrote: > > which I don't imagine D will be able to support any time real soon? > > In fact, until GDC learns cross-module inlining, using these modes is the > only > way to make the compiler generate sane code
Yeah I'm very concerned by this currently. But it seems to we a well known issue with a plan/intent to fix it right? (Side note: I'd still really like an explicit @forceinline attribute) > > ...and even then, relying on WPO for the language to generate good code > in certain circumstances is a really really bad idea. This makes the task > of implementing an efficient compiler for the language extremely difficult. > > There is a reason why i never even considered trying out a non-gcc-based D > compiler... [1] > > For a language like D, WPO in some form is almost required; w/o it you'd > need to > always think about how the compiler will treat your code; which, while > possible, > would often result in more "unnatural" and tricky solutions. (In C/C++ > there's > a *.h/*.c split, which helps mitigate the problem) > "think about how the compiler will treat your code" ... "'unnatural' and tricky solutions" ... Outside of cross module inlining, what are some other common problem cases? C/C++ .h files only really simplify 2 things, inlining, and templates, but I can't see how the situation is any different in D? My understanding is that templates depends on .d/.di files being present during compilation? So why doesn't D do inlining the same way? If I declare some inline function in a .d/.di file, surely it should be capable of inlining? C/C++ can't inline something from a foreign object either without a definition in a header...