dsimcha wrote: > == 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.
I'm going to play devils advocate too... struct ctor/dtor's are simplifiers. They remove a hard to explain difference and aren't even a little bit hard to understand. I'm tempted to say the same about ref return, but we can leave it in the adds column. The rest I'll agree with (at least enough not to quibble much). -- Brad
