Why C+ exists

The premise

For most of software history, the bottleneck was typing the code. Languages optimized for the author: terse syntax, clever inference, features that let a fluent human move fast. That tradeoff is now inverted. The model does the typing. The scarce resource is a person who can read what was generated and be certain it is correct.

C+ is built for reading and verifying, not for showing off at the keyboard. Every program stays locally legible: you can read one function and know exactly what it does, what it owns, and what it touches, without chasing hidden control flow across the codebase.

What we left out, on purpose

Every feature C+ omits removes a class of mistake a model could make and a person would have to catch:

• No null, so there are no null dereferences to review.
• No exceptions, so control flow is the code you can see. Errors are values, matched explicitly.
• No closures, so there are no capture semantics to get subtly wrong.
• No overloading, so one name resolves to exactly one signature.
• No implicit conversions, so every width change is visible in the source.
• No hidden allocations, so a hot path that must not touch the heap can be proven not to.

Ownership is written on every parameter. unsafe is written at every operation that needs it. Imports name their source. Nothing important is implicit.

Safety without a tax on speed

C+ compiles directly to native code through LLVM. There is no garbage collector and no runtime overhead. The borrow checker enforces aliasing-xor-mutation, so data races do not compile, and the same guarantees it proves are the aliasing facts the optimizer needs to vectorize hot loops. Safety and speed come from the same analysis rather than fighting each other.

When a function must be deterministic, you mark it #[realtime] and the compiler proves across the entire call graph that it never allocates, never blocks, and never recurses unbounded. That is a compile error if violated, not a lint you can ignore.

It meets the code you already have

C+ speaks the C ABI in both directions. It calls C, Objective-C, and Metal directly through extern fn with no binding layer, and because cpc emits standard C-ABI object files, existing C and C++ projects link C+ straight back. You can replace one function at a time inside a CMake build, until the binary stands on its own. Adoption does not require a rewrite.

Where it is today

C+ is pre-1.0 and moving quickly. The toolchain ships for macOS and Linux, with an LSP for VS Code and Neovim. The language surface is small and stable by design, the diagnostics are numbered and machine-readable, and every code sample in the guides is compiled against the real cpc before it ships. If you are evaluating it for a team, the adoption guide is an honest read on fit and maturity.