223d0397c0
Carbon is accelerating and adjusting its safety strategy, specifically to flesh out its memory safety strategy and reflect simplifying developments in the safety space. This proposal replaces the previous directional safety strategy with a new concrete and updated framework for the safety design. It includes a specific framework for memory safety, simplified build modes, specific "safety modes", and terminology. This proposal also provides a _directional_ suggestion for temporal and data-race safety specifically. In addition to fully building out the above directional component, there are several other aspects of our safety design that will follow in subsequent proposals. The hope is to establish the initial framework here. --------- Co-authored-by: Dana Jansens <danakj@orodu.net> Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com> Co-authored-by: Mike Forster <michael@forster.pro> Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Principles
Some language goals will have widely-applicable, high-impact, and sometimes non-obvious corollaries. We collect concrete language design principles in this directory as a way to document and clarify these. Principles clarify, but do not supersede, goals and priorities. Principles should be used as a tool in making decisions, and to clarify to contributors how decisions are expected to be made.
A key difference between a principle and the design of a language feature is that a principle should inform multiple designs, whereas a feature's design is typically more focused on achieving a specific goal or set of goals. The principle can help achieve consistency across those multiple designs.
Note that these principles seek to establish both the approaches the project wants to pursue, as well as those we want to exclude.