Workaround for typeid access violation

[Etienne Cimon via Digitalmars-d]

On Wednesday, 17 June 2015 at 14:19:33 UTC, ketmar wrote:
> this is an implementation detail. nothing guarantees that is 
> will stay like that even for one more commit. relying on this 
> means that your code is bugged and can break at any time, 
> without warning. more than that, if user pulled in another GC 
> implementation, completely adhering to specs, your code simply 
> goes nuts, forcing the poor user to guess what's wrong.
>
> so as other people already wrote, simply "don't do it". there 
> will be no way to do what you want here until GC requirements 
> in specs will be changed (and this is unlikely to happen).

If we can freeze the druntime interface anytime soon (while 
adding said support to the interface), the library can be subject 
to micro-optimizations by deferring the linking process and 
allowing it to be compiled and linked through dub.

This allows applications to use whatever GC is best for them. 
Parallel, precise, thread-local, you name it.

This being said, I know my use of the core.gc implementation 
carries no forward guarantees, so, I might end up dragging it 
along for a while and merging only certain parts of druntime in 
the future.