dmd 2.068, 2.069, 2.0xx Evil Plan going forward

[Jonathan M Davis via Digitalmars-d]

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.068 - resolve remaining regressions and release
>
> 2.069 - translate to D. No new features, no refactoring. Only 
> regression fixes and what's already in HEAD. This should give 
> us a solid baseline. It also means that open PRs that address 
> other issues will not be pulled for 2.069.
>
> Perhaps we should name this 2.100, to signify such a milestone.
>
> 2.101+ -
> 1. Take advantage of D features to improve quality.
> 2. Go to full lazy semantic analysis of imports, rather than 
> the current "analyze them all"
> 3. Rethink what "speculative instantiation" of templates means 
> so we can have a coherent process of compiling them.
> 4. Redo CTFE interpreter so it only rarely needs to allocate 
> memory. This was already done for constant folding, but now 
> it's time for the rest of the interpreter.
> 5. Get rid of reliance on the global error count. This has been 
> mostly done, it just hast to be finished.
> 6. Convert the back end to D as well.

It'll be fantastic to get a lot of that done. The CTFE 
improvements in particular are likely to be huge. It'll be 
interesting to see how much faster some of the compiler 
improvements will get done once we don't have to worry about 
maintaining it in C++ anymore.

One big item that we've never quite managed to get far with is 
removing opEquals, opCmp, toString, and toHash from Object:

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

Without that, attributes on classes are kind of borked - 
particularly with regards to const. As it is, druntime is 
violating the type system by casting away const to compare const 
Objects.

Making that work without breaking code is going to require some 
changes in both dmd and druntime (probably including the work on 
AAs that Martin's been working on), and it'll likely be fairly 
interesting to pull off, but I think that it's pretty clear that 
we need to find a way to do it if we don't want classes to be too 
restrictive with regards to attributes - both with regards to 
which ones are permitted and which ones are required.

- Jonathan M Davis