A new systems programming language specification defines a language that looks like C on the surface but enforces memory safety, ownership, and borrowing at the language level rather than leaving them to programmer convention. CobaltC is statically typed, targets native execution, and provides explicit ownership, deterministic destruction, compiler-checked borrowing, and safe concurrency without garbage collection.
What CobaltC actually is
CobaltC is a C-like language with ordinary functions, generics, explicit memory and ownership safety, and modules. It provides the data layout and control flow that C developers expect, but the rules that prevent buffer overflows, use-after-free errors, and data races are language semantics enforced by the compiler, not guidelines that developers must follow manually.
The language is intended for software requiring predictable resource management, strong memory safety, native execution, and controlled interaction with low-level facilities. It does not provide classes, object-oriented inheritance, or dynamic dispatch. There is no garbage collection. Resource cleanup happens through deterministic destruction at language-defined ownership and scope boundaries.
Visibility is defined at the module boundary through explicit export declarations. There are no public, private, or protected keywords on individual declarations. A module's export block lists the declarations that external code may access. Everything else remains module-local. The language does not prescribe a source-file or directory layout. Module relationships are defined through module declarations, imports, and exports, not through file-system conventions.
How memory safety works
Managed pointers are the source-language representation of borrow capabilities. A borrow is the semantic relationship between an access capability and a referent. The managed pointer value carries that capability. Managed pointers do not represent ownership unless a language rule explicitly states otherwise.
The language defines four managed pointer types. A shared non-null pointer permits read-only access. A shared nullable pointer permits read-only access but may be null. An exclusive mutable non-null pointer permits exclusive mutable access. An exclusive mutable nullable pointer permits exclusive mutable access and may be null. The distinction between shared and exclusive access prevents data races at compile time.
Owned values are values whose lifetime and destruction are controlled by the owning storage location according to the ownership rules. A borrowed managed pointer is not an owned value unless a language rule explicitly states otherwise. This distinction matters for deterministic cleanup: owned values are destroyed when their owning storage goes out of scope, while borrowed pointers simply lose their access capability.
Unsafe operations and foreign-function interfaces form explicit boundaries outside the automatic safety guarantees of safe CobaltC. Code that needs to perform operations the compiler cannot verify must explicitly enter an unsafe context. The specification requires that operations expressible in safe CobaltC without entering an unsafe context must not have undefined behavior.
The type system
CobaltC defines primitive types including bool, char, void, signed and unsigned integers from 8 to 128 bits, pointer-sized integer types, and 32-bit and 64-bit floating-point types. Integer overflow, division by zero, and invalid shift operations are not silently memory-unsafe. The implementation must diagnose statically provable invalid constant operations and must otherwise apply defined failure semantics.
Compound types include structs, enums, arrays, function types, managed pointers, raw pointers, and generic types. Structs and enums are nominal types. Type aliases do not create new nominal types. Arrays use the syntax T[N] where N is the length. Function types use the function declaration form.
The language includes language-provided abstractions like String, Vector, and Result that are specified as library types rather than primitive types. This means the core language stays small while the standard library provides the data structures that applications need.
Modules and visibility
A module declaration has the form module name;. A translation unit defines exactly one module. Modules may import declarations or selective declarations from other modules. Name resolution is lexical and module-aware. An unresolved name is a compile-time error. Imports do not implicitly re-export declarations.
The export block lists declarations that are externally accessible from the module. Declarations not listed remain module-local. A submodule is a distinct module and is not exported by its parent merely because it exists beneath that parent in the source-file hierarchy. A module hierarchy does not implicitly grant access between parent, child, or sibling modules.
This approach provides an explicit software-engineering boundary. Declarations that are not exported may be changed without changing the externally visible interface, provided the specified behavior and requirements of the exported interface remain compatible. Two translation units must not define the same module for one program.
What the specification does not cover
The specification deliberately leaves implementation technique, representation, and compiler architecture to the implementor except where those choices affect a normative language guarantee. The language does not prescribe how the compiler should generate code, what data layouts to use, or how to organize the compilation pipeline.
The specification also does not provide classes, inheritance, or dynamic dispatch. The language is explicitly designed for systems programming where these features add overhead and complexity without proportional benefit. Developers who need polymorphism use generics and trait-like patterns rather than class hierarchies.
For developers evaluating systems programming languages, CobaltC occupies a specific niche: it provides the memory safety guarantees of Rust-like ownership systems but with a C-like syntax and control flow that may feel more familiar to developers coming from C or C++. The explicit ownership, borrowing, and destruction rules are enforced by the compiler, but the language surface remains close to what systems programmers already know.