Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using a local clone.

Documentation Generator

The D programming language enables embedding both contracts and test code along side the actual code, which helps to keep them all consistent with each other. One thing lacking is the documentation, as ordinary comments are usually unsuitable for automated extraction and formatting into manual pages. Embedding the user documentation into the source code has important advantages, such as not having to write the documentation twice, and the likelihood of the documentation staying consistent with the code.

Some existing approaches to this are:

D's goals for embedded documentation are:

  1. It looks good as embedded documentation, not just after it is extracted and processed.
  2. It's easy and natural to write, i.e. minimal reliance on <tags> and other clumsy forms one would never see in a finished document.
  3. It does not repeat information that the compiler already knows from parsing the code.
  4. It doesn't rely on embedded HTML, as such will impede extraction and formatting for other purposes.
  5. It's based on existing D comment forms, so it is completely independent of parsers only interested in D code.
  6. It should look and feel different from code, so it won't be visually confused with code.
  7. It should be possible for the user to use Doxygen or other documentation extractor if desired.


The specification for the form of embedded documentation comments only specifies how information is to be presented to the compiler. It is implementation-defined how that information is used and the form of the final presentation. Whether the final presentation form is an HTML web page, a man page, a PDF file, etc. is not specified as part of the D Programming Language.

Phases of Processing

Embedded documentation comments are processed in a series of phases:

  1. Lexical - documentation comments are identified and attached to tokens.
  2. Parsing - documentation comments are associated with specific declarations and combined.
  3. Sections - each documentation comment is divided up into a sequence of sections.
  4. Special sections are processed.
  5. Highlighting of non-special sections is done.
  6. All sections for the module are combined.
  7. Macro and Escape text substitution is performed to produce the final result.


Embedded documentation comments are one of the following forms:

  1. /** ... */ The two *'s after the opening /
  2. /++ ... +/ The two +'s after the opening /
  3. /// The three slashes

The following are all embedded documentation comments:

/// This is a one line documentation comment.

/** So is this. */

/++ And this. +/

   This is a brief documentation comment.

 * The leading * on this line is not part of the documentation comment.

   The extra *'s immediately following the /** are not
   part of the documentation comment.

   This is a brief documentation comment.

 + The leading + on this line is not part of the documentation comment.

   The extra +'s immediately following the / ++ are not
   part of the documentation comment.

/**************** Closing *'s are not part *****************/

The extra *'s and +'s on the comment opening, closing and left margin are ignored and are not part of the embedded documentation. Comments not following one of those forms are not documentation comments.


Each documentation comment is associated with a declaration. If the documentation comment is on a line by itself or with only whitespace to the left, it refers to the next declaration. Multiple documentation comments applying to the same declaration are concatenated. Documentation comments not associated with a declaration are ignored. Documentation comments preceding the ModuleDeclaration apply to the entire module. If the documentation comment appears on the same line to the right of a declaration, it applies to that.

If a documentation comment for a declaration consists only of the identifier ditto then the documentation comment for the previous declaration at the same declaration scope is applied to this declaration as well.

If there is no documentation comment for a declaration, that declaration may not appear in the output. To ensure it does appear in the output, put an empty declaration comment for it.

int a;  /// documentation for a; b has no documentation
int b;

/** documentation for c and d */
/** more documentation for c and d */
int c;
/** ditto */
int d;

/** documentation for e and f */ int e;
int f;  /// ditto

/** documentation for g */
int g; /// more documentation for g

/// documentation for C and D
class C
    int x; /// documentation for C.x

    /** documentation for C.y and C.z */
    int y;
    int z; /// ditto

/// ditto
class D { }


The document comment is a series of Sections. A Section is a name that is the first non-blank character on a line immediately followed by a ':'. This name forms the section name. The section name is not case sensitive.

Section names starting with 'http://' or 'https://' are not recognized as section names.


The first section is the Summary, and does not have a section name. It is first paragraph, up to a blank line or a section name. While the summary can be any length, try to keep it to one line. The Summary section is optional.


The next unnamed section is the Description. It consists of all the paragraphs following the Summary until a section name is encountered or the end of the comment.

While the Description section is optional, there cannot be a Description without a Summary section.

 * Brief summary of what
 * myfunc does, forming the summary section.
 * First paragraph of synopsis description.
 * Second paragraph of
 * synopsis description.

void myfunc() { }

Named sections follow the Summary and Description unnamed sections.

Standard Sections

For consistency and predictability, there are several standard sections. None of these are required to be present.

Lists the author(s) of the declaration.
 * Authors: Melvin D. Nerd, [email protected]
Lists any known bugs.
 * Bugs: Doesn't work for negative values.
Specifies the date of the current revision. The date should be in a form parseable by
 * Date: March 14, 2003
Provides an explanation for and corrective action to take if the associated declaration is marked as deprecated.
 * Deprecated: superseded by function bar().

deprecated void foo() { ... }
Any usage examples
 * Examples:
 * --------------------
 * writeln("3"); // writes '3' to stdout
 * --------------------
Revision history.
 * History:
 *      V1 is initial version
 *      V2 added feature X
Any license information for copyrighted code.
 * License: use freely for any purpose

void bar() { ... }
Explains the return value of the function. If the function returns void, don't redundantly document it.
 * Read the file.
 * Returns: The contents of the file.

void[] readFile(const(char)[] filename) { ... }
List of other symbols and URLs to related items.
 * See_Also:
 *    foo, bar,
If this declaration is compliant with any particular standard, the description of it goes here.
 * Standards: Conforms to DSPEC-1234
Lists exceptions thrown and under what circumstances they are thrown.
 * Write the file.
 * Throws: WriteException on failure.

void writeFile(string filename) { ... }
Specifies the current version of the declaration.
 * Version: 1.6a

Special Sections

Some sections have specialized meanings and syntax.

This contains the copyright notice. The macro COPYRIGHT is set to the contents of the section when it documents the module declaration. The copyright section only gets this special treatment when it is for the module declaration.
/** Copyright: Public Domain */

module foo;
Function parameters can be documented by listing them in a params section. Each line that starts with an identifier followed by an '=' starts a new parameter description. A description can span multiple lines.
 * foo does this.
 * Params:
 *      x =     is for this
 *              and not for that
 *      y =     is for that

void foo(int x, int y)
The macros section follows the same syntax as the Params: section. It's a series of NAME=value pairs. The NAME is the macro name, and value is the replacement text.
 * Macros:
 *      FOO =   now is the time for
 *              all good men
 *      BAR =   bar
 *      MAGENTA =   <font color="magenta">$0</font>
The escapes section is a series of substitutions which replace special characters with a string. It's useful when the output format requires escaping of certain characters, for example in HTML & should be escaped with &amp;.
The syntax is /c/string/, where c is either a single character, or multiple characters separated by whitespace or commas, and string is the replacement text.
 * ESCAPES = /&/AddressOf!/
 *           /!/Exclamation/
 *           /?/QuestionMark/
 *           /,/Comma/
 *           /{ }/Parens/
 *           /<,>/Arrows/


Embedded Comments

The documentation comments can themselves be commented using the $(DDOC_COMMENT comment text) syntax. These comments do not nest.

Embedded Code

D code can be embedded using lines beginning with at least three hyphens -, backticks ` or tildes ~ (ignoring whitespace) to delineate the code section:

 + Our function.
 + Example:
 + ---
 + import std.stdio;
 + void foo()
 + {
 +     writeln("foo!");  /* print the string */
 + }
 + ---

Note that in the above example the documentation comment uses the /++ ... +/ form so that /* ... */ can be used inside the code section.

D code gets automatic syntax highlighting. To include code in another language without syntax highlighting, add a language string at the end of the top delimiter line:

 + Some C++
 + ``` cpp
 + #include <iostream>
 + void foo()
 + {
 +     std::cout << "foo!";
 + }
 + ```

Enable support for backticks, tildes and other code languages with the -preview=markdown compiler flag.

Inline Code

Inline code can be written between backtick characters (`), similarly to the syntax used on GitHub, Reddit, Stack Overflow, and other websites. Both the opening and closing ` character must appear on the same line to trigger this behavior.

Text inside these sections will be escaped according to the rules described above, then wrapped in a $(DDOC_BACKQUOTED) macro. By default, this macro expands to be displayed as an inline text span, formatted as code.

A literal backtick character can be output either as a non-paired ` on a single line or by using the $(BACKTICK) macro.

 /// Returns `true` if `a == b`.
 void foo() {}

 /// Backquoted `<html>` will be displayed to the user instead
 /// of passed through as embedded HTML (see below).
 void bar() {}

Embedded HTML

HTML can be embedded into the documentation comments, and it will be passed through to the HTML output unchanged. However, since it is not necessarily true that HTML will be the desired output format of the embedded documentation comment extractor, it is best to avoid using it where practical.

 * Example of embedded HTML:
 * <ol>
 *   <li><a href="">Digital Mars</a></li>
 *   <li><a href="">Empire</a></li>
 * </ol>


Enable this feature with the -preview=markdown compiler flag.

A long documentation section can be subdivided by adding headings. A heading is a line of text that starts with one to six # characters followed by whitespace and then the heading text. The number of # characters determines the heading level. Headings may optionally end with any number of trailing # characters.

 * # H1
 * ## H2
 * ### H3
 * #### H4 ###
 * ##### H5 ##
 * ###### H6 #


Enable this feature with the -preview=markdown compiler flag.

Documentation may link to other documentation or to a URL. There are four styles of links:

 * Some links:
 * 1. A [reference link][ref] and bare reference links: [ref] or [Object]
 * 2. An [inline link](
 * 3. A bare URL:
 * 4. An ![image](
 * [ref]: "The D Language Website"

Reference Links

Reference-style links enclose a reference label in square brackets. They may optionally be preceeded by some link text, also enclosed in square brackets.

The reference label must match a reference defined elsewhere. This may be a D symbol in scope of the source code being documented, like [Object] in the example above, or it may be an explicit reference that is defined in the same documentation comment, like [ref] in the example above. In the example both instances of [ref] in item 1. will be replaced with the URL and title text from the matching definition at the bottom of the example. The first link will read reference link and the second will read ref.

Reference definitions start with a label in square brackets, followed by a colon, a URL and an optional title wrapped in single or double quotes, or in parentheses. If a reference label would match both a D symbol and a reference definition then the reference definition is used.

The generated links to D symbols are relative if they have the same root package as the module being documented. If not, their URLs are preceeded by a $(DDOC_ROOT_pkg) macro, where pkg is the root package of the symbol being linked to. Links to D symbols are generated with a $(DOC_EXTENSION) macro after the module name. So the generated URL for [Object] in the above example is as if you had written:


You may define your own DOC_ROOT_ macros for any external packages you wish to link to using a Macros section.

Inline Links

Inline-style links enclose link text in square brackets and the link URL in parentheses. Like reference links, the URL may optionally be followed by title text wrapped in single or double quotes, or in parentheses:

/// [a link with title text]( 'Some title text')

Bare URLs

Bare URLs are sequences of characters that start with http:// or https://, continue with one or more characters from the set of letters, digits and -_?=%&/+#~., and contain at least one period. URL recognition happens before all macro text substitution. The URL is wrapped in a $(DDOC_LINK_AUTODETECT) macro and is otherwise left untouched.


Images have the same form as reference or inline links, but add an exclamation point ! before the initial square bracket. What would be the link text in a normal link is used as the image's alt text.


Enable this feature with the -preview=markdown compiler flag.

Documentation may contain lists. Start an ordered list with a number followed by a period:

 * 1. First this
 * 2. Then this
 *    1. A sub-item

Start an unordered list with a hypen (-), an asterisk (*) or a plus (+). Subsequent items in the same list must also start with the same symbol:

 * - A list
 * - With a second item
 * + A different list
 *   - With a sub-item
 * * A third list (note the double asterisks)

Note the double asterisks in the example above. This is because the list is inside a documentation comment that is delimited with asterisks, so the initial asterisk is considered part of the documentation comment, not a list item. This is even true when other lines don't start with an asterisk:

 - A list
 * Not a list because the asterisk is part of the documentation comment

 + + The caveat also applies to plus-delimited documentation comments

List items can include content like new paragraphs, headings, embedded code, or child list items. Simply indent the content to match the indent of the text after the list symbol:

 * - A parent list item
 *   With a second paragraph
 *   - A sub-item
 *     ---
 *     // A code example inside the sub-item
 *     ---


Enable this feature with the -preview=markdown compiler flag.

Data may be placed into a table. Tables consist of a single header row, a delimiter row, and zero or more data rows. Cells in each row are separated by pipe (|) characters. Initial and trailing |'s are optional. The number of cells in the delimiter row must match the number of cells in the header row:

 *  | Item | Price |
 *  | ---- | ----: |
 *  | Wigs | $10 |
 *    Wheels | $13
 *  | Widgets | $200 |

Cells in the delimiter row contain hyphens (-) and optional colons (:). A : to the left of the hyphens creates a left-aligned column, a : to the right of the hyphens creates a right-aligned column (like the example above), and :'s on both sides of the hyphens create a center-aligned column.


Enable this feature with the -preview=markdown compiler flag.

Documentation may include a section of quoted material by prefixing each line of the section with a >. Quotes may include headings, lists, embedded code, etc.

 * > To D, or not to D. -- Willeam NerdSpeare

Lines of text that directly follow a quoted line are considered part of the quote:

 * > This line
 * and this line are both part of the quote
 * This line is not part of the quote.

Horizontal Rules

Enable this feature with the -preview=markdown compiler flag.

Create a horizontal rule by adding a line containing three or more asterisks, underscores or hyphens:

 * ***
 * ___

As with lists, note that the initial * in the example above will be stripped because it is part of a documentation comment that is delimited with asterisks, so you need at least three subsequent asterisks.

To create a horizontal rule with hyphens, add spaces between the hyphens. Without the spaces they would be treated as the start or end of an embedded code block. Note that any horizontal rule may contain spaces:

 * - - -
 * _ _ _
 * * * *

Text Emphasis

Enable this feature with the -preview=markdown compiler flag.

A span of text wrapped in asterisks (*) is emphasized, and text wrapped in two asterisks (**) is strongly emphasized:

*single asterisks* is rendered as single asterisks.

**double asterisks** is rendered as double asterisks.

You can insert a literal asterisk by backslash-escaping it: \* is rendered as *.

Unlike Markdown, underscores (_) are not supported for emphasizing text because it would break snake_case names and underscore prefix processing in identifier emphasis.

Identifier Emphasis

Identifiers in documentation comments that are function parameters or are names that are in scope at the associated declaration are emphasized in the output. This emphasis can take the form of italics, boldface, a hyperlink, etc. How it is emphasized depends on what it is  —  a function parameter, type, D keyword, etc. To prevent unintended emphasis of an identifier, it can be preceded by an underscore (_). The underscore will be stripped from the output.

Character Entities

Some characters have special meaning to the documentation processor, to avoid confusion it can be best to replace them with their corresponding character entities:

Characters and Entities

It is not necessary to do this inside a code section, or if the special character is not immediately followed by a # or a letter.

Punctuation Escapes

Enable this feature with the -preview=markdown compiler flag.

You can escape any ASCII punctuation symbol with a backslash \. Doing so outputs the original character without the backslash, except for the following characters which output predefined macros instead:

Characters and Escape Macros

To output a backslash, simply use two backslashes in a row: \\. Note that backslashes inside embedded or inline code do not escape punctuation and are included in the output as-is. Backslashes before non-punctation are also included in the output as-is. For example, C:\dmd2\bin\dmd.exe does not require escaping its embedded backslashes.

No Documentation

No documentation is generated for the following constructs, even if they have a documentation comment:


The documentation comment processor includes a simple macro text preprocessor. When a $(NAME) appears in section text it is replaced with NAMEs corresponding replacement text.

For example:
 PARAM = <u>$1</u>
 MATH_DOCS = <a href="">Math Docs</a>
module math;

 * This function returns the sum of $(PARAM a) and $(PARAM b).
 * See also the $(MATH_DOCS).
int sum(int a, int b) { return a + b; }

The above would generate the following output:

<dl><dt><big><a name="sum"></a>int <u>sum</u>(int <i>a</i>, int <i>b</i>);
<dd>This function returns the <u>sum</u> of <u><i>a</i></u> and <u><i>b</i></u>.
 See also the <a href="">Math Docs</a>.

The replacement text is recursively scanned for more macros. If a macro is recursively encountered, with no argument or with the same argument text as the enclosing macro, it is replaced with no text. Macro invocations that cut across replacement text boundaries are not expanded. If the macro name is undefined, the replacement text has no characters in it. If a $(NAME) is desired to exist in the output without being macro expanded, the $ should be backslash-escaped: \$.

Macros can have arguments. Any text from the end of the identifier to the closing ‘)’ is the $0 argument. A $0 in the replacement text is replaced with the argument text. If there are commas in the argument text, $1 will represent the argument text up to the first comma, $2 from the first comma to the second comma, etc., up to $9. $+ represents the text from the first comma to the closing ‘)’. The argument text can contain nested parentheses, "" or '' strings, <!-- ... --> comments, or tags. If stray, unnested parentheses are used, they can be backslash-escaped: \( or \).

Macro definitions come from the following sources, in the specified order:

  1. Predefined macros.
  2. Definitions from file specified by sc.ini's or dmd.conf DDOCFILE setting.
  3. Definitions from *.ddoc files specified on the command line.
  4. Runtime definitions generated by Ddoc.
  5. Definitions from any Macros: sections.

Macro redefinitions replace previous definitions of the same name. This means that the sequence of macro definitions from the various sources forms a hierarchy.

Macro names beginning with "D_" and "DDOC_" are reserved.

Predefined Macros

A number of macros are predefined Ddoc, and represent the minimal definitions needed by Ddoc to format and highlight the presentation. The definitions are for simple HTML.

The implementations of all predefined macros are implementation-defined. The reference implementation's macro definitions can be found here.

Ddoc does not generate HTML code. It formats into the basic formatting macros, which (in their predefined form) are then expanded into HTML. If output other than HTML is desired, then these macros need to be redefined.

Predefined Formatting Macros
Bboldface the argument
Iitalicize the argument
Uunderline the argument
Pargument is a paragraph
DLargument is a definition list
DTargument is a definition in a definition list
DDargument is a description of a definition
TABLEargument is a table
TRargument is a row in a table
THargument is a header entry in a row
TDargument is a data entry in a row
OLargument is an ordered list
ULargument is an unordered list
LIargument is an item in a list
BIGargument is one font size bigger
SMALLargument is one font size smaller
BRstart new line
LINKgenerate clickable link on argument
LINK2generate clickable link, first arg is address
REDargument is set to be red
BLUEargument is set to be blue
GREENargument is set to be green
YELLOWargument is set to be yellow
BLACKargument is set to be black
WHITEargument is set to be white
D_CODEargument is D code
D_INLINECODEargument is inline D code
LFInsert a line feed (newline)
LPARENInsert a left parenthesis
RPARENInsert a right parenthesis
BACKTICKInsert a backtick
DOLLARInsert a dollar sign
DDOCoverall template for output

DDOC is special in that it specifies the boilerplate into which the entire generated text is inserted (represented by the Ddoc generated macro BODY). For example, in order to use a style sheet, DDOC would be redefined as:

    <META http-equiv="content-type" content="text/html; charset=utf-8">
    <link rel="stylesheet" type="text/css" href="style.css">

Highlighting of D code is performed by the following macros:

D Code Formatting Macros
D_COMMENTHighlighting of comments
D_STRINGHighlighting of string literals
D_KEYWORDHighlighting of D keywords
D_PSYMBOLHighlighting of current declaration name
D_PARAMHighlighting of current function declaration parameters

The highlighting macros start with DDOC_. They control the formatting of individual parts of the presentation.

Ddoc Section Formatting Macros
DDOC_CONSTRAINTHighlighting of a template constraint.
DDOC_COMMENTInserts a comment in the output.
DDOC_DECLHighlighting of the declaration.
DDOC_DECL_DDHighlighting of the description of a declaration.
DDOC_DITTOHighlighting of ditto declarations.
DDOC_SECTIONSHighlighting of all the sections.
DDOC_SUMMARYHighlighting of the summary section.
DDOC_DESCRIPTIONHighlighting of the description section.
DDOC_AUTHORSHighlighting of the authors section.
DDOC_BUGSHighlighting of the bugs section.
DDOC_COPYRIGHTHighlighting of the copyright section.
DDOC_DATEHighlighting of the date section.
DDOC_DEPRECATEDHighlighting of the deprecated section.
DEPRECATEDWrapper for deprecated declarations.
DDOC_EXAMPLESHighlighting of the examples section.
DDOC_HISTORYHighlighting of the history section.
DDOC_LICENSEHighlighting of the license section.
DDOC_OVERLOAD_SEPARATORInserts a separator between overloads of a given name.
DDOC_RETURNSHighlighting of the returns section.
DDOC_SEE_ALSOHighlighting of the see-also section.
DDOC_STANDARDSHighlighting of the standards section.
DDOC_THROWSHighlighting of the throws section.
DDOC_VERSIONHighlighting of the version section.
DDOC_SECTION_HHighlighting of the section name of a non-standard section.
DDOC_SECTIONHighlighting of the contents of a non-standard section.
DDOC_MEMBERSDefault highlighting of all the members of a class, struct, etc.
DDOC_MODULE_MEMBERSHighlighting of all the members of a module.
DDOC_CLASS_MEMBERSHighlighting of all the members of a class.
DDOC_STRUCT_MEMBERSHighlighting of all the members of a struct.
DDOC_ENUM_MEMBERSHighlighting of all the members of an enum.
DDOC_TEMPLATE_PARAMHighlighting of a template's individual parameters.
DDOC_TEMPLATE_PARAM_LISTHighlighting of a template's parameter list.
DDOC_TEMPLATE_MEMBERSHighlighting of all the members of a template.
DDOC_ENUM_BASETYPEHighlighting of the type an enum is based upon
DDOC_PARAMSHighlighting of a function parameter section.
DDOC_PARAM_ROWHighlighting of a name=value function parameter.
DDOC_PARAM_IDHighlighting of the parameter name.
DDOC_PARAM_DESCHighlighting of the parameter value.
DDOC_BLANKLINEInserts a blank line.
DDOC_ANCHORExpands to a named anchor used for hyperlinking to a particular declaration section. Argument $1 expands to the qualified declaration name.
DDOC_PSYMBOLHighlighting of declaration name to which a particular section is referring.
DDOC_PSUPER_SYMBOLHighlighting of the base type of a class.
DDOC_KEYWORDHighlighting of D keywords.
DDOC_PARAMHighlighting of function parameters.
DDOC_BACKQUOTEDInserts inline code.
DDOC_AUTO_PSYMBOL_SUPPRESSHighlighting of auto-detected symbol that starts with underscore
DDOC_AUTO_PSYMBOLHighlighting of auto-detected symbol
DDOC_AUTO_KEYWORDHighlighting of auto-detected keywords
DDOC_AUTO_PARAMHighlighting of auto-detected parameters

For example, one could redefine DDOC_SUMMARY:


And all the summary sections will now be green.

Macro Definitions from sc.ini's DDOCFILE

A text file of macro definitions can be created, and specified in sc.ini:


Macro Definitions from .ddoc Files on the Command Line

File names on the DMD command line with the extension .ddoc are text files that are read and processed in order.

Macro Definitions Generated by Ddoc

Generated Macro Definitions
Macro NameContent
BODY Set to the generated document text.
TITLE Set to the module name.
DATETIME Set to the current date and time.
YEAR Set to the current year.
COPYRIGHT Set to the contents of any Copyright: section that is part of the module comment.
DOCFILENAME Set to the name of the generated output file.
SRCFILENAME Set to the name of the source file the documentation is being generated from.

Using Ddoc to generate examples from unit tests

Ddoc can automatically generate usage examples for declarations using unit tests. If a declaration is followed by a documented unit test, the code from the test will be inserted into the example section of the declaration. This avoids the frequent problem of having outdated documentation for pieces of code.

To create a documented unit test just add three forward slashes before the unittest block, like this:


For more information please see the full section on documented unit tests.

Using Ddoc for other Documentation

Ddoc is primarily designed for use in producing documentation from embedded comments. It can also, however, be used for processing other general documentation. The reason for doing this would be to take advantage of the macro capability of Ddoc and the D code syntax highlighting capability.

If the .d source file starts with the string "Ddoc" then it is treated as general purpose documentation, not as a D code source file. From immediately after the "Ddoc" string to the end of the file or any "Macros:" section forms the document. No automatic highlighting is done to that text, other than highlighting of D code embedded between lines delineated with --- lines. Only macro processing is done.

Much of the D documentation itself is generated this way, including this page. Such documentation is marked at the bottom as being generated by Ddoc.

Security considerations

Note that DDoc comments may embed raw HTML, including <script> tags. Be careful when publishing or distributing rendered DDoc HTML generated from untrusted sources, as this may allow cross-site scripting.

Links to D documentation generators

A list of current D documentation generators which use Ddoc can be found on our wiki page.

D x86 Inline Assembler
Interfacing to C