On Wednesday, November 28, 2012 07:44:39 Andrei Alexandrescu wrote: > On 11/28/12 3:01 AM, Jacob Carlborg wrote: > > TDPL was release way, way too soon. It was written before many of the > > features were even implemented. Then at a later stage "Whoops, this > > apparently doesn't work, we need to break TDPL". > > I disagree. Aside from a few details, the language described by TDPL is > implementable. The problem becomes when TDPL gets in competition with > incorrect code that currently compiles and runs although it shouldn't.
That's mostly true, but there are some features which have required further ironing out even if TDPL is mostly correct about them still (e.g. pure and shared), and some features _still_ aren't properly implemented (e.g. synchronized and alias this). I'm not about to say that TDPL was released too early (it's been a _great_ resource and has undoubtedly helped the community grow), but at the same time, it doesn't quite represent what the language actually is, and we're slow at catching up with it. So, in that sense, if TDPL is meant to be a definitive resource, it would have been nice to have the implementation be closer to where TDPL is before having released it However, a _big_ benefit from having not delayed its release was that that a lot of stuff stopped changing after that. We stopped making huge, incompatible changes from release to release of the compiler. We didn't stop making breaking changes, but for the most part, we stopped trying to design the language and instead have focused on finishing implementing it. All of the design work that has happened since then has either fixed a pressing problem caused by the current design (e.g. weak purity) or introduced new, compatible features (e.g. SIMD). We're no longer doing stuff like changing how operator overloading works just because we came up with a cooler, better way to do it. - Jonathan M Davis