679 – Spec needs allowances for copying garbage collection

The specification is to the effect that a D implementation may use a garbage collector that moves objects around in memory. However, there are issues that still need to be addressed before this'll work.
http://www.digitalmars.com/d/archives/26273.html
http://www.digitalmars.com/d/archives/digitalmars/D/learn/3492.html
To summarise, these issues are:
(a) unions
(b) pointers into the GC heap held by foreign code
(c) crocky APIs, which may sometimes use pointer types to hold non-pointer data (e.g. in the Windows API, handles and numeric resource IDs) or vice versa (I think there are one or two instances of this in the Windows API)
Moreover, gc.html indicates that, for (b), it is sufficient to "Maintain a root to the object in an area the collector does scan for roots". (At least they _appear_ to be "or" bullet points, considering that it can't be necessary to do all three, and sometimes doing all three isn't even possible.) However, this won't work if the GC may still move the object in memory, as it isn't going to update the pointer held by the foreign code.
Several people have proposed a method of pinning as a way to deal with this. Walter also indicated (see the second linked-to post) that there would be implicit pinning in certain circumstances. However, none of this is documented yet. It needs to be.
A possibility is to specify that the following will implicitly pin something in the GC heap:
- storing a pointer to it in a union
- storing a pointer to it on the stack
- making the object's memory address a root using using std.gc.addRoot or std.gc.addRange
- having a pointer to it in any foreign memory that the GC happens to stumble upon
The option to "Maintain a root to the object in an area the collector does scan for roots" would have to be removed. In order for it to be pinned so that a copying GC doesn't invalidate the pointer held by the foreign code, it's necessary (in the general case) to addRoot the pointer itself or use one of the other pinning mechanisms. Maintaining a root to the foreign memory where the pointer is held may not be an option - even if the foreign API documents the conditions under which it keeps the pointer, it need not release to the outside world anything about _where_ it keeps it.

(In reply to comment #0)
> A possibility is to specify that the following will implicitly pin 
> something in the GC heap:
Add to this list:
- Storing a pointer to it in an allocated block referenced by a void* or void[].

http://www.dsource.org/projects/phobos/changeset/2138