Is DMD 0.166 RC 1.0?

[Chad J]

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.