C+
Reference · View as Markdown

Stability and versioning

C+ keeps a deliberately small language surface. New capability goes into packages and tooling, not the core, so the language you read — and a model generates — stays small and predictable. The core itself does still change: to fix soundness and correctness bugs, and, more rarely, to refine syntax. Those changes ship only in versioned releases, and every release is archived. v0.0.23, for example, was a soundness and C-ABI hardening release that also refined the interface-impl syntax (impl Type for Interface, see §9.3 of the specification).

This page states what stays stable, what changes between releases, and how packages version on their own cadence. The language specification is the normative description of the current surface.

What stays stable

  • A small surface. The core stays small on purpose: types, ownership, the C ABI, and a little construction sugar. Capability grows by adding packages, not by growing the language, so the grammar and keyword set you learn stay compact.
  • Source compatibility is the goal. A program the current compiler accepts is intended to keep compiling, with the same meaning, on later releases. When a release does change whether a program compiles — almost always a soundness fix that rejects a program that was never sound — it is called out as such, and the release it compiled under stays available as an archive.
  • A stable, dated target for tools and agents. The grammar, the cpc query / cpc mcp code graph, the error codes, and the /llms.txt snapshots describe a specific, archived release. Tooling built against a version has a fixed target, and a citation can name the version it was written against.

What changes between releases

  • Soundness and correctness fixes. Where the compiler and the specification disagree, one is corrected to match the other. That can mean a program that was wrongly accepted is later rejected, or one that was wrongly rejected later compiles. This is the bulk of a release like v0.0.23.
  • Occasional surface refinements. The language surface changes rarely and deliberately. When it does — like the v0.0.23 interface-impl order — it ships in a versioned release with the change documented, and the prior release stays archived at its own URL.
  • Diagnostics. Error and warning wording, spans, notes, and machine-applicable suggestions improve freely. The stable error codes and their meanings are the contract; the exact message text is not.
  • Performance and code generation. Optimisation, codegen quality, and ABI lowering improve over time. The language asks for no runtime tax for its safety, and that work is ongoing.
  • Tooling. cpc subcommands (build, check, run, test, fmt, doc, query, mcp, lsp) and the editor surface evolve and gain features — this is where most ongoing work lands.
  • Targets. Support for additional targets and cross-compilation back-ends can be added; adding a target does not change the language.
  • The standard library and packages. stdlib and every package under vendor/ evolve on their own cadence (see below).

The compiler is the authority

The specification is verified against cpc and its test suite, but where the two ever disagree the compiler wins — run cpc check or cpc build and trust the diagnostic. The in-repo test suite is the executable conformance record. If you find a case where the compiler and the spec disagree, that is a bug worth reporting.

Packages version independently

The package-first model is what keeps the language small. Capability that another language would build into the core lives in a package here, and each package carries its own version and moves at its own pace:

  • A package declares its dependencies and their versions in Cplus.toml and is resolved under vendor/. See Modules and packages and the package manager.
  • A new package, or a new release of an existing one, adds capability without touching the language. It builds against the same small language surface.
  • This is the intended path for everything additive: UI builders, FFI bindings, numeric kernels, embedded peripherals. The packages index lists what ships today.

Documentation versioning

The manual you are reading tracks the current release. Every release is also archived: older versions stay available at /docs/{version} and are never removed or collapsed — they are intentional archives, not stale pages. When you cite the manual, cite the version. /docs and /llms.txt are authoritative for the latest release (v0.0.23).

For why the design is the way it is, see the design FAQ.