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

[Lars Ivar Igesund]

Tony wrote:

> "Walter Bright" <newshound at digitalmars.com> wrote in message
> news:e8n9mi$2flp$1 at digitaldaemon.com...
>> Kyle Furlong wrote:
>>> *Standing Ovation*
>>
>> Yeah, that's concerned me as well. But it isn't just me trying to make
>> it perfect, everyone's got their favorite bug/feature that must get in
>> before 1.0.
>>
>> So what do you say we just call D right now *1.0* and move on? It's not
>> like D will stop undergoing improvements.
> 
> I've taken the liberty of making this a new thread as the old one was
> getting a little long.
> 
> Walters post raises the issue of exactly what criteria should be used to
> determine when D reaches a state suitable for a 1.0 release.
> 
> My personal take is that it should be a 1.0 release when Walter believes
> that all of the language changes which are expected to break existing code
> have been made.  For example, if he expects to add any further reserved
> words, reserve them (even if not presently implemented) prior to the 1.0
> release.  Also, any change which alters the semantics of an existing
> feature and thus breaks existing code should be made prior to 1.0.
> 
> This still leaves bug fixing and additional language features which don't
> break existing code for post-1.0 releases.
> 
> Tony
> Melbourne, Australia

With the latest posts on template issues (some are labeled bugs, some are
labeled 2.0), I believe there are two major problems with the current
implementation and/or specification (and a whole bunch of niggles, but
those might just qualify as bugs):

 - The const issue
 - Visibility and accessibility rules

I think both are far from being able to be labeled as "just bugs", and if
any of them are fixed with steel wire and strong tape, then they will be
revisited with double strength post 1.0 release.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi