Bug in TypeInfo generation?

[Benjamin Thaut via Digitalmars-d]

Lets say I have a library and it contains the following module:
module a;

struct SomeStruct
{
  string name;
}

struct SomeOtherStruct(T)
{
  ~this()
  {
    typeid(T).initializer;
  }
}

struct ThirdStruct
{
  SomeOtherStruct!SomeStruct m;
}

And now I have a second module:

module b;

import a;

int main()
{
  return 0;
}

I would expect that I can compile module .b into an executable like this:

dmd -m64 b.d

As I'm not using anything from module a I would expect that this 
compiles and links just fine. It does not, it gives linker errors:

b.obj : error LNK2001: unresolved external symbol 
"_D1a10SomeStruct9__xtoHashFNbNeKxSQBgQBhZm".
b.obj : error LNK2001: unresolved external symbol 
"_D1a10SomeStruct11__xopEqualsFKxSQBfQBgKxQjZb".

Debugging dmd a bit shows that the typeid expression in the destructor 
of SomeOtherStruct causes the type info of SomeStruct to be created and 
then in the gen object phase the full type info for SomeStruct is 
written into the object file. This is a bug in my eyes though. The 
compiler should be able to figure out that the destructor of 
SomeOtherStruct must already exist, as its clearly always instanciated. 
As a result the compiler should not instanciate the TypeInfo for 
SomeStruct but instead assume that it also already exists. By doing so 
it would never write the SomeStruct type info to the object file and the 
linker errors would go away.

I'm asking this because this behavior for type info generation turns out 
to be a problem for my dll-work.
--
Kind Regards
Benjamin Thaut