dlib is a collection of native D language libraries that implement common functionality (read below about our definition of "common"). It is useful for various higher-level projects - such as game engines, rendering pipelines and multimedia applications.

Currently dlib contains the following packages:

• dlib.core - modules that are widely used by other packages
• dlib.memory - allocators and memory management functions
• dlib.container - containers and data structures
• dlib.filesystem - abstract FS interface and its implementations for Windows and POSIX filesystems
• dlib.math - linear algebra and numerical analysis (vectors, matrices, quaternions, etc.)
• dlib.geometry - computational geometry (ray casting, primitives, intersection, etc.)
• dlib.image - image processing (filters, color correction, FFT, HDRI, graphics formats I/O, support for 8 and 16-bit RGBA buffers and floating point operations)
• dlib.audio - sound processing (synthesizers, audio formats I/O)
• dlib.network - networking and web functionality
• dlib.serialization - data serialization
• dlib.coding - data coding and compression algorithms
• dlib.text - text processing

Why dlib? Read the Rationale. There's also FAQ that explains dlib's design decisions.

dlib can be used both in garbage-collected and GC-free applications. Using its GC-based functionality is straightforward and D-ish, while following GC-free path requires writing more verbose code.

Note: For historical/compatibility reasons, dlib is neither betterC nor @nogc. We support GC-compatible and GC-free programming styles under one unified API, which consequently can't be constrained as @nogc.

Look Best Practices for more details on this topic.

On GitHub issue tracker, we use several labels to mark bugs and improvements:

• Breaking change. This is self-descriptive: an improvement that breaks backward compatibility;
• Bug. A bug that should be fixed without API change;
• Enhancement. A non-breaking improvement of existing functionality (e.g. optimization or a new feature);
• Missing. Appears when existing functionality is removed due to regressions and needs to be rewritten, or when some implementation is not complete;
• New functionality. Self-descriptive: a new functionality request.