On 29 April 2012 01:09, F i L <witte2...@gmail.com> wrote: > 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 >
Hear hear. I completely agree with everything you just said.