Does D have too many features?

Dmitry Olshansky dmitry.olsh at gmail.com
Sat Apr 28 12:22:01 PDT 2012


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. Compiler 
should be smart enough to avoid putting immutable integers/doubles into 
object file as variables.

3. with statement (?). I kind of like it but bleh it's too boggy and it 
doesn't seem to pull its weight. (pointers? class references? a lot of 
stuff to go wrong) Fluent interfaces solve a good portion of its 
benefits to be specific.

4. foreach_reverse. Seriously let's kill this abomination. If it happens 
that foreach(x; retro(range)){...} is slower it just means compiler 
(inlining?) is no good and should be improved.

5. .tupleof looks like a hack. But I'd rather "refactor" than drop it.

6. Drop out arguments? There are tuples.
And auto (a, b) = getMeTwoThings();  is cleanerthan
<something> a, b;
fillTheseTwoThings(a, b);
// no indication whatsoever that a & b are modified heck even fn(&a, &b) 
in C is *better*
(ok no tuple unpacking for now but you got the idea)

7. I can live without homogenous varaidics. Since most of the time they 
readily progress to full-blown variadics that detect common type & 
forward things to an array version of function. Also given that 
sometimes people do things like:

this(int[] arr...)// ctor with cool syntax, yada-yada ;)
{
	this.data = arr; //boom! (pointer to stack-allocated stuff)
}

8. Something else. D is huge :)

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list