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.
