On Sat, Apr 28, 2012 at 09:58:02PM +0200, foobar wrote: [...] > D has a lot of ad-hock features which make the language > needlessly large and complex. I'd strive to replace these with > better general purpose mechanisms. > > My list: > * I'd start with getting rid of foreach completely. (not just > foreach_reverse). This is nothing more than a fancy function with > a delegate parameter.
I disagree. Having a dedicated foreach construct allows the compiler to optimize away the delegate in certain cases. I wouldn't want to incur the cost of creating and passing a delegate in something as simple as foreach (i; 0..100), for example. > * enum - enum should be completely redesigned to only implement > what it's named after: enumerations. Actually, I rather like the enum idiom of declaring compile-time constants. Though it could do with a renaming to something more befitting. > * version - this does not belong in a programming language. Git > is a much better solution. This is an interesting idea. But using separate git branches just for having versioned code seems a bit like total overkill... plus a maintenance nightmare since you have to continue pull and merge changes to every porting branch every time development happens. Whereas having everything represented in source means that whoever writes a new feature is also responsible for making it work with whatever versions are currently out there. After-the-fact fixes are always painful. > * di files - a library should encapsulate all the info required > to use it. Java Jars, .Net assemblies and even old school; Pascal > units all solved this long ago. I proposed a while ago that .di files should be replaced by something better: omit ALL function bodies, template bodies, private members, etc., and just keep the "real" public API in the human-readable part of the file. Function and template bodies should be kept in as a binary blob readable by the compiler (which obviously needs to know them otherwise it won't be able to expand templates). (Yes the binary blob can be reverse-engineered, but so can executables, so it's a moot point. We're not trying to write cryptographic security here, but it's nice to separate what the compiler needs to know vs. what the user of a library needs to know.) > * This is a big one: get rid of *all* current compile time > special syntax. It should be replaced by a standard compilation > API and the compiler should be able to use plugins/addons. This > would reduce the size of the language to half of its current > size, maybe even more. I have to disagree here. CTFE and compile-time features is a major reason I like D. I argue rather that compile-time features should be *improved*. The current situation is good, but not quite there yet. It can be made better. T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
