譯者：uframer

模板

D 模板提供了一種提供范型編程和偏特化能力的簡潔的方法。

關聯數組

關聯數組是索引可以為任意類型的數組，不像普通數組那樣必須使用整數作為索引。本質上，關聯數組就是散列表。關聯數組使構建快速、高效、無錯的符號表變得容易了。

真正的 typedef

C 和 C++ 的 typedef 實際上是類型 別名 ，因為它不會引入新的類型。D 實現了真正的 typedef ：

typedef int handle;

實實在在地創造了一個新類型 handle 。D 同樣會對 typedef 引入的類型進行類型檢查，并且 typedef 也參與函數重載的決策。

例如：

int foo(int i);

int foo(handle h);

Bit 類型

機器上最基本的數據類型是位，因此 D 直接支持 bit 數據類型。它在創建位數組時最有用：

bit[] foo;

函數

如你所愿，D 提供常規的對函數的支持，包括全局函數、重載函數、函數在線化、成員函數、虛函數、函數指針等等。另外，D 還支持：

嵌套函數
函數可以嵌套在其他函數內。這對于代碼分解、局部性以及函數閉包技術都具有很高的價值。

函數文字量
匿名函數可以直接嵌入到表達式中。

動態閉包
嵌套函數和類成員函數可以被稱為閉包（也被稱為委托），它們可使范型編程更為容易并保證類型安全。

In, Out 和 Inout 參數
這幾個修飾符不只能使函數更為易于理解，還能避免使用指針而不會影響代碼的功能，另外這也會提高編譯器幫助程序員找到編碼問題的可能性。

這些修飾符使 D 能夠直接同更多的外部 API 對接。也就無需使用“接口定義語言”（IDL）之類的東西了。

數組

C 數組有幾個可以被糾正的缺點：

* 數組本身并不帶有數組結構的信息，它們必須另外存儲和傳遞。一個經典的例子就是傳遞給 main(int argc, char *argv[]) 函數的 argc 和 argv 參數。（在 D 中，main 被聲明為 main(char[][] args) 。）
* 數組不是一等公民。當一個數組被傳遞給函數時，他被轉換為指針，盡管那個原型令人迷惑地聲稱它是一個數組。當發生類型轉換時，所有的數組類型信息也就丟失了。
* C 數組的大小不可改變。這意味著即使最簡單的聚集如堆棧都必須用一個復雜的類構造。
* C 數組沒有邊界檢查，因為它們根本不知道數組邊界是多少。
* 數組聲明中的 [] 位于標志符之后。這使得聲明如一個指向數組的指針這樣的東西都需要復雜難懂語法：

int (*array)[3];

在 D 中，數組的 [] 位于左側：

int[3] *array; // 聲明了一個指向含有 3 個 int 的數組的指針

long[] func(int x); // 聲明了一個返回含有 long 數據的數組

顯然這更易于理解。

D 數組有四種變體：指針、靜態數組、動態數組和關聯數組。

字符串

在 C 和 C++ 中，對字符串的操作是如此的頻繁，而又如此的笨拙，以至于最好還是由語言本身來支持它比較好。現代語言都處理字符串連接、復制等等操作，D 語言也提供了這些支持。字符串是直接由經過改進的數組來處理的。

資源管理

垃圾收集

D 的內存分配完全采用垃圾收集。經驗告訴我們，C++ 中的很多復雜特征都是用于處理內存釋放的。有了垃圾收集，語言就變得簡單多了。

有一種看法認為垃圾收集是給那些懶惰、初級的程序員準備的。我還記得那些對 C++ 的評論，畢竟，沒有什么 C++ 能做而 C 不能做的，或者這對匯編來說也一樣。

采用垃圾收集可以避免 C 和 C++ 中必需的乏味的、易于出錯的內存分配和追蹤代碼。這不只意味著更少的開發時間和更低的維護費用，還意味著程序運行得更快！

當然，可以在 C++ 中使用垃圾收集程序，我已經在我自己的項目中使用它了。C++ 對垃圾收集程序并不友好，這也造成了 C++ 中垃圾收集的低效。很多運行時庫的代碼都不能同來垃圾收集程序一同工作。

顯式內存分配

盡管 D 是一種采用垃圾收集的語言，還是可以重寫某個類的 new 和 delete 操作以采用一個定制的分配器。

RAII
RAII 是一種管理資源分配和釋放的現代軟件開發技術。D 以一種可控的、可預測的方式支持 RAII ，它是獨立于垃圾收集程序的回收周期的。

性能

輕量級聚集

D 支持簡單的 C 風格的結構，既保證了對 C 數據結構的兼容性，也是因為有時采用類有殺雞用牛刀之嫌。

內聯匯編

設備驅動程序、高性能系統程序、嵌入式系統和某些特殊的代碼需要使用匯編語言完成任務。盡管 D 的實現不一定要實現內聯匯編，它也仍被定義為語言的一部分。他可以滿足絕大多數使用匯編語言的需要，這樣就不需要單獨的匯編程序或者使用 DLL 了。

許多的 D 實現同時也實現那些類似于 C 的支持 I/O 端口操作、直接訪問浮點硬件等內部功能的內函數。

可靠性

現代的語言應該竭盡所能地幫助程序員避免出錯。語言提供的幫助有多種形式：從易于使用更為健壯的技術，到有編譯器指出明顯出錯的代碼，到運行時檢查。

契約

契約式編程（由 B. Meyer 發明）是一種用于保證程序正確性的革命性的技術。D 版本的 DBC 包括函數先驗條件、函數后驗條件、雷不變量和斷言契約。

單元測試

可以給一個類加入單元測試，這樣測試程序就能在程序啟動時自動運行。這樣就能夠在每次構建時都驗證類是否實現了他所應完成的功能。單元測試構成了源代碼的一部分。創建單元測試成為了類開發過程中的自然的一部分，而不是將完成的代碼直接拋給測試小組。

單元測試可以使用其它語言完成，但是其結果看起來有一種七拼八湊的感覺，而且你采用的那種語言很可能并不兼容這個概念。單元測試是 D 的一個主要特征。對于庫函數來說，單元測試已經被證明是十分有效的。它既可以保證函數工作正常，也可以演示如何使用這些函數。

考慮大量的可以從網上下載的 C++ 庫和應用程序代碼。其中有“幾個”是帶有驗證測試的？更不要奢望單元測試了？少于 1% ？通常的做法是，如果它們能通過編譯，我們就假定它是正確的。而且我們不知道變異過程中給出的警告到底是真正的錯誤還是瞎嘮叨。

契約式編程和單元測試使 D 為編寫可信賴、健壯的系統程序的最好的語言。單元測試還是我們能夠粗略但快速地估計你從未經手的 D 代碼片斷的質量——如果沒有單元測試和契約式編程，每人會干這種事。

調試特征和語句

現在調試成為了語言語法的一部分了。可以在編譯時決定是否使用這些代碼，再也不用使用宏或者預處理命令了。調試語法提供了一種持續的、可移植的、易于理解的識別調試代碼的方法，使程序員既能夠生成帶有調試代碼的二進制版本，也能夠生成沒有調試代碼的二進制版本。

異常處理

D 采用了更為高級的 try-catch-finally 模型而不是原來的 try-catch 模型。沒有必要只是為了利用析構函數實現 finally 語義而構造一個傀儡對象。

同步

因為多線程編程已經越來越成為主流，所以 D 提供了構建多線程程序的原語。同步既可以作用在方法上，也可以作用在對象上。

synchronized int func() { . }

同步方法一次只允許一個線程執行。

同步語句將在語句塊周圍插入一個互斥體，控制對象或全局的訪問。

對健壯性技術的支持

* 使用動態數組而不是指針
* 使用對變量的引用而不是指針
* 使用對對象的引用而不是指針
* 使用垃圾收集而不是顯式內存分配
* 內建線程同步原語
* 不再有宏給你的代碼來那么一下子
* 使用內聯函數而不是宏
* 在很大程度上減少了使用指針的需要
* 整型的大小是明確的
* 不用再擔心 char 類型是否有符號了
* 不必再分別在源文件和頭文件中重復地寫聲明了
* 為調試代碼提供了顯式的解析支持

編譯時檢查

* 更強的類型檢查
* 需要進行顯式初始化
* 不允許出現未使用的局部變量
* 不允許出現空的（只由‘;’的）循環體
* 賦值語句不會返回布爾類型的結果
* 廢棄過時的 API

運行時檢查

* assert() 表達式
* 數組邊界檢查
* switch 語句中的未定義 case 語句異常
* 內存耗盡異常
* in、out 和類不變量提供了對契約式編程的支持

兼容性

運算符優先級和求值規則
D 保留了 C 的運算符和它們的優先級、求值的規則和類型提升規則。這就避免了由于同 C 的語義不同而造成的微妙的難以發現的 bug 的出現。

直接訪問 C API
D 不支擁有同 C 類型對應的類型，它還提供了直接訪問 C 函數的能力。完全沒有必要編寫封裝函數和參數變換器，也沒有必要逐一地復制聚集類型的成員。

支持所有的 C 數據類型
使對 C API 或者現有的 C 庫代碼的接口成為可能。D 支持結構、聯合、枚舉、指針和所有的 C99 類型。D 還擁有設置結構成員對齊方式的能力，這樣就可以保證同外部導入的數據格式的兼容。

操作系統異常處理
D 的異常處理機制將在應用程序中利用底層操作系統提供的異常處理方式。

使用現成的工具
D 生成標準的目標文件格式，這樣就能夠使用標準的匯編程序、鏈接器、調試器、性能分析工具、可執行程序壓縮程序和其他的分析程序，還能夠同其他語言編寫的代碼相鏈接。

項目管理

版本控制
D 對從同一份源碼生成多個版本的程序提供了內建的支持。它替代了 C 預處理程序的 #if/#endif 技術。

廢棄
隨著代碼不停的演進，一些舊的庫代碼會被更新、更好的版本代替。同時舊的版本必須可用以支持舊的客戶代碼，舊的版本可以被標記為 廢棄的 。可以通過編譯器的一個選項來判斷使用廢棄版本代碼的版本是否是合法的，這樣一來負責維護的程序員就可以更為輕松的判斷哪里是依賴于已經被廢棄的特征的。

沒有警告
D 編譯器不會為可疑的代碼生成警告。代碼要么可以被編譯器接受，要么不能被編譯器接受。這樣就不會引起有關哪些警告確實是錯誤而那些不是的爭論，也就沒有如何處理它們的爭論了。對編譯器警告的需求本身就是不好的語言設計的表現。

示例程序 (sieve.d)