Phobos: the standard library that ships with the D compiler

What actually ships in the box

Phobos is the standard library that comes with the D compiler, and the difference in phrasing from most language ecosystems is the whole story. There is no separate package to install, no version to resolve, and no dependency to conflict with, because the library is packaged together with the compiler you downloaded. The scope of what is included follows from the topic list of the repository, and it is broad. There are the container and range types, the algorithms, the regular expression engine, the numeric and mathematical modules, the standard input and output layer, the character and Unicode handling, the type traits and the conversion machinery, the functional programming pieces, the memory allocator, the meta programming facilities, and the concurrency and parallelism modules. For a language whose selling point was systems programming with high level conveniences, that is the set of features the language exists to provide, and the quality of this library is a large part of that proposition.

Getting it: the package or the source

The README is direct about this. Phobos is packaged together with the compiler, and the recommendation is to download the whole precompiled package rather than to try to assemble a toolchain from parts. For a developer who wants to build everything themselves, the wiki carries a description of building the compiler, and the repository here is the library half of that. The distinction matters for a few audiences. A contributor needs the source and the build, and so does a distribution packager. A team that wants to audit the library it ships can read the source in this repository without any tooling. Everybody else should take the precompiled package, because the library and the compiler are released together and a mismatched pair is the one thing the packaging arrangement is designed to prevent.

The makefile is the build system

The build is a GNU make makefile, and the header comment is a manual in itself. On Windows you need a prebuilt GNU make executable and a Git for Windows installation, since the build relies on bash and on the usual file utilities. On FreeBSD the default make is not GNU make, so you install gmake and invoke it under that name. The comment also explains that the operating system is detected with uname, and the makefile pulls in the compiler's own osmodel makefile from a sibling directory, which tells you the library build expects the compiler source to sit next to it. The targets are numerous and each one has a stated purpose: the default target makes a release build, clean removes what was built, zip packages the sources, a build variable switches to a debug build, and install copies the library into the system library directory. There is a target that builds the HTML documentation, and another that builds a module and runs it in a debugger.

The unit tests are part of the build

The test story is the most instructive part of the makefile, because it is expressed as build targets rather than as a separate harness. The unittest target builds all the unit tests, for the debug configuration and the release configuration, and runs them. A target named after a module builds and unit tests that single module, and a package level target does the same for every module in a package, and a further target runs one module's unit test. That is an unusual amount of granularity for a standard library, and it is the kind of arrangement that lets a contributor check a change in one module in seconds rather than running the entire suite. The results feed the coverage service, and the continuous integration is split between CircleCI, which has a configuration directory in the tree, and Buildkite, which appears in the badges.

What the tree tells you about the project

The top level is a working library rather than a polished package. The std/ directory holds the modules themselves, and next to it sits a phobos/ directory, and the README does not explain how the two relate, which is itself worth knowing before you read the code. There is a test/ directory, an etc/ directory for supporting files, a changelog/ directory where the release history lives, and a tools/ directory for the build helpers. The documentation is generated from a project file, so the API reference and the source stay in step, and there is a separate build file for the version three of the compiler alongside the older posix makefile. Two files stand out for what they imply. The dscanner configuration is for the D linter, which is how the library enforces its own style rules, and the CODEOWNERS file is how a project of this size decides who reviews which part of it.

Where the one-library approach strains

The single biggest consequence of shipping the standard library inside the compiler is the release cadence. A library versioned with its compiler moves at the speed of the compiler, so a new container, a new regular expression engine or a new range adaptor waits for a compiler release rather than arriving as an independent package. That is a good trade for stability and a poor one for a team that wants a feature next week. The alternative approach, which most ecosystems have settled on, is a small standard library plus a set of separately published packages with their own versions, and the price paid there is dependency resolution, duplicated utilities and the possibility of two incompatible implementations of the same idea. The D ecosystem has leaned both ways over the years, and the presence of a legacy phobos/ directory next to the current std/ layout in this repository is a visible reminder of that. For a reviewer choosing, the question is not which approach is better in the abstract, it is how quickly you need new standard library features and how much you mind the coupling.

Licence, versioning and where the project stands

Phobos is distributed under the Boost Software License, and the text sits in a file named for it in the repository root, which is the arrangement most D projects use because it is permissive and short. The repository publishes no GitHub releases of its own, which is consistent with the versioning story: the library is released as part of the compiler, and the changelog directory in the tree is where the library's own history is recorded rather than a release page. The last push was on 2026-10-19, so the work is current. Support and discussion run through the D bug tracker for defects, the D forum for questions and the wiki for documentation, and the repository adds a contributing guide and a code of conduct for people working on the code itself. For an engineer, the practical point is that Phobos is not a dependency you add to a project file, it is the library that comes with the toolchain, so the version you have is the version you get.

Editorial conclusion

Phobos fits a D developer who wants a batteries-included standard library that is versioned together with the compiler, and a team that prefers a single coherent library over an ecosystem of separately published packages. It does not fit a team that wants to pull in only the pieces it needs, or one that expects the standard library to move quickly, because a library that ships inside the compiler moves at the speed of the compiler. Before depending on it, check the version of the compiler you have against the release notes in the changelog directory, and read the build instructions in the wiki if you intend to build it yourself, because the make targets assume GNU make and a specific source layout.

Frequently asked questions

Official sources

1. dlang/phobos on GitHub
2. Issues
3. License: BSL-1.0
4. Project website
5. README