* [http://forum.dlang.org/post/nh2o9i$hr0$1@digitalmars.com The Case against Autodecode] - NG discussion in May 2016

== Attribute creep ==

== Attribute creep ==

Line 51:

Line 52:

* [http://dlang.org/attribute.html#disable <tt>@disable</tt>]

* [http://dlang.org/attribute.html#disable <tt>@disable</tt>]

* [http://dlang.org/attribute.html#deprecated <tt>deprecated</tt>]

* [http://dlang.org/attribute.html#deprecated <tt>deprecated</tt>]

−

* [[DIP25 | return]]

+

* [[DIP25 | <tt>return</tt>]]

Additionally, function return types can be or be annotated with the following keywords:

Additionally, function return types can be or be annotated with the following keywords:

Latest revision as of 17:35, 28 February 2017

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.

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:

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.

Walter Bright has mentioned that auto-decoding is his #1 thing he currently dislikes about D [1] [2].

Signed/unsigned comparisons

Currently, the following code fails:

uinti=1;assert(i>-2);

i > -2 evaluates to false due to C compatibility (the same expression also evaluates to false in C, and one of D's goals is that if any C code compiles in D, then it should act like in C). One proposal is to make signed/unsigned comparisons generate a warning.

Null References

Null references have often been blamed as a common class of bugs, which could be prevented statically by the compiler (e.g. as a NotNull modifier, or explicitly marking variables possibly containing null values). This can be done by statically checking if all code paths (e.g. all class constructors) initialize a reference variable to a non-null value.

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.

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.

an easy way for other constructors to not have overlooked field initializers, so they get garbage initialized like in C++

generic code can rely on the existence of trivial construction that cannot fail

dummy objects can be created, useful for "does this compile" semantics

an object can be "destroyed" by overwriting it with .init (overwriting with 0 is not the same thing)

when you see: T t; in code, you know it is trivially constructed and will succeed

objects can be created using TypeInfo

Explicit syntax and @disable this

In theory, explicit struct construction syntax S s = S(); could allow calling a zero-argument constructor (vs. just S s; which is default construction). Forgetting to use the explicit syntax can be solved by disabling the default constructor (@disable this;).