== Quote from Brad Roberts ([email protected])'s article > dsimcha wrote: > > D2 is a complex language, but it's not complex in a haphazard way. It's > > complex > > because it statically proves stuff about your code (const, etc), and allows > > extremely powerful, generic user-defined types. These are the kinds of > > things > > that most people only dream about. > I'd like to drill into this 'd2 is a complex language' assertion more. Can we > build a factual list of the delta of complexity between d1 and d2? > The primary area is the type system: > 1) introduction of const > -- optional and doesn't affect callers of api's that declare const > params > 2) introduction of immutable > -- less optional since it's not as coercable, but also less frequently > used in apis. > 3) introduction of pure > -- optional, will not affect callers of apis > 4) introduction of nothrow > -- optional, will not affect callers of apis > Others: > 5) template if clause > I'm specifically leaving out Phobos and other library layer issues, though > feel > free to count the runtime as part of the language when adding to this list. > -- Brad
Template alias parameters, ref returns, shared (even though it's not implemented, it's on its way, so it still counts), closures, alias this, template literals, struct ctors and dtors (and in general structs becoming more like classes) to name a few. I love all of these, and I personally think the complexity is justified. It's just that I don't know how easy it would be to convince someone coming from Java of this, so I'm playing devil's advocate a little. On the other hand, I do see a pattern here: Most of these features are things you only need to care about if you're writing near the tip of the pyramid, stuff like generic, reusable code. In fact, I've realized that my mindset when coding in D is completely different when working on something that aims to be extremely generic (like rangeextra or dstats, stuff I wouldn't even be able to do in any language besides D) vs. when working on day-to-day code that just has to solve one problem well. The latter is a lot easier, but also a lot less fun, from a programming perspective.
