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.

The loop is the design target

When C+ says it is optimized for agents, that does not mean only reducing the time or token count needed to generate source code. Generating code is one step. The design target is the complete development loop.

An agent can query the compiler's resolved view of the code, edit the relevant source, validate cheaply with cpc check, produce an executable with cpc build, run the application, and connect to its live agent surface. It can then click, type, or invoke actions, read exposed state, semantic events, and results, and use that observed behavior to decide whether to continue or return to the relevant code and repeat the loop.

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. Every operation that can crash is visible in the source itself. 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. Version 0.0.28 supports macOS, Windows, Linux, iOS, Android, ESP32, and WebAssembly. The native toolchain runs on macOS, Linux, and Windows. A macOS host cross-compiles for iOS through Xcode; Android and ESP32 use their target toolchains, while cpc-wasm supplies the WebAssembly path. Facet runs through AppKit, UIKit, Android, GTK, and Win32 backends. The language surface is small and stable by design, and the diagnostics are numbered and machine-readable. If you are evaluating it for a team, the adoption guide describes fit and maturity.