Richard Smith
35a0bf1c7e
This proposal addresses the question of whether we should perform a fully top-down compilation (like in C), a mostly top-down compilation (like in C++), or whether we should allow information from later in the same source file to be used in earlier program constructs (like in Rust, Swift, Java, C#, Haskell, and so on).
The proposed direction is:
- Entities declared later in the same source file cannot be used earlier; top-down semantics apply everywhere.
- As an exception, class member function bodies are parsed as if they appeared after the class.
- Forward declarations can be used to separate interface from implementation and to allow entities to be used before they are defined.
- The behavior of the program is nonetheless required to be the same as if we had a globally-consistent rule: it's always a hard error to depend on any information that is not known or that is provided later.
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.