Discusssion on the Discussion of the Design for a new GC

[Orvid King via Digitalmars-d]

So, in order to get the ball rolling on the new GC I intend to 
implement for D, I want to facilitate a lively discussion of the 
design of it, so that it can be designed to be both robust and 
free of design flaws. To keep the discussion from getting 
derailed, I want to lay out a few guidelines, but want to get 
feedback on those guidelines before I actually implement them. My 
current draft of them is as follows:

First we’ll start with a brief overview of the development 
process:
A PR will be created for DMD, DRuntime, and, although it may stay 
empty, Phobos. A new commit will be created for each update of 
the implementation, this includes bug fixes, and continuing work 
on the implementation, in as many iterations as are required. 
This is done to allow progressive review of the code rather than 
trying to review the PRs as a whole, because, as it is likely to 
include several thousand lines of changes to the code, it would 
be impractical to review all at once.
No force push should ever be done to the PRs except to fix a typo 
in or clarify a detail of the commit message for the newest 
commit. If there is a typo in a commit message, or it is not very 
clear on what was actually done, and another commit has already 
been pushed, the typo or un-clear message shall remain for all 
eternity. The suggested remedy in this case is to make a note of 
the typo or clarify the commit message with a comment on the 
commit.
PRs to the PRs are welcome, it is however encouraged to 
coordinate any work you do with the others actively working on 
the GC. The primary outlet for this should be the IRC, however, 
should the need arise, the mailing list is a valid venue for this.
Github should be used as the primary outlet for discussion of 
actual code, due to the ease of referencing code, as well as the 
ability to tell if a comment is about a piece of code that was 
already changed.
The mailing list should be used exclusively for discussion of the 
design. It should not be used for discussing snippets of code in 
the actual implementation. It can, and should be, used to discuss 
snippets of code that may demonstrate a flaw, weakness, or 
strength in the design.
The IRC should be used for rapid-fire Q&A, or bringing someone 
up-to-date with the discussion and progression of the GC so far. 
Discussion about inconsistencies in the coding style of the 
implementation (whitespaces, newlines, etc.) should reside 
exclusively on the IRC, as they are things that a future reader 
of the discussions doesn’t really care about. If a discussion of 
the overall code style used in the implementation is required, a 
thread should be created on the mailing list.
The IRC should not be used to facilitate a design discussion. The 
reason for this is twofold, firstly the IRC has a limited 
audience, thus limited feedback, and secondly, I want the 
discussion of the design to stand as documentation for why the GC 
is designed the way it is.

Now, on to the guidelines for the design discussion.
ARC does not exist. We are implementing a GC, however, if the 
opportunity arises to allow an efficient implementation of 
interfacing with an external ARC platform, such as what is used 
in Objective C, discussion of that interfacing mechanism is 
permitted.
If DMD support is needed, it exists. This means that if the GC 
needs DMD to be capable of something such as scope analysis in 
order to make a particular optimization, then DMD should be 
assumed to be capable of doing that.
While language additions may be proposed, the design must still 
be able to function should the additions not be done, as the 
additions should only be to allow for additional optimization 
opportunities. For instance, re-introducing scoped class locals.



After all of that, I intend to include a base draft of the design 
of the GC, along with opening the PRs and committing the starting 
API. So, is there something I’m missing? Am I overlooking the 
obvious? Is there a more practical way to produce the same 
results?