Does D have too many features?

[F i L]

On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
> Andrei and I had a fun discussion last night about this 
> question. The idea was which features in D are redundant and/or 
> do not add significant value?
>
> A couple already agreed upon ones are typedef and the cfloat, 
> cdouble and creal types.
>
> What's your list?

First, I completely agree with some points already made here, and 
I completely disagree with a few others.

A modern compiler should be as powerful and convenient as 
possible, I completely disagree that a compiler can't do a broad 
range of things very efficiently _and_ with a smooth learning. 
Indeed this is what attracted me to D in the first place, the 
idea that it has the low level power of C++ when you get down to 
it, but it's also attractive and initially easy to use.



What I think should be removed/changed:

- Drop is( ... ) and extend "__traits()" (however "__traits" 
should become .metaof or something along those lines). Also, a 
easy to understand traits lib should be imported by default like 
Object.d

- Enum as manifest constant - I agree, this is better as "static 
x = 10" or equivalent. I was actually confused at first when I 
realized enum's where what was *supposed* to be used for that.

- foreach_reverse. Dmitry's gave a good alternative. Though, I 
think a more intelligent 'foreach' (or even 'for') statement 
could address this as well. Something like:

     for (key, value of range, step) {
         ...
     }

     // Where step values which can be deduced at compile time
     // are used to produce the most optimizated code.

- version statements - this would be a lot more consistent as a 
static if() I think. But it does need a more obvious syntax, 
possibly something like:

     static if ("foo" in Compiler.flags) {
         ...
     }

- .di files - I agree with foobar here. Other language have had 
this for awhile, and it makes linking a much easier concept.

- NaN as default - I've said this before on here, but I think it 
deserves being said again. FP values defaulting to Nan is a 
debugging feature, and should be explicitly expressed in areas 
which need to guarantee a variable is set after declaration. A 
useful, and consistent default should be used instead. Ints (the 
other number type) default to zero, and because zero is the most 
practical and commonly understood, FP values should start here as 
well.

- commas - should be use for tuples and parameters, not as ending 
marks:

     int, int foo() { return 5, 6; }

     auto x, y = 2;    // x = 0, y = 2
     auto x, y = 2, 3; // x = 2, y = 3

     x, y = foo();     // x = 5, y = 6



What should stay:

- foreach (or an intelligent 'for' as exampled above). This is an 
incredibly convenient, tried 'n true feature.

- built-in Associative Arrays - one of D's sexiest features. It's 
very useful for many things, and always having it at your 
disposal is a logical choice.

- properties - another incredibly convenient feature. I think a 
more sexy implementation of properties are in order, but the 
construct is great. It would be nice to have properties as a 
language type, rather than a attribute:

     struct Foo {
         property int x { get; private set; }
         property int y {
             get()    { return x; }
             set(T t) { x = t; }
         }
     }

     // Or the syntax could follow Types:

     property x : int { ... }

     // Which could be templated:

     property y(T = int) : int {
         static if (T.isType!int) {
            ...
         }
         else {
            ...
         }
     }

- with statement - no reason to kill it really and it's useful in 
some places. Helps keep code short and readable.

- Anonymous class - There's no reason to remove this feature, 
it's not hurting anyone and it could allow for interesting 
frameworks similar to jQuery.



Other things that would be cool:

- static foreach