Why D Is a Good Fit for CLI Tools
D compiles quickly to a native, self-contained executable, which makes it well suited for command-line utilities: you get near-C performance, a rich standard library (Phobos) covering argument parsing, file I/O, and text processing, and — when you statically link the runtime — a single binary you can copy to another machine without installing anything extra. The edit-compile-run loop with dmd is fast enough to feel closer to a scripting language than typical C++ build times.
Cricket analogy: Like a fast bowler brought on for a single fiery over without a lengthy warm-up, D's quick compile-edit-run loop skips the long build-and-link cycle a comparable C++ tool would need.
Parsing Arguments with std.getopt
std.getopt turns a raw string[] args array into typed, named options with a single call: getopt(args, "output|o", "description", &outputFile, "verbose|v", "description", &verbose) binds long and short flags directly to variables of the matching type, converting and validating as it goes, and getopt(config.required, ...) can mark an option mandatory. Passing an unparseable value for a typed option, like text where an integer is expected, throws a clear ConvException instead of silently misbehaving.
Cricket analogy: Like a match referee's coin toss producing a simple 'heads' or 'tails', std.getopt maps a --verbose flag directly onto a bool variable with no extra parsing code required.
Exit Codes and Stream Discipline
A well-behaved CLI tool writes its real output to stdout and diagnostics to stderr via stderr.writeln, and returns a distinct integer from main for each meaningful failure mode (0 for success, 1 for bad usage, 2 for a missing file, and so on) rather than always exiting 1. This makes the tool composable in shell pipelines and lets calling scripts branch on exactly what went wrong instead of just detecting 'something failed'.
Cricket analogy: Like distinguishing a specific 'no-ball' call from open play, returning a distinct non-zero exit code for each failure type lets calling scripts branch on exactly what went wrong.
Reading Files and Handling I/O Safely
std.file.readText and std.file.exists cover the common file-reading path, and wrapping risky operations in scope(exit), scope(failure), or scope(success) blocks guarantees the right cleanup runs regardless of how a function leaves — scope(exit) always runs, scope(failure) runs only if an exception propagates out, and scope(success) runs only on a normal return. Combined with D exceptions (try/catch around file operations that can throw FileException), this gives deterministic resource cleanup without needing a Java- or Go-style defer keyword or an explicit finally around every code path.
Cricket analogy: Like a groundskeeper who always covers the pitch when rain starts regardless of the match situation, scope(exit) guarantees cleanup code, such as closing a file handle, runs whether a function returns normally or throws.
import std.stdio;
import std.getopt;
import std.file : readText, exists, write;
import std.array : split;
import std.conv : to;
int main(string[] args)
{
string outputFile;
bool verbose;
uint minLength = 1;
auto helpInfo = getopt(
args,
"output|o", "Write results to this file instead of stdout", &outputFile,
"verbose|v", "Print progress information", &verbose,
"min-length|m", "Only count words at least this long", &minLength
);
if (helpInfo.helpWanted)
{
defaultGetoptPrinter("Usage: wordcount [options] <file>", helpInfo.options);
return 0;
}
if (args.length < 2)
{
stderr.writeln("error: no input file given");
return 1;
}
string path = args[1];
if (!exists(path))
{
stderr.writeln("error: file not found: ", path);
return 2;
}
scope(exit) if (verbose) stderr.writeln("done processing ", path);
auto words = readText(path).split();
size_t count = 0;
foreach (w; words)
if (w.length >= minLength)
count++;
if (outputFile.length)
write(outputFile, "word count: " ~ count.to!string ~ "\n");
else
writeln("word count: ", count);
return 0;
}scope(exit), scope(success), and scope(failure) can all appear in the same function to handle different outcomes distinctly: use scope(exit) for cleanup that must always run (closing a handle), scope(success) for work that should only happen after a clean return (committing a transaction), and scope(failure) for rollback logic that should only run when an exception unwinds the stack.
Packaging and Distributing with dub
A dub.json (or dub.sdl) manifest declares the project name, dependencies, and target type, and dub build --build=release compiles an optimized binary with debug symbols stripped and inlining enabled, in contrast to the default debug build which favors fast compilation and full stack traces. Running dub build --build=release --compiler=ldc2 swaps in the LLVM-backed compiler for better runtime performance on the shipped binary, while keeping dmd for day-to-day development where compile speed matters more.
Cricket analogy: Like the BCCI issuing one official playing-kit specification every state team must follow, a dub.json manifest gives one standard description of how to build and package a D project.
On Linux, dmd links against a shared libphobos2 by default, so a binary built on a newer distro can fail to run on an older one with a missing-symbol error; pass -static (via dflags in dub.json, e.g. "dflags": ["-static"]) to produce a fully static binary you can copy anywhere. Also note that dub build --build=release disables assert and contract checking by default (compiled with -release), so bugs that only manifest as a failed assertion in debug builds can slip through into what you actually ship — keep a separate test/CI build that runs with contracts enabled.
- D's fast compile times and ability to produce a single native executable make it a strong choice for CLI tools, especially when statically linked.
- std.getopt binds command-line flags directly to typed variables and can auto-generate --help output via defaultGetoptPrinter.
- Write real output to stdout and diagnostics to stderr, and return distinct non-zero exit codes per failure mode so calling scripts can branch precisely.
- scope(exit), scope(success), and scope(failure) give deterministic, outcome-specific cleanup without a manual finally block around every path.
- std.file.readText, std.file.exists, and std.file.write cover most file I/O needs; wrap risky calls in try/catch for FileException.
- dub build --build=release strips debug info and enables optimizations, and -static in dflags produces a portable binary independent of the target's libphobos2 version.
- Release builds compile with -release, which disables contracts and asserts, so keep a CI build with contracts enabled to catch logic errors before shipping.
Practice what you learned
1. Which standard library module binds command-line flags directly to typed variables in D?
2. Where should a well-behaved CLI tool write diagnostic and error messages?
3. Which scope statement runs its block only when an exception propagates out of the function?
4. What does dub build --build=release change compared to the default debug build?
5. Why might a release build let a logic bug slip through that a debug build would have caught?
Was this page helpful?
You May Also Like
D Best Practices
Practical conventions for writing idiomatic, maintainable D: default immutability, range-based pipelines, deliberate GC management, and design-by-contract testing.
D Quick Reference
A condensed lookup of D's core syntax — variables, arrays, functions, templates, control flow, and the most commonly used Phobos standard library modules.
D vs C++
A practical comparison of D and C++ covering memory management, compile-time metaprogramming, syntax safety, and tooling to help you decide when D is the better fit for a systems project.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics