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.
