Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.
The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.
This Week in D has an RSS feed.
This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.
See more at the announce forum.
The thread DMD producing huge binaries brought up a recurring problem inlarger D codebases: gigantic symbol names leading to huge binaries and really slow builds.
The core team is onboard with finding a solution. Walter quickly enabled a compression scheme on symbols, and others are helping with the implementation, making it fast. However, compression is a linear solution to an exponential problem, and even if the compression algorithm is very fast, it will necessarily eat some CPU and RAM (even if the cost is smaller than writing out the large symbol names to the object file and being processed by the linker), so others are continuing to search for a root-cause fix.
Among the ideas are changing the mangling scheme for auto functions, which fails to fix the exponential size problem, hashing symbols, which limits their size but adds more processing time (already done on dmd/win32 using OMF to work around optlink size limits), or using some kind of random or sequential identifier, which has the problem of not being reproducible reliably under separate compilation (doing one module or package at a time - then, the sequence a symbol is encountered will not necessarily be the same when building the next package, and that would lead to linker errors).
My money is on a compression/hash implementation being merged in the next month to kick the problem further down the road (perhaps even good enough for all practical purposes!), but I'm holding out hope that we'll figure out a root cause solution as it should give the best long-term results.
With general consensus that this is a serious problem that needs a solution, I am optimistic about where this is going. Walter also recognized some other bugs with separate compilation in the past, so we should hopefully avoid repeating those mistakes.
Meanwhile, the thread about floating point continued, with the argument apparently going in circles. We still might get a warning for some of the issues, but the original agreement is now getting buried in the long argument. You, yes, you, the reader, might want to redouble efforts on the noncontroversial tidbits to make at least incremental progress despite the ongoing argument.
To learn more about D and what's happening in D: