Last update January 22, 2007

Doc Comments /
builtins

Core Language Features vs Library Implementation

Messages

Add your comments here...

Introduction

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

Dynamic Arrays
Strings
Associative Arrays
Complex numbers

The topics of "unit testing" and "contract programming" come to mind as well. Probably others, too? (One might even include that the pre-processor is built-in to D, with the version/debug statements?)

Dynamic Arrays

Re "the need for each of these variations just evaporates. There's one array type that covers it all"...

I don't think this is entirely true in the case of some of the variations listed. Most importantly (IMHO) a one-size-fits-all builtin array can't offer a coder the space and complexity choices that C++'s library can. F'rinstance, a builtin array type can offer compatibility with C arrays (like vector), or it can offer constant-time front insertion (like deque). It can't offer both.

Which needn't be a problem, provided D supports efficient and syntactically-consistent user-defined container types. But it's better to underpromise and overdeliver than the other way around.

The example for the "alternative" associative arrays is not realistic. The package std.associativeArray and the full name std.associativeArray.AA should be replaced with something more reasonable like std.array or std.map or something. And the full name shouldn't be needed in the code unless there is a symbol conflict (which is usually unlikely).

Complex Numbers

The most compelling reason is compatibility with C's imaginary and complex floating point types. Next, is the ability to have imaginary floating point literals. Isn't:

	c = (6 + 2i - 1 + 3i) / 3i;

far preferable than writing:

	c = (complex!(double)(6,2) + complex!(double)(-1,3)) / complex!(double)(0,3);

? It's no contest.

Actually, I find the lack of syntactic sugar for precedence in this example a bit disturbing, as it might lead to abiguity.

Unless 6 + 2i - 1 + 3i is equivilent to 6 - 1 + 2i + 3i, which would be 5 + 5i, you should require parens to visually separate the higher precidence complex "+" from the standard addition/subtraction precidence. I'd suggest require using parens, (6 + 2i) - (1 + 3i), as programmers are used to that anyway. (Some might suggest that braces might be more appropriate.) It may not be a technical problem in the compiler to handle the different meanings and precidence of "+" based on the right-hand-side being pure imaginary, but in more complex expressions, the programmer might mess up the grouping in unexpected ways.

Note that raw imaginary values, like 3i, would not require parens. Initializations, such as "complex c = 5.1 + 3i;" would be allowed, as the compiler can treat that as a constant expression adding a real and imaginary quantity, promoting the real to complex before the addition.

(Huh? 6 - 1 + 2i + 3i IS equal to 5 + 5i!)

Links

Corresponding page in the D Specification