Chandler Carruth
7612b3d821
Document the phase of associated constants, which the discussions of
contextual phase defaults never covered: an associated constant is
always a checked generic binding. This is deliberately not presented as
a contextual default, because no other phase is possible for the
construct; correspondingly, no phase keyword (including `template`) is
allowed on one. Also rework the associated constants section of the
design README where the migration left a non-sequitur ("set to
compile-time values ... and so are defined using a `let` declaration"):
describe the `let` syntax and the binding's contextual phase separately.
Use consistent terminology for bindings versus constants. Bindings are
"checked" or "template" (generic) bindings, replacing the "symbolic
binding" and bare "generic binding" terms, so "symbolic" now only
describes constants and values. The "Symbolic facet bindings" section of
the generics details becomes "Checked facet bindings". The
expression-phase terms "symbolic constant" and "template constant" are
unchanged, and the binding-pattern definitions now name the constant
each kind binds. Template bindings are additionally described as
dependent and late checked, with each instantiation providing the
binding's value.
Also normalize the remaining "regular parameter" mentions to "runtime
parameter" to match the binding terminology, and describe the
compile-time "let template" as introducing a template generic binding
"T: C" whose uses are template constants.
Assisted-by: Claude Code
Docs
This directory contains current, accepted documentation underpinning Carbon. These documents cover all aspects of Carbon ranging from the project down to detailed designs for specific language features.
If you're trying to learn more about Carbon, we recommend starting at
/README.md.
Design
Carbon language's design and rationale are documented in the
design/ directory. This documentation is intended to
support the following audiences:
- People who wish to determine whether Carbon would be the right choice for a project compared to other existing languages.
- People working on the evolution of the Carbon language who wish to understand the rationale and motivation for existing design decisions.
- People working on a specification or implementation of the Carbon language who need a detailed understanding of the intended design.
- People writing Carbon code who wish to understand why the language rules are the way they are.
This is in contrast to proposals, which document the individual decisions that led to this design (along with other changes to the Carbon project), including the rationale and alternatives considered.
Project
The project/ directory contains project-related
documentation for Carbon, including:
- goals, and the principles and roadmap derived from those goals,
- how the project works, and
- how to contribute.
Guides
The guides/ directory contains to-be-written end-user
documentation for developers writing programs in Carbon.
Spec
The spec/ directory contains the to-be-written formal
specification of the Carbon language. This is for implementers of compilers or
other tooling. This is intended to complement the toolchain.