Carbon Language

Carbon is an experimental programming language designed as a potential successor to C++. Its primary design philosophy is to provide a tool that addresses the specific needs of performance-critical software while enabling a smooth transition for C++ developers.

Key aspects of Carbon's approach include:

• Incremental Adoption: Designed to be easy for C++ developers to adopt within individual libraries or existing codebases.
• Bidirectional Interoperability: High-performance interoperability with C++ is a core requirement to allow Carbon and C++ code to coexist.
• Migration Tooling: A focus on providing excellent tools to facilitate moving from C++ to Carbon.
• Developer Experience: Prioritizing an easy ramp-up for experienced C++ software engineers.

Carbon executes blocks of statements linearly by default, but execution flow can be modified using control flow statements. The primary mechanisms for controlling flow are:

• Conditionals: Use if and else for conditional execution.
• Loops:
  • while: Executes a loop body as long as a specific expression evaluates to True.
  • for: Iterates over objects, such as elements within an array.
  • break: Immediately exits the current loop.
  • continue: Skips the remainder of the current loop iteration and proceeds to the next.
• Function Returns: Use return to end execution within a function and return control to the caller.

Carbon provides a standard set of arithmetic operators for built-in types. These include unary negation and binary operations for addition, subtraction, multiplication, division, and remainder (modulo).

Common operators:

• Negation: -a
• Addition: a + b
• Subtraction: a - b
• Multiplication: a * b
• Division: a / b (truncates towards zero)
• Remainder: a % b (defined as a % b == a - (a / b) * b)

var a: i32 = 5;
var b: i32 = 3;

// -5
var negation: i32 = -a;
// 8
var sum: i32 = a + b;
// 2
var difference: i32 = a - b;
// 15
var product: i32 = a * b;
// 1
var quotient: i32 = a / b;
// 2
var remainder: i32 = a % b;

The Carbon generics feature is documented through a series of specialized design documents. To understand the implementation and design philosophy, you can refer to the following resources:

• Overview: High-level description of the generics design and links to deeper topics.
• Goals: The motivations and principles guiding the design direction.
• Terminology: A glossary of terms used to describe the generics design.
• Detailed design: In-depth technical descriptions, including:
  • Coherence: Rationale for coherent generics and comparison with alternatives.
  • Rewrite constraints: Rules governing rewrite constraints and termination guarantees.
  • Witness tables: Implementation strategies for checked generics and their use in dynamic dispatch.

The website generation process is automated via GitHub Actions (gh_pages_deploy.yaml). The build pipeline follows these steps:

1. Run prebuild.py to prepare the necessary files.
2. Build the site using Jekyll, which uses the configuration defined in _config.yml.

As of the end of 2024, the Carbon toolchain has achieved several key milestones that define its current state:

Language Implementation

• Supports imports and a working prelude.
• Supports generic types and functions (e.g., Core.Int generic integer type).
• Includes building blocks for operator overloading via interfaces.

C++ Interop and Toolchain

• Clang Integration: The toolchain can compile C++ code without system #includes.
• Build Systems: Integrated with simple Bazel build rules for continuous testing of Carbon code.
• C++ Header Support: Initial support for importing C++ headers has been implemented, though full system header support is still a work in progress.

This proposal outlines the technical details for three key components of Carbon's generics system:

1. Adapters: Mechanisms to bridge different types to satisfy specific interface requirements.
2. Associated Types and Constants: A way to define types or values that are tied to a specific implementation of an interface.
3. Parameterized Interfaces: Interfaces that can take parameters to define their behavior or requirements.

This document is a continuation of the ongoing work to define the Carbon generics feature set, building upon previous proposals regarding generics goals, terminology, and initial details.

Carbon's development is organized around long-term milestones that define the language's evolution and functional goals. These milestones are designed to provide a coherent direction for the project, spanning more than a year each.

• Milestone 0.1 (MVP): A minimum viable product designed for C++ users and developers to evaluate Carbon. It focuses on core language features, C++ interoperability, and a functioning toolchain.
• Milestone 0.2: A feature-complete product for evaluation. This milestone includes features deferred from 0.1, such as coroutines and async.
• Milestone 1.0: The stage where Carbon is no longer considered an experiment and is suitable for production use.

The Carbon Language specification is being developed to provide enough detail for independent implementations of the language. The specification is divided into two main parts: the language definition itself and the standard library definition.

• Language specification: Defines the core syntax, semantics, and rules of the Carbon language.
• Library specification: Defines the standard library provided with the language.

The Carbon project is shifting its focus to include a concrete design for memory safety alongside its ongoing C++ interop work. The 0.1 milestone target has been moved from 2025 to the end of 2026 to accommodate this change.

Key goals for 2025 include:

• Completing features required for non-template C++ interop.
• Implementing the interop layer for non-template Carbon ↔ C++, prioritizing calling C++ APIs from Carbon.
• Providing full support for compiling C++ code via the Carbon toolchain using Clang.
• Establishing a detailed strategy for memory safety.
• Designing for compile-time and type-system based temporal and mutation safety.

Expressions in Carbon are syntax components that produce values. Because types are treated as values in Carbon, type specifications are also considered expressions.

Example of expressions in a function signature:

fn Foo(a: i32*) -> i32 {
  return *a;
}

In this example:

• i32* (parameter type) is an expression.
• i32 (return type) is an expression.
• *a (operand of the return statement) is an expression.