Why I (Still) Won't Use D

[bearophile]

Benji Smith:
> Const is a total trainwreck, and is the biggest reason for me to stay 
> away from D in a real project.

Now You can use D 1.x. And I think that eventually D developers will understand that the current const regime may be not practical enough.


> The existence of three different string types (six, if you count 
> const/mutable variations of each) makes text-processing more difficult 
> than it ought to be.
> I would have liked to see just one string type, with encoding kept as an 
> internal implementation detail. And I'd much rather have a string class 
> than to treat strings as character arrays (especially since 
> indexing/slicing deals with code-points rather than character positions).

I think Python 3.0 (despite being a very different language with quite different purposes) shows a good solution: a (probably mutable) byte array (or maybe two of them, one mutable and one immutable) plus an unicode (immutable) string class. Those two are probably enough for many situations.
But currently on 32 bit systems an empty string is a struct that needs 4+4 bytes only, while a string class probably requires more, it may be slower, etc.


> The mandate to keep keyword count as low as possible has been a real 
> detriment to the language.
> Each unique concept should have its own unique keyword.

I agree. I am not scared of more keywords, if they help keep the language more clean.


> 1) There's a gap in functionality between static arrays (whose size must 
> be known at compile time) and growable dynamic arrays.

Their semantics is a bit tricky, try to loop on an AA with static arrays as keys, etc.


> Most often, what I really want is a non-growable array whose size isn't 
> known until runtime, but D doesn't have that concept

You can create such "concept", it's not too much difficult to write such class/struct. I have already done it, TinyVector, a struct that you can use that is useful when running speed is the most important thing.


>I also would have preferred to have growable arrays and associative arrays in the standard library than in the language.<

Having a built-in AA is really useful in many situations (but I agree it has some downsides too).


> I don't want to memorize a bunch of loopholes. I want a straightforward
> language that makes sense, right out of the box.

Even if no one has answered my post:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=68070
It seems you are saying the same thing: the most important thing for D now is probably to reduce the number of its corner cases.

Bye,
bearophile