From d22b55f16ddf84fb33450d1c0d9b1e6b9ed79302 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 29 Sep 2021 20:09:00 +0000 Subject: [PATCH 01/16] Filling out template with PR 861 --- proposals/p0861.md | 62 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 proposals/p0861.md diff --git a/proposals/p0861.md b/proposals/p0861.md new file mode 100644 index 0000000000000..a3adbc400ff87 --- /dev/null +++ b/proposals/p0861.md @@ -0,0 +1,62 @@ +# Naming conventions + + + +[Pull request](https://github.com/carbon-language/carbon-lang/pull/861) + + + +## Table of contents + +- [Problem](#problem) +- [Background](#background) +- [Proposal](#proposal) +- [Details](#details) +- [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) +- [Alternatives considered](#alternatives-considered) + + + +## Problem + +TODO: What problem are you trying to solve? How important is that problem? Who +is impacted by it? + +## Background + +TODO: Is there any background that readers should consider to fully understand +this problem and your approach to solving it? + +## Proposal + +TODO: Briefly and at a high level, how do you propose to solve the problem? Why +will that in fact solve it? + +## Details + +TODO: Fully explain the details of the proposed solution. + +## Rationale based on Carbon's goals + +TODO: How does this proposal effectively advance Carbon's goals? Rather than +re-stating the full motivation, this should connect that motivation back to +Carbon's stated goals for the project or language. This may evolve during +review. Use links to appropriate goals, for example: + +- [Community and culture](/docs/project/goals.md#community-and-culture) +- [Language tools and ecosystem](/docs/project/goals.md#language-tools-and-ecosystem) +- [Performance-critical software](/docs/project/goals.md#performance-critical-software) +- [Software and language evolution](/docs/project/goals.md#software-and-language-evolution) +- [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write) +- [Practical safety and testing mechanisms](/docs/project/goals.md#practical-safety-and-testing-mechanisms) +- [Fast and scalable development](/docs/project/goals.md#fast-and-scalable-development) +- [Modern OS platforms, hardware architectures, and environments](/docs/project/goals.md#modern-os-platforms-hardware-architectures-and-environments) +- [Interoperability with and migration from existing C++ code](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code) + +## Alternatives considered + +TODO: What alternative solutions have you considered? From 02ce3215b8cf823e79e2d703e84a0826a908afdb Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 29 Sep 2021 21:05:17 +0000 Subject: [PATCH 02/16] Checkpoint --- proposals/p0861.md | 98 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 91 insertions(+), 7 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index a3adbc400ff87..bf883eec28242 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -16,6 +16,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Background](#background) - [Proposal](#proposal) - [Details](#details) + - [Constants](#constants) + - [Properties](#properties) - [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) - [Alternatives considered](#alternatives-considered) @@ -23,22 +25,104 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception ## Problem -TODO: What problem are you trying to solve? How important is that problem? Who -is impacted by it? +The goal of this proposal is to establish naming conventions for: + +- Idiomatic Carbon code. +- Carbon-provided features, including: + - Keywords, such as `fn` or `for`. + - Basic types, such as `i32` or `bool`. + - Complex types, such as `String`. + +The reason for resolving this through proposal is to ensure we're headed in a +reasonably consistent path as we write early documentation and example code. ## Background -TODO: Is there any background that readers should consider to fully understand -this problem and your approach to solving it? +Naming conventions are an issue frequently addressed by style guides. A few +examples of language-provided guidelines are: + +- [Effective Go](https://golang.org/doc/effective_go#names) +- [Python's PEP 8](https://www.python.org/dev/peps/pep-0008/#naming-conventions) + - Note PEP 8 offers a list of + [naming styles](https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles). +- [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/naming.html) +- [Swift's API Design Guidelines](https://swift.org/documentation/api-design-guidelines/#general-conventions) + +Issue +[#750 Naming conventions for Carbon-provided features](https://github.com/carbon-language/carbon-lang/issues/750) +discusses options further. ## Proposal -TODO: Briefly and at a high level, how do you propose to solve the problem? Why -will that in fact solve it? +Only `UpperCamelCase` and `lower_snake_case` conventions will be used, in order +to minimize the variation in rules. + +- For idiomatic Carbon code: + - `UpperCamelCase` will be used when the identifier can be resolved to a + specific value at compile-time. + - `lower_snake_case` will be used when the identifier's value won't be + known until runtime, such as for variables. + - Private class members will have a suffix `_`. +- For Carbon-provided features: + - Keywords will use `lower_snake_case`, but should typically be a single + word. + - Basic Carbon types will be named similarly to keywords. + - Other code will use the guidelines for idiomatic Carbon code. + +In other words: + +| Item | Convention | Explanation | +| ---------------------- | ------------------ | ------------------------------------------------------------------------------------------ | +| Packages | `UpperCamelCase` | Used for compile-time lookup. | +| Types | `UpperCamelCase` | Resolved at compile-time. | +| Functions | `UpperCamelCase` | Resolved at compile-time. | +| Methods | `UpperCamelCase` | Equivalent to functions. | +| Generic parameters | `UpperCamelCase` | May vary based on inputs, but are ultimately resolved at compile-time. | +| Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants] for more remarks. | +| Variables | `lower_snake_case` | May be reassigned and thus require runtime information. | +| Member variables | `lower_snake_case` | Behave like variables. See [properties](#properties) for more remarks. | +| Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | +| Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | +| Basic Carbon types | `lower_snake_case` | Treated as similar to keywords. | +| Complex Carbon types | `UpperCamelCase` | Behave like normal types. | ## Details -TODO: Fully explain the details of the proposed solution. +### Constants + +While `let` may be used to designate a constant, consider the following code: + +```carbon +package Example; + +let CompileTimeConstant: i32 = 7; + +fn RuntimeFunction(let runtime_constant: i32); +``` + +In this example, `CompileTimeConstant` has a singular value (`7`) which is known +at compile-time. As such, it uses `UpperCamelCase`. + +On the other hand, `runtime_constant` may be constant due to `let`, but it is +assigned at runtime when `RuntimeFunction` is called. Its value is only known in +a given runtime invocation of `RuntimeFunction`. As such, it uses +`lower_camel_case`. + +### Properties + +> NOTE: Property syntax hasn't been established for Carbon, but is expected, so +> this proposal aims to include it. + +The primary purpose of a +[property]() is to provide +a transparent wrapper to a private member variable. This may be done for reasons +such as guaranteeing lazy initialization of data on first access, or providing a +helpful breakpoint for debug access. Regardless of the reason, we want it to be +trivial for properties to replace member variables without affecting clients of +an API, and so they use the same naming scheme. + +Private member variables should use a `_` suffix in order to prevent name +collisions. We discourage private properties. ## Rationale based on Carbon's goals From e63840577a940cc43fde3257960083d2f1a3a0ae Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 29 Sep 2021 23:18:42 +0000 Subject: [PATCH 03/16] Checkpoint --- proposals/p0861.md | 40 +++++++++++++++++++++++----------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index bf883eec28242..c40d05e0be172 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -18,6 +18,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Details](#details) - [Constants](#constants) - [Properties](#properties) + - [Carbon type naming](#carbon-type-naming) - [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) - [Alternatives considered](#alternatives-considered) @@ -30,8 +31,8 @@ The goal of this proposal is to establish naming conventions for: - Idiomatic Carbon code. - Carbon-provided features, including: - Keywords, such as `fn` or `for`. - - Basic types, such as `i32` or `bool`. - - Complex types, such as `String`. + - Type literals, such as `i32`. + - Types, such as `bool` or `String`. The reason for resolving this through proposal is to ensure we're headed in a reasonably consistent path as we write early documentation and example code. @@ -83,8 +84,9 @@ In other words: | Member variables | `lower_snake_case` | Behave like variables. See [properties](#properties) for more remarks. | | Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | | Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | -| Basic Carbon types | `lower_snake_case` | Treated as similar to keywords. | -| Complex Carbon types | `UpperCamelCase` | Behave like normal types. | +| Type literals | `lower_snake_case` | Equivalent to keywords. | +| Booleans | `lower_snake_case` | Behave like keywords. This is `bool`, `true`, and `false`. | +| Other Carbon types | `UpperCamelCase` | Behave like normal types. | ## Details @@ -124,22 +126,26 @@ an API, and so they use the same naming scheme. Private member variables should use a `_` suffix in order to prevent name collisions. We discourage private properties. -## Rationale based on Carbon's goals +### Carbon type naming + +Carbon types are split into a few categories: + +- Type literals from issue + [#543: pick names for fixed-size integer types](https://github.com/carbon-language/carbon-lang/issues/543): + `i`, `u`, `f` +- Booleans: `bool`, `true`, `false` +- Other Carbon types: `Int`, `UnsignedInt`, `String` -TODO: How does this proposal effectively advance Carbon's goals? Rather than -re-stating the full motivation, this should connect that motivation back to -Carbon's stated goals for the project or language. This may evolve during -review. Use links to appropriate goals, for example: +The dividing line between these is being decided on a case-by-case basis: `bool` +reasonable expectation may be that a type that is neither generic (as with +`Int`'s generic parameter for size) nor provides non-operator methods (as with a +`Substring()` method on `String`) is a basic type for naming purposes, while +other types are complex types for naming purposes. + +## Rationale based on Carbon's goals -- [Community and culture](/docs/project/goals.md#community-and-culture) -- [Language tools and ecosystem](/docs/project/goals.md#language-tools-and-ecosystem) -- [Performance-critical software](/docs/project/goals.md#performance-critical-software) -- [Software and language evolution](/docs/project/goals.md#software-and-language-evolution) - [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write) -- [Practical safety and testing mechanisms](/docs/project/goals.md#practical-safety-and-testing-mechanisms) -- [Fast and scalable development](/docs/project/goals.md#fast-and-scalable-development) -- [Modern OS platforms, hardware architectures, and environments](/docs/project/goals.md#modern-os-platforms-hardware-architectures-and-environments) -- [Interoperability with and migration from existing C++ code](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code) + - The primary purpose of naming conventions is to provide ## Alternatives considered From 4b275452d59e4879126ba56263220a0ba989391d Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 30 Sep 2021 16:31:04 +0000 Subject: [PATCH 04/16] Drafting --- proposals/p0861.md | 114 +++++++++++++++++++++++++++++++++++++-------- 1 file changed, 94 insertions(+), 20 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index c40d05e0be172..f2df0e989ecc1 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -14,13 +14,16 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Problem](#problem) - [Background](#background) + - [Cross-language precedent](#cross-language-precedent) + - [Carbon artifacts](#carbon-artifacts) - [Proposal](#proposal) - [Details](#details) - [Constants](#constants) - [Properties](#properties) - - [Carbon type naming](#carbon-type-naming) + - [Carbon-provided item naming](#carbon-provided-item-naming) - [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) - [Alternatives considered](#alternatives-considered) + - [Establish a rubrik for naming](#establish-a-rubrik-for-naming) @@ -39,6 +42,8 @@ reasonably consistent path as we write early documentation and example code. ## Background +### Cross-language precedent + Naming conventions are an issue frequently addressed by style guides. A few examples of language-provided guidelines are: @@ -49,9 +54,22 @@ examples of language-provided guidelines are: - [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/naming.html) - [Swift's API Design Guidelines](https://swift.org/documentation/api-design-guidelines/#general-conventions) -Issue -[#750 Naming conventions for Carbon-provided features](https://github.com/carbon-language/carbon-lang/issues/750) -discusses options further. +### Carbon artifacts + +Related issues: + +- Issue + [#543: pick names for fixed-size integer types](https://github.com/carbon-language/carbon-lang/issues/543) + covers numeric type literal naming. +- Issue + [#750: Naming conventions for Carbon-provided features](https://github.com/carbon-language/carbon-lang/issues/750) + was used for initial naming convention discussion. + +Related proposals: + +- Proposal + [#720: Property naming in C++](https://github.com/carbon-language/carbon-lang/pull/720) + covers nuances of property naming. ## Proposal @@ -63,6 +81,8 @@ to minimize the variation in rules. specific value at compile-time. - `lower_snake_case` will be used when the identifier's value won't be known until runtime, such as for variables. + - Properties will use this style because they are intended to be + interchangeable with member variables. - Private class members will have a suffix `_`. - For Carbon-provided features: - Keywords will use `lower_snake_case`, but should typically be a single @@ -85,7 +105,8 @@ In other words: | Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | | Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | | Type literals | `lower_snake_case` | Equivalent to keywords. | -| Booleans | `lower_snake_case` | Behave like keywords. This is `bool`, `true`, and `false`. | +| Booleans | `lower_snake_case` | Equivalent to keywords. | +| `Self` and `Super` | `UpperCamelCase` | These are similar to compile-time constant types on a class. | | Other Carbon types | `UpperCamelCase` | Behave like normal types. | ## Details @@ -108,7 +129,7 @@ at compile-time. As such, it uses `UpperCamelCase`. On the other hand, `runtime_constant` may be constant due to `let`, but it is assigned at runtime when `RuntimeFunction` is called. Its value is only known in a given runtime invocation of `RuntimeFunction`. As such, it uses -`lower_camel_case`. +`lower_snake_case`. ### Properties @@ -126,27 +147,80 @@ an API, and so they use the same naming scheme. Private member variables should use a `_` suffix in order to prevent name collisions. We discourage private properties. -### Carbon type naming +### Carbon-provided item naming -Carbon types are split into a few categories: +Carbon-provided items are split into a few categories: -- Type literals from issue - [#543: pick names for fixed-size integer types](https://github.com/carbon-language/carbon-lang/issues/543): - `i`, `u`, `f` -- Booleans: `bool`, `true`, `false` -- Other Carbon types: `Int`, `UnsignedInt`, `String` +- Keywords; for example, `for`, `fn`, and `var` +- Type literals; for example, `i`, `u`, and `f` +- Booleans; for example, `bool`, `true`, and `false` + - The separate categorization of booleans should not be taken as a rule + that only booleans would use lowercase; it's just the only example right + now. +- `Self` and `Super` +- Other Carbon types; for example, `Int`, `UnsignedInt`, and `String` -The dividing line between these is being decided on a case-by-case basis: `bool` -reasonable expectation may be that a type that is neither generic (as with -`Int`'s generic parameter for size) nor provides non-operator methods (as with a -`Substring()` method on `String`) is a basic type for naming purposes, while -other types are complex types for naming purposes. +Note that while other Carbon types currently use `UpperCamelCase`, that should +not be inferred to mean that future Carbon types will do the same. The leads +will make decisions on future naming. ## Rationale based on Carbon's goals - [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write) - - The primary purpose of naming conventions is to provide + - The intent is that limiting to `UpperCamelCase` and `lower_snake_case` + will offer developers a limited number of style rules to learn. + - There is a desire to maintain good ergonomics for developers. +- [Interoperability with and migration from existing C++ code](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code) + - There is a general desire to maintain naming consistency with C++, and + this can be seen with keywords such as `for` as well as booleans. ## Alternatives considered -TODO: What alternative solutions have you considered? +### Establish a rubrik for naming + +A couple naming formats consistent with `i32` were discussed: + +- Anything language-provided without needing an `import` is always + `lower_snake_case`. + - `i32`, `bool`, `true`, `self`, `super`, `string.is_empty()` +- As above, but prelude class members follow standard naming conventions. + - `i32`, `bool`, `true`, `self`, `super`, `string.IsEmpty()` +- Keywords and type literals use `lower_snake_case`, everything else uses + standard naming conventions. + - `i32`, `Self`, `Super`, `String.IsEmpty()` + - `bool`/`Bool` and `true`/`True` would be dependent upon later design + choices, but it's likely they'd be `bool`/`true` because of language + dependencies on boolean logic. + +Note the third choice is practically identical to the path being taken. However, +no rubrik should be interpreted as being established at present. The perspective +is that rationale for individual choices has been justified mostly after making +a decision on what the naming should be, and so no standard for future names is +really being selected. + +Individual naming decisions can be summarized as: + +- Idiomatic Carbon code uses the baseline of `UpperCamelCase` for identifiers + resolved at compile-time, and `lower_snake_case` for runtime. +- Properties use `lower_snake_case` as described in proposal + [#720: Property naming in C++](https://github.com/carbon-language/carbon-lang/pull/720). +- Keywords use `lower_snake_case` because it offers easy consistency with C++. + There's also good cross-language precedent for using `lower_snake_case`. +- Type literals use `lower_snake_case` as described in issue + [#543: pick names for fixed-size integer types](https://github.com/carbon-language/carbon-lang/issues/543). + - `i8` is more ergonomic than `Int8` for brevity. + - `i32` and `i64` maintain the same length as C++'s `int`. + - We don't want to use `I32` because `I32` can be hard to visually + distinguish with `132` or `l32`, even though it may help screen readers. +- Booleans use `bool`, `true`, and `false` mainly because there's a desire not + to skew from C++. + - While leads are okay with some things being shadowed, such as `Self` and + `Super`, there is a desire not to allow shadowing of booleans. +- `Self` and `Super` are `UpperCamelCase` because leads want them to look more + like normal types. + - They may be implemented as a hybrid approach, using something similar to + lookup in classes so they aren't quite keywords, but somewhat similar to + keywords because leads may want to reject them as identifiers in + non-class contexts. +- `String` and potentially other names follow idiomatic naming conventions. + - Note that, in this case, divergence from C++ is accepted. From 3bb78db42ee57f8a0619b1e4341566e41ffff65b Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 30 Sep 2021 19:42:58 +0000 Subject: [PATCH 05/16] Filling in lead thoughts --- proposals/p0861.md | 59 +++++++++++++++++++++++++++------------------- 1 file changed, 35 insertions(+), 24 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index f2df0e989ecc1..3f1a3fded18c7 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -23,7 +23,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Carbon-provided item naming](#carbon-provided-item-naming) - [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) - [Alternatives considered](#alternatives-considered) - - [Establish a rubrik for naming](#establish-a-rubrik-for-naming) + - [Other naming conventions](#other-naming-conventions) + - [Other conventions for naming Carbon types](#other-conventions-for-naming-carbon-types) @@ -85,9 +86,7 @@ to minimize the variation in rules. interchangeable with member variables. - Private class members will have a suffix `_`. - For Carbon-provided features: - - Keywords will use `lower_snake_case`, but should typically be a single - word. - - Basic Carbon types will be named similarly to keywords. + - Keywords and type literals will use `lower_snake_case`. - Other code will use the guidelines for idiomatic Carbon code. In other words: @@ -106,8 +105,8 @@ In other words: | Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | | Type literals | `lower_snake_case` | Equivalent to keywords. | | Booleans | `lower_snake_case` | Equivalent to keywords. | -| `Self` and `Super` | `UpperCamelCase` | These are similar to compile-time constant types on a class. | | Other Carbon types | `UpperCamelCase` | Behave like normal types. | +| `Self` and `Super` | `UpperCamelCase` | These are similar to type members on a class. | ## Details @@ -176,29 +175,22 @@ will make decisions on future naming. ## Alternatives considered -### Establish a rubrik for naming +### Other naming conventions -A couple naming formats consistent with `i32` were discussed: +A couple naming conventions that were discussed briefly are: -- Anything language-provided without needing an `import` is always - `lower_snake_case`. - - `i32`, `bool`, `true`, `self`, `super`, `string.is_empty()` -- As above, but prelude class members follow standard naming conventions. - - `i32`, `bool`, `true`, `self`, `super`, `string.IsEmpty()` -- Keywords and type literals use `lower_snake_case`, everything else uses - standard naming conventions. - - `i32`, `Self`, `Super`, `String.IsEmpty()` - - `bool`/`Bool` and `true`/`True` would be dependent upon later design - choices, but it's likely they'd be `bool`/`true` because of language - dependencies on boolean logic. +- `lowerCamelCase` names came up, but are hard to distinguish from + `lower_snake_case` for single-word identifiers. By contrast, + `UpperCamelCase` and `lower_snake_case` are distinct, whether a single word + or multiple. +- `ALL_CAPS_SNAKE_CASE` is used in C++ code, such as for macros and + compile-time constants. With Carbon, we hope the language is simple enough + that the readability benefit of an additional naming convention wouldn't + outweigh the cost of giving developers more naming conventions to learn. -Note the third choice is practically identical to the path being taken. However, -no rubrik should be interpreted as being established at present. The perspective -is that rationale for individual choices has been justified mostly after making -a decision on what the naming should be, and so no standard for future names is -really being selected. +### Other conventions for naming Carbon types -Individual naming decisions can be summarized as: +In detail, individual naming decisions are: - Idiomatic Carbon code uses the baseline of `UpperCamelCase` for identifiers resolved at compile-time, and `lower_snake_case` for runtime. @@ -224,3 +216,22 @@ Individual naming decisions can be summarized as: non-class contexts. - `String` and potentially other names follow idiomatic naming conventions. - Note that, in this case, divergence from C++ is accepted. + +Taking that into consideration, and that we are likely to keep +`lower_snake_case` for keywords and type literals in particular, a couple +options discussed would have mainly affect `self`, `super`, and `string`: + +- Anything language-provided without needing an `import` is always + `lower_snake_case`. + - `i32`, `bool`, `true`, `self`, `super`, `string.is_empty()` +- As above, but prelude class members follow standard naming conventions. + - `i32`, `bool`, `true`, `self`, `super`, `string.IsEmpty()` + +The understanding is that the difference between `bool` being treated similarly +to a keyword and `Self` being treated similarly to a type (both regardless of +implementation) is somewhat arbitrary. The decision not to use +`lower_snake_case` consistently depends mainly on the leaning of the leads, that +`self` and `super` felt like they shouldn't strictly be treated as keywords, and +`string` felt like the point where users should expect something more like an +idiomatic class. Future borderline cases may need to be decided by leads whether +they should be treated as more keyword-like or type-like. From 228472370a8546e3db3f54887c5c5ba21b093ee7 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Mon, 11 Oct 2021 23:01:57 +0000 Subject: [PATCH 06/16] Edits --- proposals/p0861.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index 3f1a3fded18c7..e6c5d55b245c2 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -96,7 +96,7 @@ In other words: | Packages | `UpperCamelCase` | Used for compile-time lookup. | | Types | `UpperCamelCase` | Resolved at compile-time. | | Functions | `UpperCamelCase` | Resolved at compile-time. | -| Methods | `UpperCamelCase` | Equivalent to functions. | +| Methods | `UpperCamelCase` | Methods, including virtual methods, are equivalent to functions. | | Generic parameters | `UpperCamelCase` | May vary based on inputs, but are ultimately resolved at compile-time. | | Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants] for more remarks. | | Variables | `lower_snake_case` | May be reassigned and thus require runtime information. | @@ -112,7 +112,8 @@ In other words: ### Constants -While `let` may be used to designate a constant, consider the following code: +Supposing `let` might be used to designate a constant, consider the following +code: ```carbon package Example; @@ -157,7 +158,7 @@ Carbon-provided items are split into a few categories: that only booleans would use lowercase; it's just the only example right now. - `Self` and `Super` -- Other Carbon types; for example, `Int`, `UnsignedInt`, and `String` +- Other Carbon types; for example, `Int`, `UInt`, and `String` Note that while other Carbon types currently use `UpperCamelCase`, that should not be inferred to mean that future Carbon types will do the same. The leads From fd0387b562ac8cf1e22d6e6853db4ef0a518b6ff Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Fri, 7 Jan 2022 23:07:21 +0000 Subject: [PATCH 07/16] Merge llvm-project --- third_party/llvm-project | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/third_party/llvm-project b/third_party/llvm-project index dbf0d8118ccbf..1ca35fc89e68f 160000 --- a/third_party/llvm-project +++ b/third_party/llvm-project @@ -1 +1 @@ -Subproject commit dbf0d8118ccbfd09def0974bf671c39e94d0be93 +Subproject commit 1ca35fc89e68fb2d0276856d8621bb5e68600919 From 49c10ce12398ddc0cfff28e99f1d33330d133498 Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Fri, 7 Jan 2022 15:25:49 -0800 Subject: [PATCH 08/16] Apply suggestions from code review Co-authored-by: Chandler Carruth --- proposals/p0861.md | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index e6c5d55b245c2..f57a5837721d3 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -104,7 +104,7 @@ In other words: | Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | | Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | | Type literals | `lower_snake_case` | Equivalent to keywords. | -| Booleans | `lower_snake_case` | Equivalent to keywords. | +| Boolean type and literals | `lower_snake_case` | Equivalent to keywords. | | Other Carbon types | `UpperCamelCase` | Behave like normal types. | | `Self` and `Super` | `UpperCamelCase` | These are similar to type members on a class. | @@ -120,13 +120,13 @@ package Example; let CompileTimeConstant: i32 = 7; -fn RuntimeFunction(let runtime_constant: i32); +fn RuntimeFunction(runtime_constant: i32); ``` In this example, `CompileTimeConstant` has a singular value (`7`) which is known at compile-time. As such, it uses `UpperCamelCase`. -On the other hand, `runtime_constant` may be constant due to `let`, but it is +On the other hand, `runtime_constant` may be constant within the function body, but it is assigned at runtime when `RuntimeFunction` is called. Its value is only known in a given runtime invocation of `RuntimeFunction`. As such, it uses `lower_snake_case`. @@ -153,7 +153,7 @@ Carbon-provided items are split into a few categories: - Keywords; for example, `for`, `fn`, and `var` - Type literals; for example, `i`, `u`, and `f` -- Booleans; for example, `bool`, `true`, and `false` +- Boolean type and literals; for example, `bool`, `true`, and `false` - The separate categorization of booleans should not be taken as a rule that only booleans would use lowercase; it's just the only example right now. @@ -191,14 +191,8 @@ A couple naming conventions that were discussed briefly are: ### Other conventions for naming Carbon types -In detail, individual naming decisions are: +In detail, individual naming decisions that had alternative patterns or options discussed were: -- Idiomatic Carbon code uses the baseline of `UpperCamelCase` for identifiers - resolved at compile-time, and `lower_snake_case` for runtime. -- Properties use `lower_snake_case` as described in proposal - [#720: Property naming in C++](https://github.com/carbon-language/carbon-lang/pull/720). -- Keywords use `lower_snake_case` because it offers easy consistency with C++. - There's also good cross-language precedent for using `lower_snake_case`. - Type literals use `lower_snake_case` as described in issue [#543: pick names for fixed-size integer types](https://github.com/carbon-language/carbon-lang/issues/543). - `i8` is more ergonomic than `Int8` for brevity. From 8361ea1627d29a6105e1750aa95214d31befabcd Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Fri, 7 Jan 2022 23:46:23 +0000 Subject: [PATCH 09/16] Addressing comments --- proposals/p0861.md | 61 ++++++++++++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 24 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index f57a5837721d3..332001ddbd3e5 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -21,6 +21,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Constants](#constants) - [Properties](#properties) - [Carbon-provided item naming](#carbon-provided-item-naming) +- [Open questions](#open-questions) + - [Should private members have a name augment?](#should-private-members-have-a-name-augment) - [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) - [Alternatives considered](#alternatives-considered) - [Other naming conventions](#other-naming-conventions) @@ -78,8 +80,9 @@ Only `UpperCamelCase` and `lower_snake_case` conventions will be used, in order to minimize the variation in rules. - For idiomatic Carbon code: - - `UpperCamelCase` will be used when the identifier can be resolved to a - specific value at compile-time. + - `UpperCamelCase` will be used when the identifier names a specific + program entity, such as a function, a namespace, or a compile-time + constant value. - `lower_snake_case` will be used when the identifier's value won't be known until runtime, such as for variables. - Properties will use this style because they are intended to be @@ -91,22 +94,22 @@ to minimize the variation in rules. In other words: -| Item | Convention | Explanation | -| ---------------------- | ------------------ | ------------------------------------------------------------------------------------------ | -| Packages | `UpperCamelCase` | Used for compile-time lookup. | -| Types | `UpperCamelCase` | Resolved at compile-time. | -| Functions | `UpperCamelCase` | Resolved at compile-time. | -| Methods | `UpperCamelCase` | Methods, including virtual methods, are equivalent to functions. | -| Generic parameters | `UpperCamelCase` | May vary based on inputs, but are ultimately resolved at compile-time. | -| Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants] for more remarks. | -| Variables | `lower_snake_case` | May be reassigned and thus require runtime information. | -| Member variables | `lower_snake_case` | Behave like variables. See [properties](#properties) for more remarks. | -| Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | -| Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | -| Type literals | `lower_snake_case` | Equivalent to keywords. | +| Item | Convention | Explanation | +| ------------------------- | ------------------ | ------------------------------------------------------------------------------------------ | +| Packages | `UpperCamelCase` | Used for compile-time lookup. | +| Types | `UpperCamelCase` | Resolved at compile-time. | +| Functions | `UpperCamelCase` | Resolved at compile-time. | +| Methods | `UpperCamelCase` | Methods, including virtual methods, are equivalent to functions. | +| Generic parameters | `UpperCamelCase` | May vary based on inputs, but are ultimately resolved at compile-time. | +| Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants] for more remarks. | +| Variables | `lower_snake_case` | May be reassigned and thus require runtime information. | +| Member variables | `lower_snake_case` | Behave like variables. See [properties](#properties) for more remarks. | +| Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | +| Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | +| Type literals | `lower_snake_case` | Equivalent to keywords. | | Boolean type and literals | `lower_snake_case` | Equivalent to keywords. | -| Other Carbon types | `UpperCamelCase` | Behave like normal types. | -| `Self` and `Super` | `UpperCamelCase` | These are similar to type members on a class. | +| Other Carbon types | `UpperCamelCase` | Behave like normal types. | +| `Self` and `Super` | `UpperCamelCase` | These are similar to type members on a class. | ## Details @@ -126,9 +129,9 @@ fn RuntimeFunction(runtime_constant: i32); In this example, `CompileTimeConstant` has a singular value (`7`) which is known at compile-time. As such, it uses `UpperCamelCase`. -On the other hand, `runtime_constant` may be constant within the function body, but it is -assigned at runtime when `RuntimeFunction` is called. Its value is only known in -a given runtime invocation of `RuntimeFunction`. As such, it uses +On the other hand, `runtime_constant` may be constant within the function body, +but it is assigned at runtime when `RuntimeFunction` is called. Its value is +only known in a given runtime invocation of `RuntimeFunction`. As such, it uses `lower_snake_case`. ### Properties @@ -144,9 +147,6 @@ helpful breakpoint for debug access. Regardless of the reason, we want it to be trivial for properties to replace member variables without affecting clients of an API, and so they use the same naming scheme. -Private member variables should use a `_` suffix in order to prevent name -collisions. We discourage private properties. - ### Carbon-provided item naming Carbon-provided items are split into a few categories: @@ -164,6 +164,18 @@ Note that while other Carbon types currently use `UpperCamelCase`, that should not be inferred to mean that future Carbon types will do the same. The leads will make decisions on future naming. +## Open questions + +### Should private members have a name augment? + +In +[#720: Property naming in C++](https://github.com/carbon-language/carbon-lang/pull/720), +we added a suffix `_` for private data members in C++. Should Carbon do similar, +for the same reasons of avoiding property and private data member name +collisions? + +This is currently unresolved because properties haven't been designed. + ## Rationale based on Carbon's goals - [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write) @@ -191,7 +203,8 @@ A couple naming conventions that were discussed briefly are: ### Other conventions for naming Carbon types -In detail, individual naming decisions that had alternative patterns or options discussed were: +In detail, individual naming decisions that had alternative patterns or options +discussed were: - Type literals use `lower_snake_case` as described in issue [#543: pick names for fixed-size integer types](https://github.com/carbon-language/carbon-lang/issues/543). From 4dd4e57d5aca73eb127c202bdfd71a9a15a323e3 Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Fri, 21 Jan 2022 10:50:28 -0800 Subject: [PATCH 10/16] Update proposals/p0861.md Co-authored-by: Chandler Carruth --- proposals/p0861.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index 332001ddbd3e5..d7b0f287521f3 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -101,7 +101,7 @@ In other words: | Functions | `UpperCamelCase` | Resolved at compile-time. | | Methods | `UpperCamelCase` | Methods, including virtual methods, are equivalent to functions. | | Generic parameters | `UpperCamelCase` | May vary based on inputs, but are ultimately resolved at compile-time. | -| Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants] for more remarks. | +| Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants) for more remarks. | | Variables | `lower_snake_case` | May be reassigned and thus require runtime information. | | Member variables | `lower_snake_case` | Behave like variables. See [properties](#properties) for more remarks. | | Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | From a09b9e419df0865922c63c43452e95d900bee6d6 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Fri, 21 Jan 2022 19:07:20 +0000 Subject: [PATCH 11/16] Addressing comments --- proposals/p0861.md | 38 +++++--------------------------------- 1 file changed, 5 insertions(+), 33 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index 332001ddbd3e5..630d7095c8ce9 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -19,7 +19,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Proposal](#proposal) - [Details](#details) - [Constants](#constants) - - [Properties](#properties) - [Carbon-provided item naming](#carbon-provided-item-naming) - [Open questions](#open-questions) - [Should private members have a name augment?](#should-private-members-have-a-name-augment) @@ -80,14 +79,11 @@ Only `UpperCamelCase` and `lower_snake_case` conventions will be used, in order to minimize the variation in rules. - For idiomatic Carbon code: - - `UpperCamelCase` will be used when the identifier names a specific - program entity, such as a function, a namespace, or a compile-time - constant value. - - `lower_snake_case` will be used when the identifier's value won't be + - `UpperCamelCase` will be used when the named entity cannot have a + dynamically varying value. For example, functions, namespaces, or + compile-time constant values. + - `lower_snake_case` will be used when the named entity's value won't be known until runtime, such as for variables. - - Properties will use this style because they are intended to be - interchangeable with member variables. - - Private class members will have a suffix `_`. - For Carbon-provided features: - Keywords and type literals will use `lower_snake_case`. - Other code will use the guidelines for idiomatic Carbon code. @@ -103,8 +99,7 @@ In other words: | Generic parameters | `UpperCamelCase` | May vary based on inputs, but are ultimately resolved at compile-time. | | Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants] for more remarks. | | Variables | `lower_snake_case` | May be reassigned and thus require runtime information. | -| Member variables | `lower_snake_case` | Behave like variables. See [properties](#properties) for more remarks. | -| Properties | `lower_snake_case` | Behave as wrappers for class members. See [properties](#properties) for more remarks. | +| Member variables | `lower_snake_case` | Behave like variables. | | Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | | Type literals | `lower_snake_case` | Equivalent to keywords. | | Boolean type and literals | `lower_snake_case` | Equivalent to keywords. | @@ -134,19 +129,6 @@ but it is assigned at runtime when `RuntimeFunction` is called. Its value is only known in a given runtime invocation of `RuntimeFunction`. As such, it uses `lower_snake_case`. -### Properties - -> NOTE: Property syntax hasn't been established for Carbon, but is expected, so -> this proposal aims to include it. - -The primary purpose of a -[property]() is to provide -a transparent wrapper to a private member variable. This may be done for reasons -such as guaranteeing lazy initialization of data on first access, or providing a -helpful breakpoint for debug access. Regardless of the reason, we want it to be -trivial for properties to replace member variables without affecting clients of -an API, and so they use the same naming scheme. - ### Carbon-provided item naming Carbon-provided items are split into a few categories: @@ -166,16 +148,6 @@ will make decisions on future naming. ## Open questions -### Should private members have a name augment? - -In -[#720: Property naming in C++](https://github.com/carbon-language/carbon-lang/pull/720), -we added a suffix `_` for private data members in C++. Should Carbon do similar, -for the same reasons of avoiding property and private data member name -collisions? - -This is currently unresolved because properties haven't been designed. - ## Rationale based on Carbon's goals - [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write) From 717283f1135604ae3f7b609035b26748a93061ab Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Fri, 21 Jan 2022 19:07:27 +0000 Subject: [PATCH 12/16] Addressing comments --- proposals/p0861.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index 630d7095c8ce9..35a8890cf46fd 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -21,7 +21,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Constants](#constants) - [Carbon-provided item naming](#carbon-provided-item-naming) - [Open questions](#open-questions) - - [Should private members have a name augment?](#should-private-members-have-a-name-augment) - [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) - [Alternatives considered](#alternatives-considered) - [Other naming conventions](#other-naming-conventions) @@ -99,7 +98,7 @@ In other words: | Generic parameters | `UpperCamelCase` | May vary based on inputs, but are ultimately resolved at compile-time. | | Compile-time constants | `UpperCamelCase` | Resolved at compile-time. See [constants](#constants] for more remarks. | | Variables | `lower_snake_case` | May be reassigned and thus require runtime information. | -| Member variables | `lower_snake_case` | Behave like variables. | +| Member variables | `lower_snake_case` | Behave like variables. | | Keywords | `lower_snake_case` | Special, and developers can be expected to be comfortable with this casing cross-language. | | Type literals | `lower_snake_case` | Equivalent to keywords. | | Boolean type and literals | `lower_snake_case` | Equivalent to keywords. | From 984874ea75b8634db9e003d5e7cad9da14b1bb4d Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 27 Jan 2022 11:19:52 -0800 Subject: [PATCH 13/16] Update proposals/p0861.md Co-authored-by: Richard Smith --- proposals/p0861.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index 149d3384c1d3c..750da4a2f5f69 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -103,7 +103,7 @@ In other words: | Type literals | `lower_snake_case` | Equivalent to keywords. | | Boolean type and literals | `lower_snake_case` | Equivalent to keywords. | | Other Carbon types | `UpperCamelCase` | Behave like normal types. | -| `Self` and `Super` | `UpperCamelCase` | These are similar to type members on a class. | +| `Self` and `Base` | `UpperCamelCase` | These are similar to type members on a class. | ## Details From 5fc57710623a233f21bf7bbc479911c343bf2233 Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 27 Jan 2022 11:20:02 -0800 Subject: [PATCH 14/16] Update proposals/p0861.md Co-authored-by: josh11b --- proposals/p0861.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index 750da4a2f5f69..ed60612e51178 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -138,7 +138,7 @@ Carbon-provided items are split into a few categories: - The separate categorization of booleans should not be taken as a rule that only booleans would use lowercase; it's just the only example right now. -- `Self` and `Super` +- `Self` and `Base` - Other Carbon types; for example, `Int`, `UInt`, and `String` Note that while other Carbon types currently use `UpperCamelCase`, that should From 5de6c33b9b1280fd7ecd72176495bdcb16a458fa Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 27 Jan 2022 11:20:09 -0800 Subject: [PATCH 15/16] Update proposals/p0861.md Co-authored-by: josh11b --- proposals/p0861.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index ed60612e51178..8061f6332626d 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -186,8 +186,8 @@ discussed were: - Booleans use `bool`, `true`, and `false` mainly because there's a desire not to skew from C++. - While leads are okay with some things being shadowed, such as `Self` and - `Super`, there is a desire not to allow shadowing of booleans. -- `Self` and `Super` are `UpperCamelCase` because leads want them to look more + `Base`, there is a desire not to allow shadowing of booleans. +- `Self` and `Base` are `UpperCamelCase` because leads want them to look more like normal types. - They may be implemented as a hybrid approach, using something similar to lookup in classes so they aren't quite keywords, but somewhat similar to From 8713b22f360f70275b7f4fa91379435011290998 Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 27 Jan 2022 11:20:17 -0800 Subject: [PATCH 16/16] Update proposals/p0861.md Co-authored-by: josh11b --- proposals/p0861.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/p0861.md b/proposals/p0861.md index 8061f6332626d..e961be07ae8bf 100644 --- a/proposals/p0861.md +++ b/proposals/p0861.md @@ -198,19 +198,19 @@ discussed were: Taking that into consideration, and that we are likely to keep `lower_snake_case` for keywords and type literals in particular, a couple -options discussed would have mainly affect `self`, `super`, and `string`: +options discussed would have mainly affect `self`, `base`, and `string`: - Anything language-provided without needing an `import` is always `lower_snake_case`. - - `i32`, `bool`, `true`, `self`, `super`, `string.is_empty()` + - `i32`, `bool`, `true`, `self`, `base`, `string.is_empty()` - As above, but prelude class members follow standard naming conventions. - - `i32`, `bool`, `true`, `self`, `super`, `string.IsEmpty()` + - `i32`, `bool`, `true`, `self`, `base`, `string.IsEmpty()` The understanding is that the difference between `bool` being treated similarly to a keyword and `Self` being treated similarly to a type (both regardless of implementation) is somewhat arbitrary. The decision not to use `lower_snake_case` consistently depends mainly on the leaning of the leads, that -`self` and `super` felt like they shouldn't strictly be treated as keywords, and +`self` and `base` felt like they shouldn't strictly be treated as keywords, and `string` felt like the point where users should expect something more like an idiomatic class. Future borderline cases may need to be decided by leads whether they should be treated as more keyword-like or type-like.