DIP66 has been approved contingent to a few amendments as noted

[Joseph Rushton Wakeling via Digitalmars-d]

On 28/12/14 21:08, eles via Digitalmars-d wrote:
> Thing is, by now, most of D2 code that is written is GC-centric.

With some exceptions (e.g. embedded programming), the assumption of a GC isn't 
so much a problem as the fact that too many parts of Phobos have been written in 
a way that doesn't allow you to avoid generating garbage (e.g. by passing in 
preallocated buffers or suchlike).

> And you charge this already unstable state with a new mechanism of memory
> management that is yet to be designed, not to say about being written?

I'm really not sure who this "you" is that you're talking about.

> "This project is not written in D1, but in D2+dip63,+dip45+dip119v3,+dip23 and
> incompatible with dip22 and dip99. For best performance we recommend disabling
> dip67 and use the dmd source version 2a2b3c4ddf2a"?

... will only happen if the project is slow about reviewing implemented DIPs. 
To my mind it would be a pretty bad show if any one -dip flag hung about for 
longer than a couple of compiler releases.

> Don clearly stated in one of hist posts: "keeping deprecated features has a
> cost!". It works for one of the most successful stories in the D world. Guess
> its name? Sociomantic!

I think you might want to do a bit more research into the context and concerns 
behind Don's remarks, before you cite Sociomantic as an argument for keeping 
deprecated features :-)

> Except that porting this subset to its own takes quite some time for
> Sociomantics...

Porting a large codebase, with high performance requirements, through a large 
number of breaking changes, many of which cause silent changes in program 
behaviour ... it's going to take time.  It would be much more straightforward to 
port a codebase through a sequence of individual, well-defined breaking changes.

> I agree with that. But the point is, D2 has been also reached a state where is
> too much on its plate in terms of contradiction between "be-production-ready!"
> and "be-innovative!". Not even to say "clean up all the dark corners!".

I don't think that well defined, well signposted breaking changes are an issue 
for production code (actually, they are quite welcome if they provide a 
meaningful improvement).  They're more an issue for unmaintained code.

> No, I do not start that discussion. Thing is, you cannot add zillions of flags
> that basically make you jumping from a language to another every time that you
> compile code.

I don't think I or anyone else was suggesting that.