Language issues

Like any programming language, D is not perfect. This page lists some potential problems that have been brought up and debated throughout the language's history. Fixing these is not straight-forward or may not justify breaking backwards-compatibility. As of the moment of writing this, there are no plans for a major revision of D which would allow such breaking changes, but this list may also be useful for other programming languages which wish to learn from D's experience.

See also: Language design discussions

Properties

Design of properties has been an oft-discussed topic. This language feature has evolved throughout D's history (e.g. the addition and removal of the -property switch). There are numerous DIPs with proposals on improving the design:

• DIP4
• DIP5
• DIP6
• DIP21
• DIP23
• DIP24
• DIP26
• DIP28

See also:

• Property Discussion Wrap-up
• Language design discussions#Properties

Unicode and ranges

D's ranges currently treat strings in a special way: they present them as a range of code points, thus implicitly performing UTF decoding. Algorithms that do not require working with decoded code points, and which would gain a performance advantage by treating the input as a range of code units (or an array of code units), must incorporate D strings as a special case. This approach complicates the implementation by some degree, and only solves a certain subset of problems for a subset of written languages.

In response to the question "What aspect of D do you hate/want to redesign?", Walter Bright said that he "wouldn't make the auto-decoding of UTF strings the default behavior".

See also:

• Element type of string ranges
• March 2014 discussion

Signed/unsigned comparisons

(What's the status of this? Issue 259 is open and has an open pull request.)

Null References

{Please add summary}

See also:

• February 2014 discussion
• September 2012 discussion
• Issue 4595 - [tdpl] Accessing non-static member of a null reference compiles

Virtual by default

In D, methods are virtual by default. Although this approach does have benefits from the point of view of extensibility, it has been criticized that this default incurs a considerable performance impact and harms forward compatibility in user code, unless explicitly disabled everywhere as appropriate using the final keyword.

Although at one point Walter Bright intended to change the default (see Issue 11616 and DIP51), ultimately this proposal has been rejected.

Default constructors

D does not support custom default constructors for value types: attempting to declare a struct constructor without any arguments is an error. The rationale for this limitation is to allow any type to have a known constant default value (.init property). This is unlike C++, where structs and classes can have default constructors, which allow executing custom code at the point of a variable's declaration.

D's restriction prevents implementing certain C++ patterns, and requires users to rely on conventions for factory functions.

Memory management

D is often criticized for its reliance on a garbage collector, and the quality of the current GC implementation.

The current GC implementation is:

• conservative (meaning, it can't guarantee whether any object actually has live references to it)
• non-moving (the GC doesn't attempt to compact the heap to reduce fragmentation and working set size)
• stop-the-world (all threads are stopped during a GC scan)

Precise (as far as the heap is concerned) and concurrent D GC implementations have been presented:

• A Precise Garbage Collector for D (DConf 2013 talk by Rainer Schütze)
• Concurrent Garbage Collection for D (DConf 2013 talk by Leandro Lucarella)

Although the GC can be disabled, using D completely without the GC may be challenging, as some parts of D expect a GC to be available:

• Many modules in Phobos, D's standard library, expect a GC to be present to clean up temporary allocations;
• D language features such as arrays require careful use to avoid memory leaks;
• D language features such as closures and exceptions cannot be used, as they do not provide a way to manually deallocate allocated memory.

Some alternative runtimes / standard libraries which do not rely on the GC are listed here.