dlib 2.0

dlib 2.0 is the successor of dlib 1.x. It will have more thoroughly thought out architecture and more lower-level features.

Premises

• dlib 1.x historically went its own unique way without considering the ecosystem. Now D community is embracing @nogc and betterC. New libraries should be usable together, and so they should be based on the same constraints and idioms.
• dlib 1.x aims to be backward-compatible as much as possible. As a result, too many trade-offs accumulated over time while adding new features, and the code became not very consistent. GC-free and GC-dependent functions are mixed together.
• dlib 1.x requires too much understanding of its internals from user. There are parts that "just work", but some parts often work in counter-intuitive way, or require some arcane boilerplate code which make them not very pleasant to use (for examle, dlib.filesystem.stdfs or dlib.network).

Principles

dlib 2.0 will address most of the drawbacks of classic dlib, including:

• Incompatibility with @nogc and betterC
• Dependency on Phobos. dlib will implement the most basic functionality in platform-independent manner, and only use Phobos when there's no other choise
• Mixed GC-dependent and GC-free code. There will be separate layers for betterC, @nogc and GC-dependent functionality.

Because classes require druntime and significant background work implicitly added by the compiler, all OOP features should also be separated. The library will consist of several layers, from lowest possible level (betterC) to runtime-dependent, where each layer is based on previous.

API structure

dlib 2.0 will consist of several API layers:

1. dcore - betterC-compliant low-level procedural API, a minimal standard library replacement. Completely standalone. Support for bare metal/WebAssembly/ARM.
   • Dynamic memory allocation (if available for target platform). malloc/free callbacks for custom low-level allocation mechanism
   • Standard I/O, pipelines (if available for target platform)
   • Basic filesystem (if available for target platform)
   • Portable math
   • Linear algebra
   • Basic containers: dynamic array, dictionary, string
2. dlib2 - @nogc object-oriented API with high-level features. Serves as an abstract interface for system APIs. Will support at least Unix and Windows. Based on dcore and @nogc parts of Phobos.
   • Streams
   • Multithreading
   • Abstract filesystem
   • Image processing
   • Audio processing
   • JSON
   • Networking
   • C library binding framework
   • Raycasting engine (dray port?)
3. dlib - classic dlib 0.x/1.x API. As much functionality as possible will go to dcore and dlib2, this API will be only for backwards compatibility. Based on dcore, dlib2 and Phobos.
4. dlib3 - a home for experimental/optional features.
   • New image decoder based on stb which is faster than dlib's native decoders. Ideally stb_image should be ported to D for better portability and ease of use
   • GPU acceleration for image filters via OpenCL
   • Real-time 2D canvas with vector shapes and text (based on Vulkan or, better, WebGPU).

Math library

dcore provides its own math package, dcore.math. Its purpose is to implement all standard math functions in a portable manner, if they are not available for the target platform. It makes a compile-time choise between available implementations (std.math, libc math, LLVM intrinsics), so the user will always get the most efficient ones.

If LDC is used to compile the library, LLVM intrinsics are used extensively (where applicable). Otherwise, std.math is preferred if FreeStanding or NoPhobos version flags are not present. In NoPhobos mode C runtime functions are used. In FreeStanding mode (bare metal) the library falls back to built-in portable implementations.

Memory Management

TODO

WebAssembly support status

dcore already supports WASM. A number of JS functions are required on browser side: there will be an implementation ready to include into user projects.