DIP66 has been approved contingent to a few amendments as noted

[eles via Digitalmars-d]

On Sunday, 28 December 2014 at 12:10:15 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:
> On 24/12/14 15:27, eles via Digitalmars-d wrote:
>> D2 is still looking for the best design. D1 has one, is not as 
>> good, but is a
>> safer default.
>
> Honestly, developing in D1, I personally feel that this is not 
> so much a stable version as a frozen snapshot of a 
> still-evolving language.

Yes, because D1 is just that. It was already a D2 in the making 
at that time and D1 was stopped not because it has reached a 
significant milestone, but simply because Andrei bet everything 
on D2 and wanted all resources concentrated on it.

But D1 might be dead, the question of stability s experiment 
remains.

As Ola wisely observed, the debate is not about D1 per sé, but 
about the moving target that one chases when (trying to) use(ing) 
D.

Instead of D1 and D2, think D2 and D3 or, if you like, stableD 
and experimentD. Place the border between them wherever you want, 
but before changing the paradigm of memory management.

In the original comment to which I replied with the proposal of 
D1 back again, the trigger was "different build". Just re-read 
that post and replace D1 with "different (aka stable) build" and 
re-shape the ideas accordingly.

Why that? Well, as Walter stated several times, using a new 
memory management technique is not only about having a new 
compiler and memory management mechanism. It is also (and mainly) 
about *coding style*. When developing for a GC-based language, 
one makes some assumptions and writes some code accordingly. When 
developing for a RC-based language, one writes *different* code. 
And when writing for MM-based language, one structures and writes 
another kind of code.

Thing is, by now, most of D2 code that is written is GC-centric. 
Supporting that to at least the same level of performance, while 
making sure the impact of the new changes that should allow RC 
and MM techniques, along with the work on a 
precise/concurrent/performant GC, while letting room for the new 
memory paradigm to provide optimized code (and not asking changes 
in the coding style)... is too much.

Even much too much given the other untied knots that D has: from 
properties, multiple aliasing this, re-definition of "scope" and 
C++ compatibility. I am sure there are others too.

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? Now oua re introducing -dip= flags, which could 
work as long as they are orthogonal with existing code but... for 
how long and how? Will every project come with a .ini file that 
will list the dips that are necessary for that project to work?

"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"?

What about tying up the current issues that keep running in 
circles, a lot of eternally to be deprecated features and so on? 
They will be let for 2025? Will drag properties issues and the 
others (*complex types, anyone*?) until then?

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!

> Now, that said, in practice D1 does feel for the most part very 
> much like a subset of D2 features; you could code a new project 
> in D2, using the same design principles, and have pretty much 
> identical results.  So it's entirely fair to see a D success 
> story here.

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

> With more historical resources, it might have been sane or 
> possible to backport some of the relevant breaking changes -- 
> that is, to have a D1.5 with the same reduced feature set but 
> with the inconsistencies and bad design decisions ironed out -- 
> but now that D2 has reached its current state, it doesn't seem 
> worth it to me.

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!".

Everybody keeps replying with "that was then and a decision was 
made back then!". I am saying "hey! this happens again!".

> I suppose that we could, today, divide D2 into a guaranteed 
> stable subset and a wider range of features whose final design 
> is still up for discussion, but even that seems non-trivial: 
> cf. the kerfuffle over whether class methods should be virtual 
> or final by default.  (And no, please don't take this as a 
> reason to re-open that discussion.)

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. This way, what about 
adding some new flags like "-java", "-csharp" and 
"-c++1zwithconceptsliteandmodules"?

The only thing that those flags will have in common with D and 
with each other will be the fact that they are all braces-family 
languages. That, and nothing more than that. (yes, yes, it's an 
exaggeration).