Discusssion on the Discussion of the Design for a new GC

[Joakim via Digitalmars-d]

On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
> 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?

Wow, this takes the D forums tradition of "all talk, no code," or 
as the original saying goes, "all hat, no cattle," to a new peak. 
;)

I think most would agree with you on most of these guidelines, 
better to get onto the actual design.  It might help if you put 
forth a tentative proposal, that the D goons can then proceed to 
destroy... I mean, critically evaluate.