Why I (Still) Won't Use D

Walter Bright newshound1 at digitalmars.com
Thu Mar 27 18:12:27 PDT 2008


Michiel Helvensteijn wrote:
> Walter Bright wrote:
> The implementation may be the same. The difference is in the interface.
> std::basic_string<T> can concatenate, convert to c_str, find and extract
> substrings, etc. More importantly, it is well-behaved when sent to a
> stream.

And why would one never want to concatenate arrays? Append a 0? Extract 
a sub-array? These distinctions are without a difference.


> std::vector<T> is meant as a container for any type, and has iterators, push
> and pop functions.

Bah, why cannot one iterate over the contents of a string? Why cannot 
one append a character to a string?


>> I was motivated in D to make the string type good enough to not motivate
>> people to invent string classes.
> What's good enough now may not be good enough in the future. And what's good
> enough for you may not be good enough for other programmers.

Since D string is better than std::string and Java.lang.string on just 
about every aspect, it's hard to see how it's not good enough.

> By hard-coding certain behaviors in the core language, you've taken away the
> freedom of the programmer to choose these hirself. Like the growth-rate of
> dynamic arrays. Or the sorting algorithm used by the .sort property.

See Andrei's sort routines in std.algorithms. I don't think user 
extensibility is crippled at all.

> Or the
> datastructure returned by the .keys property of associative arrays.

The way AAs are implemented does not solve every issue with containers. 
But they are so convenient to use, and work well enough, that there just 
isn't enough juice left to make it worthwhile to do other container types.

> I would still like to hear your views on my "library defines T[] and T[U]"
> idea.

I just don't see the utility of it. It's often nice to have core 
features that are always there, always work, and always work across 
implementations, and 3rd party libraries will interoperate and they 
won't have to reinvent the wheel. Sometimes ubiquity is far more 
valuable than an extra erg of features or performance.



More information about the Digitalmars-d mailing list