D Builtin Rationale

D offers several capabilities built in to the core language that are implemented as libraries in other languages such as C++:

1. Dynamic Arrays
2. Strings
3. Associative Arrays

Some consider this as evidence of language bloat, rather than a useful feature. So why not implement each of these as standardized library types?

Some general initial observations:

1. Each of them is heavily used. This means that even small improvements in usability are worth reaching for.
2. Being a core language feature means that the compiler can issue better and more to the point error messages when a type is used incorrectly. Library implementations tend to give notoriously obtuse messages based on the internal details of those implementations.
3. Library features cannot invent new syntax, new operators, or new tokens.
4. Library implementations tend to require a lot of compile time processing of the implementation, over and over for each compile, that slows down compilation.
5. Library implementations are supposed to provide flexibility to the end user. But if they are standardized, to the point of the compiler being allowed to recognize them as special (the C++ Standard allows this), then they become just as inflexible as builtin core features.
6. The ability to define new library types, while having greatly advanced in the last few years, still leaves a lot to be desired in smoothly integrating it into the existing language. Rough edges, clumsy syntax, and odd corner cases abound.

More specific comments:

Dynamic Arrays

C++ has builtin core arrays. It's just that they don't work very well. Rather than fix them, several different array types were created as part of the C++ Standard Template Library, each covering a different deficiency in the builtin arrays. These include:

• basic_string
• vector
• valarray
• deque
• slice_array
• gslice_array
• mask_array
• indirect_array

Fixing the builtin array support means the need for each of these variations just evaporates. There's one array type that covers it all, only one thing to learn, and no problems getting one array type to work with another array type.

As usual, a builtin type lets us create syntactic sugar for it. This starts with having an array literal, and follows with some new operators specific to arrays. A library array implementation has to make due with overloading existing operators. The indexing operator, a[i], it shares with C++. Added are the array concatenation operator ~, array append operator ~=, array slice operator a[i..j], and the array vector operator a[].

The ~ and ~= concatenation operators resolve a problem that comes up when only existing operators can be overloaded. Usually, + is pressed into service as concatenation for library array implementations. But that winds up precluding having + mean array vector addition. Furthermore, concatenation has nothing in common with addition, and using the same operator for both is confusing.

Strings

C++ has, of course, builtin string support in the form of string literals and char arrays. It's just that they suffer from all the weaknesses of C++ builtin arrays.

But after all, what is a string if not an array of characters? If the builtin array problems are fixed, doesn't that resolve the string problems as well? It does. It seems odd at first that D doesn't have a string class, but since manipulating strings is nothing more than manipulating arrays of characters, if arrays work, there's nothing a class adds to it.

Furthermore, the oddities resulting from builtin string literals not being of the same type as the library string class type go away.

Associative Arrays

The main benefit for this is, once again, syntactic sugar. An associative array keying off of a type T and storing an int value is naturally written as:

int[T] foo;

rather than:

import std.associativeArray;
...
std.associativeArray.AA!(T, int) foo;

Builtin associative arrays also offer the possibility of having associative array literals, which are an often requested additional feature.

Please Note

D currently has a built-in complex type that is being phased out in favor of a library implementation. Advances in D language semantics and compiler implementation have obviated the need for a built-in complex type.