Merely importing a file that contains template can make dmd generate code. This not only increases compile times, but it also can be the reason for severe exe bloat: often the linker will pull in completely unrelated modules just to get symbols for instantiated templates (the bloat is then caused by unrelated symbols that have been unnecessarily been pulled in). $ cat a.d module a; import b; $ cat b.d module b; struct Bloat(T) { void foo() { } } class NotBloat { this(Bloat!(uint) x) { } } $ dmd -c a.d $ nm a.o|grep Bloat 00000000 W _D1b12__T5BloatTkZ5Bloat3fooMFZv 00000000 V _D1b12__T5BloatTkZ5Bloat6__initZ 00000000 V _D32TypeInfo_S1b12__T5BloatTkZ5Bloat6__initZ a.d only imports b.d, yet there's this crap in a.o. Obviously dmd should not generate code in this case.
What matters is what gets into the exe file, not what's in the object files. To that end, if you use dmd to generate a library file from source, it will split each object file into multiple ones (one for each global symbol). Then, only the referenced symbols get pulled in. It's not a perfect solution, but it's a start.
Brad, why did you re-open this bug? I think that there is sufficient discussion of template bloat elsewhere that this particular bug being open is unnecessary. So, considering that, could we close this off?
I reopened it after ngxjfg went on a bit of a rampage closing all the bugs he filed. This was one of them. If the bug is fixed, by all means close it. But don't close it just because of a vague notion of 'we know there are template bloat issues'. This bug report happens to be a really good specific example.
Sounds fine by me. I was just going off Walter's comment.
This seems to have been fixed. nm on a.o simply yields: 0000000000000000 t 0000000000000000 R _D1a12__ModuleInfoZ U _d_dso_registry U __start_minfo U __stop_minfo