Is DMD 0.166 RC 1.0?

[Kristian]

I agree.
Especially things that will/could break backward compability should be  
considered now. (Later these things are of course harder to change: 1) it  
cannot be done, 2) it'll break backward compability (e.g. 1.0 code doesn't  
compile with 1.1), and 3) old syntax (marked as obsolete) exists parallel  
with the new one.)

On Mon, 04 Sep 2006 00:01:27 +0300, Chad J  
<gamerChad at _spamIsBad_gmail.com> wrote:
> Walter Bright wrote:
>> Any compelling reason why not? I know that everyone (including me)  
>> wants more features, more improvements, etc., but nothing about calling  
>> it 1.0 will prevent that from happening.
>
> Firstly, I don't think things like fancy delegates with functional  
> programming are very important for 1.0.  They are cool, but can wait.
>
> I see some things that should be implemented before RC1 for backwards  
> compatibility reasons, like auto and constness.  There is a way around  
> that for the most part though:
>
> I would like to see an experimental branch before seeing an RC, sort of  
> like Gregor suggested.  Not a branch of the compiler, but a branch of  
> the spec.  Features that are not stable or not implemented yet would  
> fall into this experimental branch.  There would be a singular DMD that  
> conforms to this spec, with the realization that any feature from the  
> experimental part of the spec my change in the next release.
>
> Here are some things I'd expect to see in the experimental spec:
> - Lazy delegates // very new stuff
> - auto // due to auto auto, this will get changed sometime right?
> - array operators // not implemented yet
> - common func ptr/delegate syntax // not implemented yet
> - IFTI // not fully implemented
> - mixins // I've read complaints about the usability of mixins
> and so on...
>
> It may even be nice to have a couple phases of experimental spec, like  
> an alpha spec and a beta spec.  The alpha spec contains things that will  
> most likely change, and the beta spec contains fairly stable features  
> that are yet to be time-tested.
>
> This would allow 1.0 to roll out without some of those things I've  
> listed being addressed.  I don't think those features I've mentioned as  
> experimental spec candidates are super important.  The only reason we  
> worry about some of these, like auto auto, are for backwards  
> compatibility.  But with an experimental system, coders are prewarned,  
> and backwards compatibility isn't too worrisome.  Still, something like  
> constness still bugs me even with experimental spec, since it could  
> change very basic things about the language.
>
>
> If 1.0 isn't a publicity thing, then disregard the below.  These assume  
> that many new programmers will be trying D when a 1.0 release happens,  
> and will need impressing.
>
> Another big problem I see with RC1 - Access violation.  If there is  
> going to be a mob of people trying D at 1.0, then the compiler should  
> behave nicely, and not produce programs that produce 'access violation'.  
>   This seems very tacky to me.  It turns a 30 second code correction  
> into a 10+ minute debugging session, ouch!  At least put line numbers on  
> those things.  Bonus points for decent descriptions of what went wrong.
>
> Also related to mobs of people trying D at 1.0 - the spec needs going  
> over with a fine tooth comb.  This seems to be going on already, which  
> is good.  The spec's coolness would go up a few notches if there was a  
> spec-only keyword search option.  Do this *before* 1.0.
>
> Phobos.  Maybe this can wait, but perhaps we should at least do some  
> work to phobos' interface?  Make sure the naming is consistent with the  
> D style guidelines.  It needs a *simple* way to read input from the  
> console, and not some std.c.crap.  Also, 'atoi' (in std.string) is a  
> horrible name for a function that turns a string into an integer, and we  
> have overloading now, unlike C back in the day, so make it 'toInt'  
> (which exists in std.conv, so why the dupe?).  This shouldn't be a big  
> effort to expand phobos' functionality, just a time where we break  
> everyone's code and deal with it so that future D programmers don't have  
> to.  Adopting another library like Ares as standard and tweaking on it  
> should work too, though I see that as harder to pull off.