Jon Meow
d031f3cdab
Co-authored by: chandlerc - Based on [PR 22](https://github.com/carbon-language/carbon-lang/pull/83) - [Idea topic](https://forums.carbon-lang.dev/t/proposal-for-an-incomplete-rough-high-level-overview-ready-for-early-feedback/52) - [RFC](https://forums.carbon-lang.dev/t/rfc-an-incomplete-early-and-in-progress-overview-of-the-language-design/73) - [Decision announcement](https://forums.carbon-lang.dev/t/accepted-an-incomplete-early-and-in-progress-overview-of-the-language-design/110) This proposal should be considered a starting point of the language design. It's not intended to be final; language details may change. This is intended to offer a reasonable starting point for: - Example code. - Conceptualizing Carbon at a high level. - Reasonable, but not necessarily final, approaches to features in README.md. - If any idea is obviously bad, we can clean it up here. This proposal is not intended to achieve: - A whole language design. - This is way too much work for a single proposal; this is a skeletal framework only. - As we work on feature-specific designs, we may decide to use other approaches. That's fine: we only need somewhere to start. - The summaries in README.md may be expected to change over time. - Feature-specific files aren't intended to be well-written or comprehensive. They are a quick jot of prior thoughts. - We want to avoid getting stuck on language details that we should consider more carefully regardless. If you're passionate about a feature, please feel free to start a new proposal for it. - Each and every aspect of the suggested overview should be subject to careful examination and justification before it becomes a settled plan of record. Chandler started this with https://github.com/carbon-language/carbon-lang/pull/22. I've taken it over with the following changes: - More of a directory hierarchy. - Trying to thin out the main file (now README.md) to lighter summaries of features. - Details/rationale/alternatives should be in feature-specific files. - Draft files are linked as references where added. For an example of how we may proceed with feature-specific designs, see https://github.com/carbon-language/carbon-lang/pull/80. In this structure: - docs/design/README.md mentions interoperability, with a light overview. - The light overview is not yet in https://github.com/carbon-language/carbon-lang/pull/80. - docs/design/interoperability/README.md goes into more depth on interoperability, covering key points of the approach. - Individual files in docs/design/interoperability/* go into more depth on interoperability. Simple designs may not have a subdirectory. All current feature-specific designs do not -- they may be moved later.
2.9 KiB
Naming conventions
Table of contents
TODO
This is a skeletal design, added to support the overview. It should not be treated as accepted by the core team; rather, it is a placeholder until we have more time to examine this detail. Please feel welcome to rewrite and update as appropriate.
Overview
We would like to have widespread and consistent naming conventions across Carbon code to the extent possible. This is for the same core reason as naming conventions are provided in most major style guides. Even migrating existing C++ code at-scale presents a significant opportunity to converge even more broadly and we're interested in pursuing this if viable.
Our current proposed naming convention, which we at least are attempting to follow within Carbon documentation in order to keep code samples as consistent as possible, is:
UpperCamelCasefor names of compile-time resolved constants, such that they can participate in the type system and type checking of the program. Comple-time constants fall into two categories:- Template constants that can be used in type checking, including literals.
- Generic constants whose value is not used in type checking, but will be used as part of code generation.
lower_snake_casefor names of run-time resolved values.
As an example, an integer that is a compile-time constant sufficient to use in
the construction a compile-time array size might be named N, where an integer
that is not available as part of the type system would be named n, even if it
happened to be immutable or only take on a single value. Functions and most
types will be in UpperCamelCase, but a type where only run-time type
information queries are available would end up as lower_snake_case.
We only use UpperCamelCase and lower_snake_case (skipping other variations
on both snake-case and camel-case naming conventions) because these two have the
most significant visual separation. For example, the value of adding
lowerCamelCase for another set seems low given the small visual difference
provided; in particular, one-word identifiers would have no difference.
The rationale for the specific division between the two isn't a huge or fundamental concept, but it stems from a convention in Ruby where constants are named with a leading capital letter. The idea is that it mirrors the English language capitalization of proper nouns: the name of a constant refers to a specific value that is precisely resolved at compile time, not just to some value. For example, there are many different shires in Britain, but Frodo comes from the Shire -- a specific fictional region.