When will D1 be finished?

[Leandro Lucarella]

grauzone, el 12 de mayo a las 02:24 me escribiste:
> >>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.

This is exactly my feeling.

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

My suggestion is to accumulate some new features in a new "minor" D1
version, like D1.1, release some betas, and release a D1.1 stable. D1.1
should no receive new features by then, but D1.2 should be started
receiving new features. Python works this way, and is a very stable *AND*
evolving language. Something that apparently Andrei and Walter think it's
not possible to have.

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

That's exactly what I've suggested some time ago, I even started a Wiki
page for this with a proposed roadmap:
http://www.prowiki.org/wiki4d/wiki.cgi?D1XProposal

> But I don't really know what to do with breaking changes, that are just
> too big.  Like const or the new threading model.

I think that should be kept as D2. Because programs needs a major rewrite
to be ported to D2, not just some cosmetic name changes (caused by a class
rename or a new keyword that you used as a variable name).

> Everyone, you just wasted your time reading this posting.

Not the first time, not the last time... =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------