On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
On 29.04.2012 0:57, Timon Gehr wrote:
On 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
On 28.04.2012 22:47, 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?


1. Drop is(...) feature entirely. Extend __traits where needed and move
compile-time reflection to "magic" meta namespace completely.

2. "enum as manifest constant". Use static or immutable/global.

static is not accessible at compile time, would you want to change that?
immutable is not an option because it infects the type.

Oops, scratch that comment about static/immutable.

But how about:
alias thing = runSomeCtfe();


That would work in certain cases, where the initializer is not a single symbol. But then, I kinda like the way 'enum' is generalized in D:

enum Foo{
    member1,
    member2,
    member3,
}

=> (allow non-integral enumerations)

enum Foo{
    member1 = "1",
    member2 = "2",
    member3 = "3",
}

=> (anonymous enums)

enum{
    member1 = "1",
    member2 = "2",
    member3 = "3",
}

=> (a single member is okay)

enum{
    member1 = "1",
}

=> (syntactic sugar)

enum member1 = "1";

And bring the usual alias to new_name = <something>;
form (even C++ finally got this right with C++11 aliases).


This is probably something that should be done.

I actually think D is not too large.

For what it does - surely not. But in general it's big.
For one it's not smaller then C++.

I am not sure how to compare, but D 'feels' smaller than C++ to me.

Implementing a compiler is probably harder for D, because of the interplay of forward references, CTFE and compile time introspection.


Reply via email to