Criteria for 1.0 (was: Re: If D becomes a failure, what's the key reason, do you think?)

[Tim Starling]

A few comments as an outsider and a latecomer to this thread.

I did "fall through the holes in the floor" as one poster put it, about 6 
months ago, when I ran into bug 8 on my second experimental project. I made 
the decision at that point to wait until the language was a bit more stable, 
which I judged would take a few years.

Personally I have never found visibility or const to be effective debugging 
tools. I would be quite happy if they were entirely ignored in an initial D 
release, optionally allowed for documentation purposes as a replacement for 
e.g. /*private*/, which is the effective access control keyword we used for 
years in PHP 4. Truly useful debugging tools are things like meaningful 
compiler error messages and exceptions. Or if you want a pipedream, a 
segfault handler which detects NULL pointer dereferences and converts them 
to exceptions.

If it's impractical to fix all bugs before a release, then allow the bugs to 
be documented as comments on the official documentation. That way the 
developer can avoid surprises. I think the documentation would greatly 
benefit from a more open editing model: put it on a CMS, give 20 people 
write access, and allow unauthorised comments on the same page. I could have 
easily avoided bug 8 if the linker issues were noted at the bottom of the 
std.boxer page.

Why is Walter the only person who ever fixes bugs in the compiler? This 
seems to slow the whole project down. Why not move the free frontend source 
to a versioning system and give 10 people write access? Then Walter can 
produce DMD binaries from the improved multi-developer source code, and 
everyone else can produce GDC binaries from the same source. Maybe some 
interfaces would have to be cleaned up, but I would think it would be well 
worth the effort, in the long term.

-- Tim Starling