Why I (Still) Won't Use D

[Vladimir Panteleev]

On Thu, 27 Mar 2008 19:26:35 +0200, Benji Smith <benji at benjismith.net> wrote:

> STRINGS
>
> 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 don't think this is suitable for a high-performance, Unicode-ready, system programming language. UTF-8 is used most commonly as it's the most space-efficient; UTF-16 is good for OSes which use it or wide strings (e.g. Windows NT); UTF-32 is used where quick indexing is required. Having a "black box" string type which does all these conversions "on-demand" does not fit in with D, IMO.

> 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).

Something like this would either be performance or memory-inefficient in most cases - it can be done by:
1) storing the string using the smallest character type that can fit any of the characters in the string (example implementation: http://www.dprogramming.com/dstring.php ) - this can cause reencoding as you add data on the string, and a large text with just a few Unicode characters can take up almost 4 times as much as the UTF-8 version
2) scanning the entire string on each index - slow indexing
3) keep some lookup tables to speed up 2) - not as slow but requires additional memory

Doesn't look like a panacea to me :)

> KEYWORD OVERLOAD
>
> 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.

D is quite a feature-rich language... I'd imagine it would get quite difficult to find simple, memorizable and unique keywords for every new feature without introducing new syntax (using non-word characters).

> what I really want is a non-growable array whose size isn't known until runtime

What advantages does a reference-type non-growable dynamic array have? Or you mean a value-type array, which will get copied on every assignment?

>   // Inplicit conversion. Does this copy data?

Dynamic arrays are reference types, slices of memory; no data is implicitly copied. 

>    // Error: functions can't return fixed-length arrays!

I agree that this is silly and should be fixed; wrapping the static array in a struct works anyway.

>    // Doesn't compile
>    char[][] words = [ "hello", "world" ];

You probably mean the issue when the strings are of different length:
    char[][] words = [ "hello", "world!" ];

Agreed - the compiler should detect that and choose the type not just based on the first element.

> 2) An empty array is equal to a null pointer. Yikes!

Could you bring a practical example of where this is a problem?

-- 
Best regards,
 Vladimir                          mailto:thecybershadow at gmail.com