Stewart Gordon wrote:
(a) having a spec that the public agrees to be complete and consistent
I think this is probably the most important of your points. Without a complete and consistent spec, there's no possible way to make a correct compiler. All features need to be in there, explaining how they should work in detail. This is a blocker for anyone who wants to write a D compiler currently, they have to go by dmd in some cases rather than the spec.
(b) all language features implemented
I think this is probably least important currently. Most (if not all) major features have been implemented in D1, and D2 is still in alpha so has no requirement for this.
(c) all of the most serious known bugs and most of the others fixed
This comes right after a complete spec on what I'd rate as important. While some of these bug fixes might be seen as "breaking changes" that shouldn't be in D1, I think we'll live. I know I'd rather have to update a load of code to comply with the spec than have a load of invalid code that works forever, even if it is a pain to update. I think frontend bugs should take priority here, as they effect all compilers that use it, not just dmd.
But generally, it's about time D1 got a move on....
Agreed. I've had trouble getting people to use D due to (mainly) those 3 rough edges. Having 3 year old unfixed bugs in the bug tracker doesn't help with persuasion.
...when we reach this practical milestone, maybe we could call it D 1.1?
I guess this is up to Walter. Would D 1.1 just be a milestone for D, or would it need a new spec? Maybe D 1.1 could be a fork of D1 which introduces the breaking changes and finalizes the spec? That way we don't have the issue of breaking D1.0. When it is complete D1.0 could be marked deprecated and D1.1 could take its place. Or of course the changes could take place in D1.0 and gradually introduce the breaking changes, making D1.1 the final result (or maybe just D1.098, however many revisions of the compiler it takes :P).
Robert
