When will D1 be finished?

[grauzone]

Walter Bright wrote:
> Derek Parnell wrote:
>> D1 is not complete. That has nothing to do with the bugs it still 
>> contains.
>> It is not complete because there is documented functionality for which no
>> implementation has yet been attempted. This assumes that the 
>> documentation
>> is complete and accurate.
>>
>> The D-Team should be dedicating resources to ensuring that the D1
>> implementation and D1 documentation are in alignment with each other. By
>> dedicating, I mean that is all that this D1-subteam of the D-Team work 
>> on -
>> no D2 work at all. Any D1 fixes that need to be propagated to D2 
>> should be
>> done by the D2-subteam. Priority should be given to getting D1 completed.
> 
> Please help me understand - why is contract inheritance preventing you 
> from using D1? Exported templates haven't stopped anyone from using C++ 
> compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a 
> feature complete C99 compiler, either.

That's mainly because the language was designed by a committee, and not 
by a compiler author and his followers, isn't it? But you have full 
control about the language specification. If there are D1 features 
you're not going to implement, they simply should be removed from the 
language specification.

>> Unless of course, D1 is just a prototype for D2 and will thus be 
>> discarded
>> the instant that D2 is released.
>>
>> What are the support plans for D1 after D2 is released? (I consider 
>> current
>> D2 releases as beta editions at best).
> 
> D1 will continue to be supported as long as there is a significant 
> userbase for it. I've said this many times.
> 
> I also fail to understand this perception that D1 is abandoned. Every 
> month an update is released for it that fixes a load of problems. D1 has 
> led the way in ports to other platforms.
> 
> What isn't being done with D1 is adding a boatload of new features - 
> because that would destroy any pretense of it being a stable release.

That's because we don't really know what we want. You gave us D1, but it 
turns out it's not really what we expected it to be.

On one side, D1 users want a stable language. That means they don't want 
to update their code with each compiler release. I think D1 reached this 
goal. Or, at least it's getting better.

On the other hand, we don't want to rely on a dead end. We don't want to 
put up with some trivial issues, that were solved in D2, but will stay 
in D1 forever. For example, D1 will never be able to support proper 
serialization, just because it lacks __traits(). That specific thing 
would (probably) be easy to port back to D1, and it wouldn't break any 
existing code.

I know, you're saying introducing new features goes against stability. 
But it makes D1 frustrating to use. Everyone feels it's a dead end, and 
that you shouldn't rely on it. In the end, it might be rock-stable, but 
nobody wants to use it. Because it will still have some problems, which 
were solved in D2. D1 will simply vanish in some time.

Now you could say, "If you want new features, use D2. If you want 
something stable, use D1. But the gap is simply too big: do you stick 
with the dead end D1, or with the heavily changing D2?

The worst thing is, you can't really interface between D1 and D2. So you 
can't use it, if you're using the wrong D version. Or the library tries 
to work under both D versions, which makes maintenance harder and bloats 
up the code. This just causes endless pain.

I propose the following:

Make D1 open for new features again. As soon as backward compatible 
features get mature and stable enough in D2, add them to D1 too. To 
prevent regressions, use the test suite. A new version of the compiler 
will only be released, if the test suite doesn't report any new regressions.

D2 will be bleeding edge. It will not need to care about _any_ breakages 
new versions might introduce. Right now, this isn't really possible, 
because there are people using D2 for "useful" stuff (instead of using 
D1). With the change, D2 would be a truly experimental testbed, and not 
the pseudo-stable "next generation D" it is today.

 From time to time, allow breaking changes to D1. It isn't really worth 
to maintain ancient versions of the compiler, like D1 will be if D3 is 
out. If someone doesn't want to deal with the breakages, he has to use 
an old compiler version. A steady transition in small increments is 
probably still better than requiring a user to do a D1 -> D2 sized 
switch all some years. While the former may require annoying but trivial 
fixes to the source code, the latter will always be a nightmare.

But I don't really know what to do with breaking changes, that are just 
too big. Like const or the new threading model. Everyone, you just 
wasted your time reading this posting.