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
