# The C+ Manual C+ compiles to native code through LLVM. It has no garbage collector, no exceptions, no closures, no overloading, no implicit conversions, and no `null`. Memory is managed manually, policed by a borrow checker, with C ABI compatibility for FFI. The point of every one of those choices is the same: each program stays **locally legible**. You can read one function and know exactly what it does, without chasing implicit destructors, hidden conversions, or surprise allocations. The compiler enforces that property. If you slip, the diagnostic tells you precisely where and why. ## C plus packages The name is the architecture: C+ is **C (the C ABI) plus packages**. The language core is small on purpose. It gives you types, ownership, and a way to speak the C ABI in both directions, and then stops. Everything else, **including the standard library**, lives in packages. `stdlib` is itself a package under `vendor/`, not a language built-in, and the same is true of the platform bindings, allocators, parsers, and math helpers. Capability grows by adding a package, not by growing the language. That is what keeps the surface you have to read, and a model has to generate, small and predictable. Each package has its own page under [Packages](/docs/packages). > This is a single, living manual that tracks the latest release of C+. C+ is pre-1.0 and moving quickly, so the surface grows between releases; this page always reflects the current one. Every page is also available as raw Markdown — append `.md` to its URL, or use the "View as Markdown" link. ## Platform support Compiler and toolchain targets: | Platform | Status | |---|---| | macOS M-series | Supported | | Linux x86-64 | Supported | | Windows x86-64 | Supported | | Linux ARM | Planned | | Windows ARM | Planned | | ESP32 | Planned | GUI backend support: | Backend | Status | |---|---| | macOS AppKit | Supported | | Linux GTK+ | Planned | | Windows Win32 | Planned | | iOS UIKit | Planned | ## Locked principles These principles underlie every C+ design decision. They are fixed, not open questions. | # | Principle | Why | |---|---|---| | 1 | No `null` anywhere | Use `Option[T]`. Avoids the billion-dollar mistake. | | 2 | No closures or lambdas | Use a named `fn` plus `(fn_ptr, user_data)`. Eliminates capture semantics. | | 3 | No `&T` / `&mut T` reference types | Borrowing is a parameter marker, not a type. | | 4 | No exceptions | Errors are tagged-union values, matched exhaustively. | | 5 | No implicit conversions | Every width change requires `as`. | | 6 | No operator or function overloading | One name, one signature. | | 7 | No macros, decorators, or comptime | Attributes are pure metadata. | | 8 | No `class`, `function`, or `var` | Use `struct` plus `impl`, `fn`, `let`. | | 9 | No mutable-by-default | `mut` is opt-in. | | 10 | Generics use `[T]`, not `` | Avoids the `a(c)` grammar ambiguity. | | 11 | Explicit `return` | No implicit tail returns at the function level. | | 12 | `::` for types, `.` for instances | Strict separation. | | 13 | Module-private by default | `pub` is the export marker. Public symbols are intentional, not accidental. | ## Where to go next - [Getting started](/docs/getting-started) compiles and runs your first program. - [Ownership](/docs/ownership) covers the part of C+ that differs most from C. - [The borrow checker](/docs/borrow-checker) explains the one rule that makes data races a compile error. - [Error handling](/docs/error-handling) shows how fallible code works without exceptions.