carbon-language/carbon-lang
1
0
Fork 0
mirror of https://github.com/carbon-language/carbon-lang.git synced 2026-09-24 11:40:14 +01:00
Code Issues Packages Projects Releases 10 Wiki Activity

Make proposal filenames use 6 digits and include the title (#7245)

Browse Source 
We've talked about adding the title to the filename several times over
the years and it seems really valuable. This requires us to compute a
"slug" for the title spelling that can be part of the filename.

Beyond that, we crossed 7000 recently, and so it seems likely that we
will need to add digits sooner rather than later here, so this goes
ahead and moves us to 6 digits so we don't have to adjust again for a
reasonable length of time.

To implement this and ensure we can sustain it going forward this adds a
tool to our pre-commit that validates (and corrects if needed) the
filename.

In order to update everything and keep links working, there are a _lot_
of changes, but the most interesting for direct review are in
`proposals/scripts`.

Assisted-by: Antigravity with Gemini

---------

Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This commit is contained in:
Chandler Carruth
2026-05-29 00:55:04 +00:00
committed by GitHub
co-authored by Richard Smith
parent 1cb0eecc1e
commit 94d2c1c6d4
250 changed files with 1139 additions and 685 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.pre-commit-config.yaml
+11
View File
@@ -112,6 +112,17 @@ repos:
entry: scripts/check_sha_filenames.py
language: python
files: ^.*/fuzzer_corpus/.*$
- id: check-proposal-names
name: Check proposal names
entry: proposals/scripts/check_proposal_names.py
language: python
files: ^proposals/p.*\.md$
# This edits files other than the ones passed to it, so we need each
# chunk of files to be run through the script serially.
require_serial: true
# This also renames files, invalidating the list of files provided to
# subsequent checks so we fail-fast if this makes changes.
fail_fast: true
- id: check-toolchain-diagnostics
name: Check toolchain diagnostics
entry: toolchain/diagnostics/check_diagnostics.py
docs/design/README.md
+3 -3
View File
@@ -486,7 +486,7 @@ intended for bit manipulation or modular arithmetic as often found in
[PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) use cases.
Values which can never be negative, like sizes, but for which wrapping does not
make sense
[should use signed integer types](/proposals/p1083.md#dont-let-unsigned-arithmetic-wrap).
[should use signed integer types](/proposals/p001083-arithmetic-expressions.md#dont-let-unsigned-arithmetic-wrap).
Identifiers of the form `iN` and `uN` are _type literals_, resulting in the
corresponding type.
@@ -864,7 +864,7 @@ or restrictions on casts between pointers and integers.
### Arrays and slices
> **TODO:** The provisional array syntax documented here has been superseded by
> [p4682: The Core.Array type for direct-storage immutably-sized buffers](/proposals/p4682.md).
> [#4682: The Core.Array type for direct-storage immutably-sized buffers](/proposals/p004682-the-core-array-type-for-direct-storage-immutably-sized-buffers.md).
The type of an array of holding 4 `i32` values is written `[i32; 4]`. There is
an [implicit conversion](expressions/implicit_conversions.md) from tuples to
@@ -3521,7 +3521,7 @@ ABI compatibility.
> References:
>
> - [Goals: Stable language and library ABI non-goal](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#stable-language-and-library-abi)
> - [#175: C++ interoperability goals: Support mixing Carbon and C++ toolchains](/proposals/p0175.md#support-mixing-carbon-and-c-toolchains)
> - [#175: C++ interoperability goals: Support mixing Carbon and C++ toolchains](/proposals/p000175-c-interoperability-goals.md#support-mixing-carbon-and-c-toolchains)
### Operator overloading
docs/design/assignment.md
+8 -8
View File
@@ -331,14 +331,14 @@ impl MyString as AddAssignWith(like MyString) {
## Alternatives considered
- [Allow assignment as a subexpression](/proposals/p2511.md#allow-assignment-as-a-subexpression)
- [Allow chained assignment](/proposals/p2511.md#allow-chained-assignment)
- [Do not provide increment and decrement](/proposals/p2511.md#do-not-provide-increment-and-decrement)
- [Treat increment as syntactic sugar for adding `1`](/proposals/p2511.md#treat-increment-as-syntactic-sugar-for-adding-1)
- [Define `$` in terms of `$=`](/proposals/p2511.md#define--in-terms-of-)
- [Do not allow overloading the behavior of `=`](/proposals/p2511.md#do-not-allow-overloading-the-behavior-of-)
- [Treat the left hand side of `=` as a pattern](/proposals/p2511.md#treat-the-left-hand-side-of--as-a-pattern)
- [Different names for interfaces](/proposals/p2511.md#different-names-for-interfaces)
- [Allow assignment as a subexpression](/proposals/p002511-assignment-statements.md#allow-assignment-as-a-subexpression)
- [Allow chained assignment](/proposals/p002511-assignment-statements.md#allow-chained-assignment)
- [Do not provide increment and decrement](/proposals/p002511-assignment-statements.md#do-not-provide-increment-and-decrement)
- [Treat increment as syntactic sugar for adding `1`](/proposals/p002511-assignment-statements.md#treat-increment-as-syntactic-sugar-for-adding-1)
- [Define `$` in terms of `$=`](/proposals/p002511-assignment-statements.md#define--in-terms-of-)
- [Do not allow overloading the behavior of `=`](/proposals/p002511-assignment-statements.md#do-not-allow-overloading-the-behavior-of-)
- [Treat the left hand side of `=` as a pattern](/proposals/p002511-assignment-statements.md#treat-the-left-hand-side-of--as-a-pattern)
- [Different names for interfaces](/proposals/p002511-assignment-statements.md#different-names-for-interfaces)
## References
docs/design/classes.md
+77 -77
View File
@@ -646,7 +646,7 @@ class types when:
same field names.
For example, since
[comparison between `i32` and `u32` is defined](/proposals/p0702.md#built-in-comparisons-and-implicit-conversions),
[comparison between `i32` and `u32` is defined](/proposals/p000702-comparison-operators.md#built-in-comparisons-and-implicit-conversions),
equality comparison between values of types `{.x: i32, .y: i32}` and
`{.y: u32, .x: u32}` is as well. Equality and inequality comparisons compare
fields using the field order of the left-hand operand and stop once the outcome
@@ -804,7 +804,7 @@ type has not yet been decided.
> **TODO:** Document that qualified names can be looked up in an incomplete
> type, as adopted in
> [p5087: Qualified lookup into types being defined](/proposals/p5087.md).
> [#5087: Qualified lookup into types being defined](/proposals/p005087-qualified-lookup-into-types-being-defined.md).
### `Self`
@@ -1144,7 +1144,7 @@ interface would then be part of our
[strategy for defining how other interfaces are implemented for data classes](#interfaces-implemented-for-data-classes).
**References:** Rationale for this approach is given in proposal
[#722](/proposals/p0722.md#nominal-data-class).
[#722](/proposals/p000722-nominal-classes-and-methods.md#nominal-data-class).
### Member type
@@ -1422,9 +1422,9 @@ constructor functions should return the constructed value without copying, as in
proposal
[#257: Initialization of memory and variables](https://github.com/carbon-language/carbon-lang/pull/257).
This means either
[creating the object in the return statement itself](/proposals/p0257.md#function-returns-and-initialization),
[creating the object in the return statement itself](/proposals/p000257-initialization-of-memory-and-variables.md#function-returns-and-initialization),
or in
[a `returned var` declaration](/proposals/p0257.md#declared-returned-variable).
[a `returned var` declaration](/proposals/p000257-initialization-of-memory-and-variables.md#declared-returned-variable).
As before, instances can be created by casting a struct value into the class
type, this time with a `.base` member to initialize the members of the immediate
base type.
@@ -1710,8 +1710,8 @@ the destructor is virtual or non-virtual, determines which
actually pointing to a derived class.
**Note:** The names `Deletable` and `Destructible` are
[**placeholders**](/proposals/p1154.md#type-of-type-naming) since they do not
conform to the decision on
[**placeholders**](/proposals/p001154-destructors.md#type-of-type-naming) since
they do not conform to the decision on
[question-for-leads issue #1058: "How should interfaces for core functionality be named?"](https://github.com/carbon-language/carbon-lang/issues/1058).
| Class | Destructor | `Concrete` | `Deletable` | `Destructible` |
@@ -1793,14 +1793,14 @@ Unhandled failure during a destructor call will abort the program.
**Alternatives considered:**
- [Types implement destructor interface](/proposals/p1154.md#types-implement-destructor-interface)
- [Prevent virtual function calls in destructors](/proposals/p1154.md#prevent-virtual-function-calls-in-destructors)
- [Allow functions to act as destructors](/proposals/p1154.md#allow-functions-to-act-as-destructors)
- [Allow private destructors](/proposals/p1154.md#allow-private-destructors)
- [Allow multiple conditional destructors](/proposals/p1154.md#allow-multiple-conditional-destructors)
- [Don't distinguish safe and unsafe delete operations](/proposals/p1154.md#dont-distinguish-safe-and-unsafe-delete-operations)
- [Don't allow unsafe delete](/proposals/p1154.md#dont-allow-unsafe-delete)
- [Allow final destructors](/proposals/p1154.md#allow-final-destructors)
- [Types implement destructor interface](/proposals/p001154-destructors.md#types-implement-destructor-interface)
- [Prevent virtual function calls in destructors](/proposals/p001154-destructors.md#prevent-virtual-function-calls-in-destructors)
- [Allow functions to act as destructors](/proposals/p001154-destructors.md#allow-functions-to-act-as-destructors)
- [Allow private destructors](/proposals/p001154-destructors.md#allow-private-destructors)
- [Allow multiple conditional destructors](/proposals/p001154-destructors.md#allow-multiple-conditional-destructors)
- [Don't distinguish safe and unsafe delete operations](/proposals/p001154-destructors.md#dont-distinguish-safe-and-unsafe-delete-operations)
- [Don't allow unsafe delete](/proposals/p001154-destructors.md#dont-allow-unsafe-delete)
- [Allow final destructors](/proposals/p001154-destructors.md#allow-final-destructors)
### Access control
@@ -1842,7 +1842,7 @@ and [D](https://wiki.dlang.org/Access_specifiers_and_visibility).
**References:** Proposal
[#561: Basic classes](https://github.com/carbon-language/carbon-lang/pull/561)
included the decision that
[members default to publicly accessible](/proposals/p0561.md#access-control)
[members default to publicly accessible](/proposals/p000561-basic-classes-use-cases-struct-literals-struct-types-and-future-work.md#access-control)
originally asked in issue
[#665](https://github.com/carbon-language/carbon-lang/issues/665).
@@ -1869,7 +1869,7 @@ C++ and is more orthogonal.
**Future work:** `private` will give the member internal linkage unless it needs
to be external because it is used in an inline method or template. We may in the
future
[add a way to specify internal linkage explicitly](/proposals/p0722.md#specifying-linkage-as-part-of-the-access-modifier).
[add a way to specify internal linkage explicitly](/proposals/p000722-nominal-classes-and-methods.md#specifying-linkage-as-part-of-the-access-modifier).
**Open questions:** Using `private` to mean "restricted to this class" matches
C++. Other languages support restricting to different scopes:
@@ -2278,104 +2278,104 @@ the type of `U.x`."
- [#257: Initialization of memory and variables](https://github.com/carbon-language/carbon-lang/pull/257)
- [Require compile-time-proven initialization](/proposals/p0257.md#require-compile-time-proven-initialization)
- [C and C++ uninitialized](/proposals/p0257.md#c-and-c-uninitialized)
- [Allow passing unformed objects to parameters or returning them?](/proposals/p0257.md#allow-passing-unformed-objects-to-parameters-or-returning-them)
- [Allow assigning an unformed object to another unformed object?](/proposals/p0257.md#allow-assigning-an-unformed-object-to-another-unformed-object)
- [Fully destructive move (Rust)](/proposals/p0257.md#fully-destructive-move-rust)
- [Completely non-destructive move (C++)](/proposals/p0257.md#completely-non-destructive-move-c)
- [Named return variable in place of a return type](/proposals/p0257.md#named-return-variable-in-place-of-a-return-type)
- [Allow unformed members](/proposals/p0257.md#allow-unformed-members)
- [Require compile-time-proven initialization](/proposals/p000257-initialization-of-memory-and-variables.md#require-compile-time-proven-initialization)
- [C and C++ uninitialized](/proposals/p000257-initialization-of-memory-and-variables.md#c-and-c-uninitialized)
- [Allow passing unformed objects to parameters or returning them?](/proposals/p000257-initialization-of-memory-and-variables.md#allow-passing-unformed-objects-to-parameters-or-returning-them)
- [Allow assigning an unformed object to another unformed object?](/proposals/p000257-initialization-of-memory-and-variables.md#allow-assigning-an-unformed-object-to-another-unformed-object)
- [Fully destructive move (Rust)](/proposals/p000257-initialization-of-memory-and-variables.md#fully-destructive-move-rust)
- [Completely non-destructive move (C++)](/proposals/p000257-initialization-of-memory-and-variables.md#completely-non-destructive-move-c)
- [Named return variable in place of a return type](/proposals/p000257-initialization-of-memory-and-variables.md#named-return-variable-in-place-of-a-return-type)
- [Allow unformed members](/proposals/p000257-initialization-of-memory-and-variables.md#allow-unformed-members)
- [#561: Basic classes: use cases, struct literals, struct types, and future work](https://github.com/carbon-language/carbon-lang/pull/561)
- [Early proposal #98](https://github.com/carbon-language/carbon-lang/pull/98)
- [Interfaces implemented for anonymous data classes](/proposals/p0561.md#interfaces-implemented-for-anonymous-data-classes)
- [Access control](/proposals/p0561.md#access-control)
- [Introducer for structural data class types](/proposals/p0561.md#introducer-for-structural-data-class-types)
- [Terminology](/proposals/p0561.md#terminology)
- [Interfaces implemented for anonymous data classes](/proposals/p000561-basic-classes-use-cases-struct-literals-struct-types-and-future-work.md#interfaces-implemented-for-anonymous-data-classes)
- [Access control](/proposals/p000561-basic-classes-use-cases-struct-literals-struct-types-and-future-work.md#access-control)
- [Introducer for structural data class types](/proposals/p000561-basic-classes-use-cases-struct-literals-struct-types-and-future-work.md#introducer-for-structural-data-class-types)
- [Terminology](/proposals/p000561-basic-classes-use-cases-struct-literals-struct-types-and-future-work.md#terminology)
- [#722: Nominal classes and methods](https://github.com/carbon-language/carbon-lang/pull/722)
- [Method syntax](/proposals/p0722.md#method-syntax)
- [Marking mutating methods at the call site](/proposals/p0722.md#marking-mutating-methods-at-the-call-site)
- [Differences between functions and methods](/proposals/p0722.md#differences-between-functions-and-methods)
- [Specifying linkage as part of the access modifier](/proposals/p0722.md#specifying-linkage-as-part-of-the-access-modifier)
- [Nominal data class](/proposals/p0722.md#nominal-data-class)
- [Let constants](/proposals/p0722.md#let-constants)
- [Method syntax](/proposals/p000722-nominal-classes-and-methods.md#method-syntax)
- [Marking mutating methods at the call site](/proposals/p000722-nominal-classes-and-methods.md#marking-mutating-methods-at-the-call-site)
- [Differences between functions and methods](/proposals/p000722-nominal-classes-and-methods.md#differences-between-functions-and-methods)
- [Specifying linkage as part of the access modifier](/proposals/p000722-nominal-classes-and-methods.md#specifying-linkage-as-part-of-the-access-modifier)
- [Nominal data class](/proposals/p000722-nominal-classes-and-methods.md#nominal-data-class)
- [Let constants](/proposals/p000722-nominal-classes-and-methods.md#let-constants)
- [#777: Inheritance](https://github.com/carbon-language/carbon-lang/pull/777)
- [Classes are final by default](/proposals/p0777.md#classes-are-final-by-default)
- [Allow keywords to be written when they would have no effect](/proposals/p0777.md#allow-keywords-to-be-written-when-they-would-have-no-effect)
- [Different virtual override keywords](/proposals/p0777.md#different-virtual-override-keywords)
- [Different virtual override keyword placement](/proposals/p0777.md#different-virtual-override-keyword-placement)
- [Final methods](/proposals/p0777.md#final-methods)
- [Constructors](/proposals/p0777.md#constructors)
- [Implicit abstract classes](/proposals/p0777.md#implicit-abstract-classes)
- [No extensible objects with non-virtual destructors](/proposals/p0777.md#no-extensible-objects-with-non-virtual-destructors)
- [Separate "exact" and "or derived" variations on types](/proposals/p0777.md#separate-exact-and-or-derived-variations-on-types)
- [Separate "exact" and "or derived" variations on pointers](/proposals/p0777.md#separate-exact-and-or-derived-variations-on-pointers)
- [Classes are final by default](/proposals/p000777-inheritance.md#classes-are-final-by-default)
- [Allow keywords to be written when they would have no effect](/proposals/p000777-inheritance.md#allow-keywords-to-be-written-when-they-would-have-no-effect)
- [Different virtual override keywords](/proposals/p000777-inheritance.md#different-virtual-override-keywords)
- [Different virtual override keyword placement](/proposals/p000777-inheritance.md#different-virtual-override-keyword-placement)
- [Final methods](/proposals/p000777-inheritance.md#final-methods)
- [Constructors](/proposals/p000777-inheritance.md#constructors)
- [Implicit abstract classes](/proposals/p000777-inheritance.md#implicit-abstract-classes)
- [No extensible objects with non-virtual destructors](/proposals/p000777-inheritance.md#no-extensible-objects-with-non-virtual-destructors)
- [Separate "exact" and "or derived" variations on types](/proposals/p000777-inheritance.md#separate-exact-and-or-derived-variations-on-types)
- [Separate "exact" and "or derived" variations on pointers](/proposals/p000777-inheritance.md#separate-exact-and-or-derived-variations-on-pointers)
- [#875: Principle: Information accumulation](https://github.com/carbon-language/carbon-lang/pull/875)
- Allow information to be used before it is provided
[globally](/proposals/p0875.md#strict-global-consistency),
[within a file](/proposals/p0875.md#context-sensitive-local-consistency),
[globally](/proposals/p000875-principle-information-accumulation.md#strict-global-consistency),
[within a file](/proposals/p000875-principle-information-accumulation.md#context-sensitive-local-consistency),
or
[within a top-level declaration](/proposals/p0875.md#top-down-with-minimally-deferred-type-checking).
- [Do not allow inline method bodies to use members before they are declared](/proposals/p0875.md#strict-top-down)
- [Do not allow separate declaration and definition](/proposals/p0875.md#disallow-separate-declaration-and-definition)
[within a top-level declaration](/proposals/p000875-principle-information-accumulation.md#top-down-with-minimally-deferred-type-checking).
- [Do not allow inline method bodies to use members before they are declared](/proposals/p000875-principle-information-accumulation.md#strict-top-down)
- [Do not allow separate declaration and definition](/proposals/p000875-principle-information-accumulation.md#disallow-separate-declaration-and-definition)
- [#981: Implicit conversions for aggregates](https://github.com/carbon-language/carbon-lang/pull/981)
- [Field order is not significant](/proposals/p0981.md#field-order-is-not-significant)
- [Different field orders are incompatible](/proposals/p0981.md#different-field-orders-are-incompatible)
- [Explicit instead of implicit conversions](/proposals/p0981.md#explicit-instead-of-implicit-conversions)
- [Field order is not significant](/proposals/p000981-implicit-conversions-for-aggregates.md#field-order-is-not-significant)
- [Different field orders are incompatible](/proposals/p000981-implicit-conversions-for-aggregates.md#different-field-orders-are-incompatible)
- [Explicit instead of implicit conversions](/proposals/p000981-implicit-conversions-for-aggregates.md#explicit-instead-of-implicit-conversions)
- [#1154: Destructors](https://github.com/carbon-language/carbon-lang/pull/1154)
- [Types implement destructor interface](/proposals/p1154.md#types-implement-destructor-interface)
- [Prevent virtual function calls in destructors](/proposals/p1154.md#prevent-virtual-function-calls-in-destructors)
- [Allow functions to act as destructors](/proposals/p1154.md#allow-functions-to-act-as-destructors)
- [Allow private destructors](/proposals/p1154.md#allow-private-destructors)
- [Allow multiple conditional destructors](/proposals/p1154.md#allow-multiple-conditional-destructors)
- [Facet type naming](/proposals/p1154.md#type-of-type-naming)
- [Other approaches to extensible classes without vtables](/proposals/p1154.md#other-approaches-to-extensible-classes-without-vtables)
- [Types implement destructor interface](/proposals/p001154-destructors.md#types-implement-destructor-interface)
- [Prevent virtual function calls in destructors](/proposals/p001154-destructors.md#prevent-virtual-function-calls-in-destructors)
- [Allow functions to act as destructors](/proposals/p001154-destructors.md#allow-functions-to-act-as-destructors)
- [Allow private destructors](/proposals/p001154-destructors.md#allow-private-destructors)
- [Allow multiple conditional destructors](/proposals/p001154-destructors.md#allow-multiple-conditional-destructors)
- [Facet type naming](/proposals/p001154-destructors.md#type-of-type-naming)
- [Other approaches to extensible classes without vtables](/proposals/p001154-destructors.md#other-approaches-to-extensible-classes-without-vtables)
- [#2107: Clarify rules around `Self` and `.Self`](https://github.com/carbon-language/carbon-lang/pull/2107)
- [`Self` not a keyword](/proposals/p2107.md#self-not-a-keyword)
- [Make `Self` a member of all types](/proposals/p2107.md#make-self-a-member-of-all-types)
- [`where` operator could be associative](/proposals/p2107.md#where-operator-could-be-associative)
- [`Self` not a keyword](/proposals/p002107-clarify-rules-around-self-and-self.md#self-not-a-keyword)
- [Make `Self` a member of all types](/proposals/p002107-clarify-rules-around-self-and-self.md#make-self-a-member-of-all-types)
- [`where` operator could be associative](/proposals/p002107-clarify-rules-around-self-and-self.md#where-operator-could-be-associative)
- [#2287: Allow unqualified name lookup for class members](https://github.com/carbon-language/carbon-lang/pull/2287)
- [No unqualified lookup when defining outside a scope](/proposals/p2287.md#no-unqualified-lookup-when-defining-outside-a-scope)
- [No unqualified lookup when defining outside a scope](/proposals/p002287-allow-unqualified-name-lookup.md#no-unqualified-lookup-when-defining-outside-a-scope)
- [#2760: Consistent `class` and `interface` syntax](https://github.com/carbon-language/carbon-lang/pull/2760)
- [Use `extends` instead of `extend`](/proposals/p2760.md#use-extends-instead-of-extend)
- [List base class in class declaration](/proposals/p2760.md#list-base-class-in-class-declaration)
- [Use `extends` instead of `extend`](/proposals/p002760-consistent-class-and-interface-syntax.md#use-extends-instead-of-extend)
- [List base class in class declaration](/proposals/p002760-consistent-class-and-interface-syntax.md#list-base-class-in-class-declaration)
- [#5017: Destructor syntax](https://github.com/carbon-language/carbon-lang/pull/5017)
- [Destructor syntax options](/proposals/p5017.md#destructor-syntax-options)
- [Destructor name options](/proposals/p5017.md#destructor-name-options)
- [Destructor syntax options](/proposals/p005017-destructor-syntax.md#destructor-syntax-options)
- [Destructor name options](/proposals/p005017-destructor-syntax.md#destructor-name-options)
- [#6008: Replace `impl fn` with `override fn`](https://github.com/carbon-language/carbon-lang/pull/6008)
- [#7016: Updating `self` syntax and adding `static` fields](https://github.com/carbon-language/carbon-lang/pull/7016)
- [Don't put `self` in either parameter list](/proposals/p7016.md#dont-put-self-in-either-parameter-list)
- [`self` syntax in the deduced parameter list `[]`](/proposals/p7016.md#self-syntax-in-the-deduced-parameter-list-)
- [`class` modifier for non-instance member variables and functions](/proposals/p7016.md#class-modifier-for-non-instance-member-variables-and-functions)
- [Alternative keywords for non-instance member variables](/proposals/p7016.md#alternative-keywords-for-non-instance-member-variables)
- [`shared`](/proposals/p7016.md#shared)
- [`global`](/proposals/p7016.md#global)
- [`static` for non-instance member functions](/proposals/p7016.md#static-for-non-instance-member-functions)
- [`static` for package- and namespace-scope variables](/proposals/p7016.md#static-for-package--and-namespace-scope-variables)
- [Distinct `method` introducer](/proposals/p7016.md#distinct-method-introducer)
- [Don't put `self` in either parameter list](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#dont-put-self-in-either-parameter-list)
- [`self` syntax in the deduced parameter list `[]`](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#self-syntax-in-the-deduced-parameter-list-)
- [`class` modifier for non-instance member variables and functions](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#class-modifier-for-non-instance-member-variables-and-functions)
- [Alternative keywords for non-instance member variables](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#alternative-keywords-for-non-instance-member-variables)
- [`shared`](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#shared)
- [`global`](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#global)
- [`static` for non-instance member functions](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#static-for-non-instance-member-functions)
- [`static` for package- and namespace-scope variables](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#static-for-package--and-namespace-scope-variables)
- [Distinct `method` introducer](/proposals/p007016-updating-self-syntax-and-adding-static-member-variables.md#distinct-method-introducer)
## References
docs/design/code_and_name_organization/README.md
+49 -49
View File
@@ -648,7 +648,7 @@ When `export` is used as a modifier to `import`, it is still considered to be an
Namespaces cannot be exported using a `export <name>` declaration. It is
possible a form of support will be added as
[future work](/proposals/p3938.md#namespaces).
[future work](/proposals/p003938-exporting-imported-names.md#namespaces).
Names in other packages also cannot be exported. This covers both possible
syntaxes: `export import <package>` and `export <package>.<name>`. However, a
@@ -1016,58 +1016,58 @@ files. This should be part of a larger testing plan.
## Alternatives considered
- Packages
- [Name paths for package names](/proposals/p0107.md#name-paths-for-package-names)
- [Referring to the package as `package`](/proposals/p0107.md#referring-to-the-package-as-package)
- [Remove the `library` keyword from `package` and `import`](/proposals/p0107.md#remove-the-library-keyword-from-package-and-import)
- [Rename package concept](/proposals/p0107.md#rename-package-concept)
- [No association between the file system path and library/namespace](/proposals/p0107.md#no-association-between-the-file-system-path-and-librarynamespace)
- [Require the use of the identifier `Main` in package declarations](/proposals/p2550.md#require-the-use-of-the-identifier-main-in-package-declarations)
- [Permit the use of the identifier `Main` in package declarations](/proposals/p2550.md#permit-the-use-of-the-identifier-main-in-package-declarations)
- [Make the main package be unnamed](/proposals/p2550.md#make-the-main-package-be-unnamed)
- [Use a different name for the main package](/proposals/p2550.md#use-a-different-name-for-the-main-package)
- [Use a different name for the entry point](/proposals/p2550.md#use-a-different-name-for-the-entry-point)
- [Distinguish file scope from package scope](/proposals/p2550.md#distinguish-file-scope-from-package-scope)
- [Default to an implementation file for `Main//default` instead of an API file](/proposals/p3403.md#default-to-maindefault-impl-instead-of-maindefault-api)
- [Name paths for package names](/proposals/p000107-code-and-name-organization.md#name-paths-for-package-names)
- [Referring to the package as `package`](/proposals/p000107-code-and-name-organization.md#referring-to-the-package-as-package)
- [Remove the `library` keyword from `package` and `import`](/proposals/p000107-code-and-name-organization.md#remove-the-library-keyword-from-package-and-import)
- [Rename package concept](/proposals/p000107-code-and-name-organization.md#rename-package-concept)
- [No association between the file system path and library/namespace](/proposals/p000107-code-and-name-organization.md#no-association-between-the-file-system-path-and-librarynamespace)
- [Require the use of the identifier `Main` in package declarations](/proposals/p002550-simplified-package-declaration-for-the-main-package.md#require-the-use-of-the-identifier-main-in-package-declarations)
- [Permit the use of the identifier `Main` in package declarations](/proposals/p002550-simplified-package-declaration-for-the-main-package.md#permit-the-use-of-the-identifier-main-in-package-declarations)
- [Make the main package be unnamed](/proposals/p002550-simplified-package-declaration-for-the-main-package.md#make-the-main-package-be-unnamed)
- [Use a different name for the main package](/proposals/p002550-simplified-package-declaration-for-the-main-package.md#use-a-different-name-for-the-main-package)
- [Use a different name for the entry point](/proposals/p002550-simplified-package-declaration-for-the-main-package.md#use-a-different-name-for-the-entry-point)
- [Distinguish file scope from package scope](/proposals/p002550-simplified-package-declaration-for-the-main-package.md#distinguish-file-scope-from-package-scope)
- [Default to an implementation file for `Main//default` instead of an API file](/proposals/p003403-change-main-default-to-an-api-file.md#default-to-maindefault-impl-instead-of-maindefault-api)
- Libraries
- [Allow exporting namespaces](/proposals/p0107.md#allow-exporting-namespaces)
- [Allow importing implementation files from within the same library](/proposals/p0107.md#allow-importing-implementation-files-from-within-the-same-library)
- [Alternative library separators and shorthand](/proposals/p0107.md#alternative-library-separators-and-shorthand)
- [Single-word libraries](/proposals/p0107.md#single-word-libraries)
- [Collapse API and implementation file concepts](/proposals/p0107.md#collapse-api-and-implementation-file-concepts)
- [Automatically generating the API separation](/proposals/p0107.md#automatically-generating-the-api-separation)
- [Collapse file and library concepts](/proposals/p0107.md#collapse-file-and-library-concepts)
- [Collapse the library concept into packages](/proposals/p0107.md#collapse-the-library-concept-into-packages)
- [Collapse the package concept into libraries](/proposals/p0107.md#collapse-the-package-concept-into-libraries)
- [Default API to private](/proposals/p0752.md#default-api-to-private)
- [Default `impl` to public](/proposals/p0752.md#default-impl-to-public)
- [Different file type labels](/proposals/p0107.md#different-file-type-labels)
- [Don't default to introducing an API file](/proposals/p3927.md#mandatory-api-or-impl-as-suffix)
- [Function-like syntax](/proposals/p0107.md#function-like-syntax)
- [Inlining from implementation files](/proposals/p0107.md#inlining-from-implementation-files)
- [Library-private access controls](/proposals/p0107.md#library-private-access-controls)
- [Make keywords either optional or required in separate definitions](/proposals/p0752.md#make-keywords-either-optional-or-required-in-separate-definitions)
- [Managing API versus implementation in libraries](/proposals/p0107.md#managing-api-versus-implementation-in-libraries)
- [Multiple API files](/proposals/p0107.md#multiple-api-files)
- [Name paths as library names](/proposals/p0107.md#name-paths-as-library-names)
- [Put the `impl` modifier at the end](/proposals/p3927.md#mandatory-api-or-impl-as-suffix)
- [Put the `impl` modifier before `library`](/proposals/p3927.md#put-the-impl-modifier-before-library)
- [Allow exporting namespaces](/proposals/p000107-code-and-name-organization.md#allow-exporting-namespaces)
- [Allow importing implementation files from within the same library](/proposals/p000107-code-and-name-organization.md#allow-importing-implementation-files-from-within-the-same-library)
- [Alternative library separators and shorthand](/proposals/p000107-code-and-name-organization.md#alternative-library-separators-and-shorthand)
- [Single-word libraries](/proposals/p000107-code-and-name-organization.md#single-word-libraries)
- [Collapse API and implementation file concepts](/proposals/p000107-code-and-name-organization.md#collapse-api-and-implementation-file-concepts)
- [Automatically generating the API separation](/proposals/p000107-code-and-name-organization.md#automatically-generating-the-api-separation)
- [Collapse file and library concepts](/proposals/p000107-code-and-name-organization.md#collapse-file-and-library-concepts)
- [Collapse the library concept into packages](/proposals/p000107-code-and-name-organization.md#collapse-the-library-concept-into-packages)
- [Collapse the package concept into libraries](/proposals/p000107-code-and-name-organization.md#collapse-the-package-concept-into-libraries)
- [Default API to private](/proposals/p000752-api-file-default-public.md#default-api-to-private)
- [Default `impl` to public](/proposals/p000752-api-file-default-public.md#default-impl-to-public)
- [Different file type labels](/proposals/p000107-code-and-name-organization.md#different-file-type-labels)
- [Don't default to introducing an API file](/proposals/p003927-more-consistent-package-syntax.md#mandatory-api-or-impl-as-suffix)
- [Function-like syntax](/proposals/p000107-code-and-name-organization.md#function-like-syntax)
- [Inlining from implementation files](/proposals/p000107-code-and-name-organization.md#inlining-from-implementation-files)
- [Library-private access controls](/proposals/p000107-code-and-name-organization.md#library-private-access-controls)
- [Make keywords either optional or required in separate definitions](/proposals/p000752-api-file-default-public.md#make-keywords-either-optional-or-required-in-separate-definitions)
- [Managing API versus implementation in libraries](/proposals/p000107-code-and-name-organization.md#managing-api-versus-implementation-in-libraries)
- [Multiple API files](/proposals/p000107-code-and-name-organization.md#multiple-api-files)
- [Name paths as library names](/proposals/p000107-code-and-name-organization.md#name-paths-as-library-names)
- [Put the `impl` modifier at the end](/proposals/p003927-more-consistent-package-syntax.md#mandatory-api-or-impl-as-suffix)
- [Put the `impl` modifier before `library`](/proposals/p003927-more-consistent-package-syntax.md#put-the-impl-modifier-before-library)
- Imports
- [Block imports](/proposals/p0107.md#block-imports)
- [Block imports of libraries of a single package](/proposals/p0107.md#block-imports-of-libraries-of-a-single-package)
- [Broader imports, either all names or arbitrary code](/proposals/p0107.md#broader-imports-either-all-names-or-arbitrary-code)
- [Direct name imports](/proposals/p0107.md#direct-name-imports)
- [Always include the package name in imports](/proposals/p2550.md#keep-the-package-name-in-imports)
- [Block imports](/proposals/p000107-code-and-name-organization.md#block-imports)
- [Block imports of libraries of a single package](/proposals/p000107-code-and-name-organization.md#block-imports-of-libraries-of-a-single-package)
- [Broader imports, either all names or arbitrary code](/proposals/p000107-code-and-name-organization.md#broader-imports-either-all-names-or-arbitrary-code)
- [Direct name imports](/proposals/p000107-code-and-name-organization.md#direct-name-imports)
- [Always include the package name in imports](/proposals/p002550-simplified-package-declaration-for-the-main-package.md#keep-the-package-name-in-imports)
- Exports
- [Other `export` syntax structures](/proposals/p3938.md#other-export-syntax-structures)
- [Other `export name` placements](/proposals/p3938.md#other-export-name-placements)
- [Re-exporting cross-package](/proposals/p3938.md#re-exporting-cross-package)
- [Other `export` syntax structures](/proposals/p003938-exporting-imported-names.md#other-export-syntax-structures)
- [Other `export name` placements](/proposals/p003938-exporting-imported-names.md#other-export-name-placements)
- [Re-exporting cross-package](/proposals/p003938-exporting-imported-names.md#re-exporting-cross-package)
- Namespaces
- [File-level namespaces](/proposals/p0107.md#file-level-namespaces)
- [Scoped namespaces](/proposals/p0107.md#scoped-namespaces)
- [Allow prefixing a tuple binding pattern with a namespace](/proposals/p3407.md#allow-prefixing-a-tuple-binding-pattern-with-a-namespace)
- [Allow binding patterns to declare names in multiple namespaces](/proposals/p3407.md#allow-binding-patterns-to-declare-names-in-multiple-namespaces)
- [Allow declaring names in namespaces not owned by the current scope](/proposals/p3407.md#allow-declaring-names-in-namespaces-not-owned-by-the-current-scope)
- [Allow declaring namespaces in scopes other than the file scope](/proposals/p3407.md#allow-declaring-namespaces-in-scopes-other-than-the-file-scope)
- [File-level namespaces](/proposals/p000107-code-and-name-organization.md#file-level-namespaces)
- [Scoped namespaces](/proposals/p000107-code-and-name-organization.md#scoped-namespaces)
- [Allow prefixing a tuple binding pattern with a namespace](/proposals/p003407-clarify-name-bindings-in-namespaces.md#allow-prefixing-a-tuple-binding-pattern-with-a-namespace)
- [Allow binding patterns to declare names in multiple namespaces](/proposals/p003407-clarify-name-bindings-in-namespaces.md#allow-binding-patterns-to-declare-names-in-multiple-namespaces)
- [Allow declaring names in namespaces not owned by the current scope](/proposals/p003407-clarify-name-bindings-in-namespaces.md#allow-declaring-names-in-namespaces-not-owned-by-the-current-scope)
- [Allow declaring namespaces in scopes other than the file scope](/proposals/p003407-clarify-name-bindings-in-namespaces.md#allow-declaring-namespaces-in-scopes-other-than-the-file-scope)
## References
docs/design/code_and_name_organization/source_files.md
+3 -3
View File
@@ -45,9 +45,9 @@ files to NFC as necessary.
## Alternatives considered
- [Character encoding](/proposals/p0142.md#character-encoding-1)
- [Byte order marks](/proposals/p0142.md#byte-order-marks)
- [Normalization forms](/proposals/p0142.md#normalization-forms)
- [Character encoding](/proposals/p000142-unicode-source-files.md#character-encoding-1)
- [Byte order marks](/proposals/p000142-unicode-source-files.md#byte-order-marks)
- [Normalization forms](/proposals/p000142-unicode-source-files.md#normalization-forms)
## References
docs/design/control_flow/conditionals.md
+3 -3
View File
@@ -72,9 +72,9 @@ This code will:
## Alternatives considered
- [Optional braces](/proposals/p0623.md#optional-braces)
- [Optional parentheses](/proposals/p0623.md#optional-parentheses)
- [`elif`](/proposals/p0623.md#elif)
- [Optional braces](/proposals/p000623-require-braces.md#optional-braces)
- [Optional parentheses](/proposals/p000623-require-braces.md#optional-parentheses)
- [`elif`](/proposals/p000623-require-braces.md#elif)
## References
docs/design/control_flow/loops.md
+7 -7
View File
@@ -109,14 +109,14 @@ while (!f.EOF()) {
## Alternatives considered
- [Non-C++ syntax](/proposals/p0340.md#non-c-syntax)
- [Initializing variables in the `while`](/proposals/p0340.md#initializing-variables-in-the-while)
- [Non-C++ syntax](/proposals/p000340-while-loops.md#non-c-syntax)
- [Initializing variables in the `while`](/proposals/p000340-while-loops.md#initializing-variables-in-the-while)
- `for`:
- [Include semisemi `for` loops](/proposals/p0353.md#include-semisemi-for-loops)
- [Multi-variable bindings](/proposals/p0353.md#multi-variable-bindings)
- [`:` versus `in`](/proposals/p0618.md#-versus-in)
- [Optional braces](/proposals/p0623.md#optional-braces)
- [Optional parentheses](/proposals/p0623.md#optional-parentheses)
- [Include semisemi `for` loops](/proposals/p000353-for-loops.md#include-semisemi-for-loops)
- [Multi-variable bindings](/proposals/p000353-for-loops.md#multi-variable-bindings)
- [`:` versus `in`](/proposals/p000618-var-ordering.md#-versus-in)
- [Optional braces](/proposals/p000623-require-braces.md#optional-braces)
- [Optional parentheses](/proposals/p000623-require-braces.md#optional-parentheses)
## References
docs/design/control_flow/return.md
+4 -4
View File
@@ -168,10 +168,10 @@ avoid copies.
## Alternatives considered
- [Implicit or expression returns](/proposals/p0415.md#implicit-or-expression-returns)
- [Named return variable in place of a return type](/proposals/p0257.md#named-return-variable-in-place-of-a-return-type)
- [Retain the C++ rule](/proposals/p0538.md#retain-the-c-rule)
- [Fully divorce functions and procedures](/proposals/p0538.md#fully-divorce-functions-and-procedures)
- [Implicit or expression returns](/proposals/p000415-syntax-return.md#implicit-or-expression-returns)
- [Named return variable in place of a return type](/proposals/p000257-initialization-of-memory-and-variables.md#named-return-variable-in-place-of-a-return-type)
- [Retain the C++ rule](/proposals/p000538-return-with-no-argument.md#retain-the-c-rule)
- [Fully divorce functions and procedures](/proposals/p000538-return-with-no-argument.md#fully-divorce-functions-and-procedures)
## References
docs/design/declaring_entities.md
+22 -22
View File
@@ -207,28 +207,28 @@ fn ValidUse() -> i32 {
## Alternatives considered
- [Other modifier keyword merging approaches](/proposals/p3762.md#other-modifier-keyword-merging-approaches)
- [No `extern` keyword](/proposals/p3762.md#no-extern-keyword)
- [Looser restrictions on declarations](/proposals/p3762.md#looser-restrictions-on-declarations)
- [`extern` naming](/proposals/p3762.md#extern-naming)
- [Default `extern` to private](/proposals/p3762.md#default-extern-to-private)
- [Opaque types](/proposals/p3762.md#opaque-types)
- [Require a library provide its own `extern` declarations](/proposals/p3762.md#require-a-library-provide-its-own-extern-declarations)
- [Allow cross-package `extern` declarations](/proposals/p3762.md#allow-cross-package-extern-declarations)
- [Use a partially or fully semantic rule](/proposals/p3763.md#use-a-partially-or-fully-semantic-rule)
- [Use package-wide name poisoning](/proposals/p3763.md#use-package-wide-name-poisoning)
- [Allow shadowing in implementation file after use in API file](/proposals/p3763.md#allow-shadowing-in-implementation-file-after-use-in-api-file)
- [Allow multiple non-owning declarations, remove the import requirement, or both](/proposals/p3980.md#allow-multiple-non-owning-declarations-remove-the-import-requirement-or-both)
- [Total number of allowed declarations (owning and non-owning)](/proposals/p3980.md#total-number-of-allowed-declarations-owning-and-non-owning)
- [Do not restrict the number of forward declarations](/proposals/p3980.md#do-not-restrict-the-number-of-forward-declarations)
- [Allow up to two declarations total](/proposals/p3980.md#allow-up-to-two-declarations-total)
- [Allow up to four declarations total](/proposals/p3980.md#allow-up-to-four-declarations-total)
- [Don't require a modifier on the owning declarations](/proposals/p3980.md#dont-require-a-modifier-on-the-owning-declarations)
- [Only require `extern` on the first owning declaration](/proposals/p3980.md#only-require-extern-on-the-first-owning-declaration)
- [Separate require-direct-import from non-owning declarations](/proposals/p3980.md#separate-require-direct-import-from-non-owning-declarations)
- [Other `extern` syntaxes](/proposals/p3980.md#other-extern-syntaxes)
- [Have types with `extern` members re-export them](/proposals/p3980.md#have-types-with-extern-members-re-export-them)
- [Require syntactic matching for `extern library` declarations](/proposals/p3980.md#require-syntactic-matching-for-extern-library-declarations)
- [Other modifier keyword merging approaches](/proposals/p003762-merging-forward-declarations.md#other-modifier-keyword-merging-approaches)
- [No `extern` keyword](/proposals/p003762-merging-forward-declarations.md#no-extern-keyword)
- [Looser restrictions on declarations](/proposals/p003762-merging-forward-declarations.md#looser-restrictions-on-declarations)
- [`extern` naming](/proposals/p003762-merging-forward-declarations.md#extern-naming)
- [Default `extern` to private](/proposals/p003762-merging-forward-declarations.md#default-extern-to-private)
- [Opaque types](/proposals/p003762-merging-forward-declarations.md#opaque-types)
- [Require a library provide its own `extern` declarations](/proposals/p003762-merging-forward-declarations.md#require-a-library-provide-its-own-extern-declarations)
- [Allow cross-package `extern` declarations](/proposals/p003762-merging-forward-declarations.md#allow-cross-package-extern-declarations)
- [Use a partially or fully semantic rule](/proposals/p003763-matching-redeclarations.md#use-a-partially-or-fully-semantic-rule)
- [Use package-wide name poisoning](/proposals/p003763-matching-redeclarations.md#use-package-wide-name-poisoning)
- [Allow shadowing in implementation file after use in API file](/proposals/p003763-matching-redeclarations.md#allow-shadowing-in-implementation-file-after-use-in-api-file)
- [Allow multiple non-owning declarations, remove the import requirement, or both](/proposals/p003980-singular-extern-declarations.md#allow-multiple-non-owning-declarations-remove-the-import-requirement-or-both)
- [Total number of allowed declarations (owning and non-owning)](/proposals/p003980-singular-extern-declarations.md#total-number-of-allowed-declarations-owning-and-non-owning)
- [Do not restrict the number of forward declarations](/proposals/p003980-singular-extern-declarations.md#do-not-restrict-the-number-of-forward-declarations)
- [Allow up to two declarations total](/proposals/p003980-singular-extern-declarations.md#allow-up-to-two-declarations-total)
- [Allow up to four declarations total](/proposals/p003980-singular-extern-declarations.md#allow-up-to-four-declarations-total)
- [Don't require a modifier on the owning declarations](/proposals/p003980-singular-extern-declarations.md#dont-require-a-modifier-on-the-owning-declarations)
- [Only require `extern` on the first owning declaration](/proposals/p003980-singular-extern-declarations.md#only-require-extern-on-the-first-owning-declaration)
- [Separate require-direct-import from non-owning declarations](/proposals/p003980-singular-extern-declarations.md#separate-require-direct-import-from-non-owning-declarations)
- [Other `extern` syntaxes](/proposals/p003980-singular-extern-declarations.md#other-extern-syntaxes)
- [Have types with `extern` members re-export them](/proposals/p003980-singular-extern-declarations.md#have-types-with-extern-members-re-export-them)
- [Require syntactic matching for `extern library` declarations](/proposals/p003980-singular-extern-declarations.md#require-syntactic-matching-for-extern-library-declarations)
## References
docs/design/expressions/README.md
+3 -3
View File
@@ -420,9 +420,9 @@ These are referred to as
Other expression documents will list more alternatives; this lists alternatives
not noted elsewhere.
- [Total order](/proposals/p0555.md#total-order)
- [Different precedence for different operands](/proposals/p0555.md#different-precedence-for-different-operands)
- [Require less than a partial order](/proposals/p0555.md#require-less-than-a-partial-order)
- [Total order](/proposals/p000555-operator-precedence.md#total-order)
- [Different precedence for different operands](/proposals/p000555-operator-precedence.md#different-precedence-for-different-operands)
- [Require less than a partial order](/proposals/p000555-operator-precedence.md#require-less-than-a-partial-order)
## References
docs/design/expressions/arithmetic.md
+15 -15
View File
@@ -267,21 +267,21 @@ to give the semantics described above.
## Alternatives considered
- [Use a sufficiently wide result type to avoid overflow](/proposals/p1083.md#use-a-sufficiently-wide-result-type-to-avoid-overflow)
- [Guarantee that the program never proceeds with an incorrect value after overflow](/proposals/p1083.md#guarantee-that-the-program-never-proceeds-with-an-incorrect-value-after-overflow)
- [Guarantee that all integer arithmetic is two's complement](/proposals/p1083.md#guarantee-that-all-integer-arithmetic-is-twos-complement)
- [Treat overflow as an error but don't optimize on it](/proposals/p1083.md#treat-overflow-as-an-error-but-dont-optimize-on-it)
- [Don't let `Unsigned` arithmetic wrap](/proposals/p1083.md#dont-let-unsigned-arithmetic-wrap)
- [Provide separate wrapping types](/proposals/p1083.md#provide-separate-wrapping-types)
- [Do not provide an ordering or division for `uN`](/proposals/p1083.md#do-not-provide-an-ordering-or-division-for-un)
- [Give unary `-` lower precedence](/proposals/p1083.md#give-unary---lower-precedence)
- [Include a unary plus operator](/proposals/p1083.md#include-a-unary-plus-operator)
- [Floating-point modulo operator](/proposals/p1083.md#floating-point-modulo-operator)
- [Provide different division operators](/proposals/p1083.md#provide-different-division-operators)
- [Use different division and modulo semantics](/proposals/p1083.md#use-different-division-and-modulo-semantics)
- [Use different precedence groups for division and multiplication](/proposals/p1083.md#use-different-precedence-groups-for-division-and-multiplication)
- [Use the same precedence group for modulo and multiplication](/proposals/p1083.md#use-the-same-precedence-group-for-modulo-and-multiplication)
- [Use a different spelling for modulo](/proposals/p1083.md#use-a-different-spelling-for-modulo)
- [Use a sufficiently wide result type to avoid overflow](/proposals/p001083-arithmetic-expressions.md#use-a-sufficiently-wide-result-type-to-avoid-overflow)
- [Guarantee that the program never proceeds with an incorrect value after overflow](/proposals/p001083-arithmetic-expressions.md#guarantee-that-the-program-never-proceeds-with-an-incorrect-value-after-overflow)
- [Guarantee that all integer arithmetic is two's complement](/proposals/p001083-arithmetic-expressions.md#guarantee-that-all-integer-arithmetic-is-twos-complement)
- [Treat overflow as an error but don't optimize on it](/proposals/p001083-arithmetic-expressions.md#treat-overflow-as-an-error-but-dont-optimize-on-it)
- [Don't let `Unsigned` arithmetic wrap](/proposals/p001083-arithmetic-expressions.md#dont-let-unsigned-arithmetic-wrap)
- [Provide separate wrapping types](/proposals/p001083-arithmetic-expressions.md#provide-separate-wrapping-types)
- [Do not provide an ordering or division for `uN`](/proposals/p001083-arithmetic-expressions.md#do-not-provide-an-ordering-or-division-for-un)
- [Give unary `-` lower precedence](/proposals/p001083-arithmetic-expressions.md#give-unary---lower-precedence)
- [Include a unary plus operator](/proposals/p001083-arithmetic-expressions.md#include-a-unary-plus-operator)
- [Floating-point modulo operator](/proposals/p001083-arithmetic-expressions.md#floating-point-modulo-operator)
- [Provide different division operators](/proposals/p001083-arithmetic-expressions.md#provide-different-division-operators)
- [Use different division and modulo semantics](/proposals/p001083-arithmetic-expressions.md#use-different-division-and-modulo-semantics)
- [Use different precedence groups for division and multiplication](/proposals/p001083-arithmetic-expressions.md#use-different-precedence-groups-for-division-and-multiplication)
- [Use the same precedence group for modulo and multiplication](/proposals/p001083-arithmetic-expressions.md#use-the-same-precedence-group-for-modulo-and-multiplication)
- [Use a different spelling for modulo](/proposals/p001083-arithmetic-expressions.md#use-a-different-spelling-for-modulo)
## References
docs/design/expressions/as_expressions.md
+5 -5
View File
@@ -176,11 +176,11 @@ type `type`. The program is invalid if this conversion is not possible.
## Alternatives considered
- [Allow `as` to perform some unsafe conversions](/proposals/p0845.md#allow-as-to-perform-some-unsafe-conversions)
- [Allow `as` to perform two's complement truncation](/proposals/p0845.md#allow-as-to-perform-twos-complement-truncation)
- [`as` only performs implicit conversions](/proposals/p0845.md#as-only-performs-implicit-conversions)
- [Integer to bool conversions](/proposals/p0845.md#integer-to-bool-conversions)
- [Bool to integer conversions](/proposals/p0845.md#bool-to-integer-conversions)
- [Allow `as` to perform some unsafe conversions](/proposals/p000845-as-expressions.md#allow-as-to-perform-some-unsafe-conversions)
- [Allow `as` to perform two's complement truncation](/proposals/p000845-as-expressions.md#allow-as-to-perform-twos-complement-truncation)
- [`as` only performs implicit conversions](/proposals/p000845-as-expressions.md#as-only-performs-implicit-conversions)
- [Integer to bool conversions](/proposals/p000845-as-expressions.md#integer-to-bool-conversions)
- [Bool to integer conversions](/proposals/p000845-as-expressions.md#bool-to-integer-conversions)
## References
docs/design/expressions/bitwise.md
+5 -5
View File
@@ -271,11 +271,11 @@ to give the semantics described above.
## Alternatives considered
- [Use different symbols for bitwise operators](/proposals/p1191.md#use-different-symbols-for-bitwise-operators)
- [Provide different operators for arithmetic and logical shifts](/proposals/p1191.md#provide-different-operators-for-arithmetic-and-logical-shifts)
- [Provide rotate operators](/proposals/p1191.md#provide-rotate-operators)
- [Guarantee the behavior of large shifts](/proposals/p1191.md#guarantee-behavior-of-large-shifts)
- [Support shifting a constant by a variable](/proposals/p1191.md#support-shifting-a-constant-by-a-variable)
- [Use different symbols for bitwise operators](/proposals/p001191-bitwise-and-shift-operators.md#use-different-symbols-for-bitwise-operators)
- [Provide different operators for arithmetic and logical shifts](/proposals/p001191-bitwise-and-shift-operators.md#provide-different-operators-for-arithmetic-and-logical-shifts)
- [Provide rotate operators](/proposals/p001191-bitwise-and-shift-operators.md#provide-rotate-operators)
- [Guarantee the behavior of large shifts](/proposals/p001191-bitwise-and-shift-operators.md#guarantee-behavior-of-large-shifts)
- [Support shifting a constant by a variable](/proposals/p001191-bitwise-and-shift-operators.md#support-shifting-a-constant-by-a-variable)
## References
docs/design/expressions/comparison_operators.md
+8 -8
View File
@@ -208,8 +208,8 @@ if (integer as f64 == float) {
```
The two kinds of mixed-type comparison may be
[less efficient](/proposals/p0702.md#performance) than the other kinds due to
the slightly wider domain.
[less efficient](/proposals/p000702-comparison-operators.md#performance) than
the other kinds due to the slightly wider domain.
Note that this approach diverges from C++, which would convert both operands to
a common type first, sometimes performing a lossy conversion potentially giving
@@ -511,12 +511,12 @@ in general. That decision is left to a future proposal.
## Alternatives considered
- [Alternative symbols](/proposals/p0702.md#alternative-symbols)
- [Chained comparisons](/proposals/p0702.md#chained-comparisons-1)
- [Convert operands like C++](/proposals/p0702.md#convert-operands-like-c)
- [Provide a three-way comparison operator](/proposals/p0702.md#provide-a-three-way-comparison-operator)
- [Allow comparisons as the operand of `not`](/proposals/p0702.md#allow-comparisons-as-the-operand-of-not)
- [Rename `OrderedWith` to `ComparableWith`](/proposals/p1178.md#use-comparablewith-instead-of-orderedwith)
- [Alternative symbols](/proposals/p000702-comparison-operators.md#alternative-symbols)
- [Chained comparisons](/proposals/p000702-comparison-operators.md#chained-comparisons-1)
- [Convert operands like C++](/proposals/p000702-comparison-operators.md#convert-operands-like-c)
- [Provide a three-way comparison operator](/proposals/p000702-comparison-operators.md#provide-a-three-way-comparison-operator)
- [Allow comparisons as the operand of `not`](/proposals/p000702-comparison-operators.md#allow-comparisons-as-the-operand-of-not)
- [Rename `OrderedWith` to `ComparableWith`](/proposals/p001178-rework-operator-interfaces.md#use-comparablewith-instead-of-orderedwith)
## References
docs/design/expressions/if.md
+9 -7
View File
@@ -212,18 +212,20 @@ var also_my_string: auto = if cond then my_string else your_string;
## Alternatives considered
- [Provide no conditional expression](/proposals/p0911.md#no-conditional-expression)
- [Provide no conditional expression](/proposals/p000911-conditional-expressions.md#no-conditional-expression)
- Use
[`cond ? expr1 : expr2`, like in C and C++](/proposals/p0911.md#use-c-syntax)
[`cond ? expr1 : expr2`, like in C and C++](/proposals/p000911-conditional-expressions.md#use-c-syntax)
syntax
- Use [`if (cond) expr1 else expr2`](/proposals/p0911.md#no-then) syntax
- Use
[`if (cond) then expr1 else expr2`](/proposals/p0911.md#require-parentheses-around-the-condition)
[`if (cond) expr1 else expr2`](/proposals/p000911-conditional-expressions.md#no-then)
syntax
- Use
[`if (cond) then expr1 else expr2`](/proposals/p000911-conditional-expressions.md#require-parentheses-around-the-condition)
syntax
- Allow
[`1 + if cond then expr1 else expr2`](/proposals/p0911.md#never-require-enclosing-parentheses)
- [Only require one `impl` to specify the common type if implicit conversions in both directions are possible](/proposals/p0911.md#implicit-conversions-in-both-directions)
- [Introduce special rules for lvalue conditionals](/proposals/p0911.md#support-lvalue-conditionals)
[`1 + if cond then expr1 else expr2`](/proposals/p000911-conditional-expressions.md#never-require-enclosing-parentheses)
- [Only require one `impl` to specify the common type if implicit conversions in both directions are possible](/proposals/p000911-conditional-expressions.md#implicit-conversions-in-both-directions)
- [Introduce special rules for lvalue conditionals](/proposals/p000911-conditional-expressions.md#support-lvalue-conditionals)
## References
docs/design/expressions/implicit_conversions.md
+5 -5
View File
@@ -231,11 +231,11 @@ types.
## Alternatives considered
- [Provide lossy and non-semantics-preserving implicit conversions from C++](/proposals/p0820.md#c-conversions)
- [Provide no implicit conversions](/proposals/p0820.md#no-conversions)
- [Provide no extensibility](/proposals/p0820.md#no-extensibility)
- [Apply implicit conversions transitively](/proposals/p0820.md#transitivity)
- [Do not allow negative constants to convert to unsigned types](/proposals/p1191.md#converting-complements-to-unsigned-types)
- [Provide lossy and non-semantics-preserving implicit conversions from C++](/proposals/p000820-implicit-conversions.md#c-conversions)
- [Provide no implicit conversions](/proposals/p000820-implicit-conversions.md#no-conversions)
- [Provide no extensibility](/proposals/p000820-implicit-conversions.md#no-extensibility)
- [Apply implicit conversions transitively](/proposals/p000820-implicit-conversions.md#transitivity)
- [Do not allow negative constants to convert to unsigned types](/proposals/p001191-bitwise-and-shift-operators.md#converting-complements-to-unsigned-types)
## References
docs/design/expressions/indexing.md
+5 -5
View File
@@ -123,11 +123,11 @@ class Span(T:! type) {
## Alternatives considered
- [Different subscripting syntaxes](/proposals/p2274.md#different-subscripting-syntaxes)
- [Multiple indices](/proposals/p2274.md#multiple-indices)
- [Read-only subscripting](/proposals/p2274.md#read-only-subscripting)
- [Rvalue-only subscripting](/proposals/p2274.md#rvalue-only-subscripting)
- [Map-like subscripting](/proposals/p2274.md#map-like-subscripting)
- [Different subscripting syntaxes](/proposals/p002274-subscript-syntax-and-semantics.md#different-subscripting-syntaxes)
- [Multiple indices](/proposals/p002274-subscript-syntax-and-semantics.md#multiple-indices)
- [Read-only subscripting](/proposals/p002274-subscript-syntax-and-semantics.md#read-only-subscripting)
- [Rvalue-only subscripting](/proposals/p002274-subscript-syntax-and-semantics.md#rvalue-only-subscripting)
- [Map-like subscripting](/proposals/p002274-subscript-syntax-and-semantics.md#map-like-subscripting)
## References
docs/design/expressions/literals.md
+8 -8
View File
@@ -189,10 +189,10 @@ var v: i8 = OneHigher(255);
### Alternatives Considered
- [Use an ordinary integer or floating-point type for literals](/proposals/p0144.md#use-an-ordinary-integer-or-floating-point-type-for-literals)
- [Use same type for all literals](/proposals/p0144.md#use-same-type-for-all-literals)
- [Allow leading `-` in literal tokens](/proposals/p0144.md#allow-leading---in-literal-tokens)
- [Forbidding floating-point ties](/proposals/p0866.md#alternatives-considered)
- [Use an ordinary integer or floating-point type for literals](/proposals/p000144-numeric-literal-semantics.md#use-an-ordinary-integer-or-floating-point-type-for-literals)
- [Use same type for all literals](/proposals/p000144-numeric-literal-semantics.md#use-same-type-for-all-literals)
- [Allow leading `-` in literal tokens](/proposals/p000144-numeric-literal-semantics.md#allow-leading---in-literal-tokens)
- [Forbidding floating-point ties](/proposals/p000866-allow-ties-in-floating-literals.md#alternatives-considered)
## Numeric type literals
@@ -237,10 +237,10 @@ as a 32-bit two's complement signed integer. `Main` then returns the output of
### Alternatives considered
- [C++ LP64 convention](/proposals/p2015.md#c-lp64-convention)
- [Type name with length suffix](/proposals/p2015.md#type-name-with-length-suffix)
- [Uppercase suffixes](/proposals/p2015.md#uppercase-suffixes)
- [Additional bit sizes](/proposals/p2015.md#additional-bit-sizes)
- [C++ LP64 convention](/proposals/p002015-numeric-type-literal-syntax.md#c-lp64-convention)
- [Type name with length suffix](/proposals/p002015-numeric-type-literal-syntax.md#type-name-with-length-suffix)
- [Uppercase suffixes](/proposals/p002015-numeric-type-literal-syntax.md#uppercase-suffixes)
- [Additional bit sizes](/proposals/p002015-numeric-type-literal-syntax.md#additional-bit-sizes)
## String literals
docs/design/expressions/logical_operators.md
+7 -7
View File
@@ -136,13 +136,13 @@ also customize how `and`, `or`, and `not` treats them.
## Alternatives considered
- [Use punctuation spelling for all three operators](/proposals/p0680.md#use-punctuation-spelling-for-all-three-operators)
- [Precedence of AND versus OR](/proposals/p0680.md#precedence-of-and-versus-or)
- [Precedence of NOT](/proposals/p0680.md#precedence-of-not)
- [Punctuation form of NOT](/proposals/p0680.md#punctuation-form-of-not)
- [Two forms of NOT](/proposals/p0680.md#two-forms-of-not)
- [Repeated NOT](/proposals/p0680.md#repeated-not)
- [AND and OR produce the decisive value](/proposals/p0680.md#and-and-or-produce-the-decisive-value)
- [Use punctuation spelling for all three operators](/proposals/p000680-and-or-not.md#use-punctuation-spelling-for-all-three-operators)
- [Precedence of AND versus OR](/proposals/p000680-and-or-not.md#precedence-of-and-versus-or)
- [Precedence of NOT](/proposals/p000680-and-or-not.md#precedence-of-not)
- [Punctuation form of NOT](/proposals/p000680-and-or-not.md#punctuation-form-of-not)
- [Two forms of NOT](/proposals/p000680-and-or-not.md#two-forms-of-not)
- [Repeated NOT](/proposals/p000680-and-or-not.md#repeated-not)
- [AND and OR produce the decisive value](/proposals/p000680-and-or-not.md#and-and-or-produce-the-decisive-value)
## References
docs/design/expressions/member_access.md
+9 -8
View File
@@ -33,11 +33,12 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
## Overview
> **TODO:** [p3720: Member binding operators](/proposals/p3720.md) introduces an
> additional "member binding" step, redefines simple member access in terms of
> compound member access, and defines compound member access in terms of calls
> to user-implementable interface methods. This document must be updated to
> reflect those changes.
> **TODO:** >
> [#3720: Member binding operators](/proposals/p003720-member-binding-operators.md)
> introduces an additional "member binding" step, redefines simple member access
> in terms of compound member access, and defines compound member access in
> terms of calls to user-implementable interface methods. This document must be
> updated to reflect those changes.
A _qualified name_ is a [word](../lexical_conventions/words.md) that is preceded
by a period or a rightward arrow. The name is found within a contextually
@@ -945,9 +946,9 @@ var n: i32 = 1 + X.Y;
## Alternatives considered
- [Separate syntax for static versus dynamic access, such as `::` versus `.`](/proposals/p0989.md#separate-syntax-for-static-versus-dynamic-access)
- [Use a different lookup rule for names in templates](/proposals/p0989.md#use-a-different-lookup-rule-in-templates)
- [Meaning of `Type.Interface`](/proposals/p0989.md#meaning-of-typeinterface)
- [Separate syntax for static versus dynamic access, such as `::` versus `.`](/proposals/p000989-member-access-expressions.md#separate-syntax-for-static-versus-dynamic-access)
- [Use a different lookup rule for names in templates](/proposals/p000989-member-access-expressions.md#use-a-different-lookup-rule-in-templates)
- [Meaning of `Type.Interface`](/proposals/p000989-member-access-expressions.md#meaning-of-typeinterface)
## References
docs/design/expressions/pointer_operators.md
+2 -2
View File
@@ -50,8 +50,8 @@ full details, see the [precedence graph](README.md#precedence).
## Alternatives considered
- [Alternative pointer syntaxes](/proposals/p2006.md#alternative-pointer-syntaxes)
- [Alternative pointer syntaxes](/proposals/p002006-values-variables-pointers-and-references.md#alternative-pointer-syntaxes)
## References
- [Proposal #2006: Values, variables, and pointers](/proposals/p2006.md)
- [Proposal #2006: Values, variables, and pointers](/proposals/p002006-values-variables-pointers-and-references.md)
docs/design/expressions/type_operators.md
+4 -4
View File
@@ -58,10 +58,10 @@ with non-type operators.
## Alternatives considered
- [Alternative pointer syntaxes](/proposals/p2006.md#alternative-pointer-syntaxes)
- [Alternative syntaxes for locals](/proposals/p2006.md#alternative-syntaxes-for-locals)
- [Make `const` a postfix rather than prefix operator](/proposals/p2006.md#make-const-a-postfix-rather-than-prefix-operator)
- [Alternative pointer syntaxes](/proposals/p002006-values-variables-pointers-and-references.md#alternative-pointer-syntaxes)
- [Alternative syntaxes for locals](/proposals/p002006-values-variables-pointers-and-references.md#alternative-syntaxes-for-locals)
- [Make `const` a postfix rather than prefix operator](/proposals/p002006-values-variables-pointers-and-references.md#make-const-a-postfix-rather-than-prefix-operator)
## References
- [Proposal #2006: Values, variables, and pointers](/proposals/p2006.md)
- [Proposal #2006: Values, variables, and pointers](/proposals/p002006-values-variables-pointers-and-references.md)
docs/design/functions.md
+6 -6
View File
@@ -26,10 +26,10 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> **TODO:** Update this document to reflect the introduction of function values,
> function types, and the `Call` interface in
> [p2875: Functions, function types, and function calls](/proposals/p2875.md).
> [#2875: Functions, function types, and function calls](/proposals/p002875-functions-function-types-and-function-calls.md).
> **TODO:** Update this document to reflect the changes to named functions in
> [p3848: Lambdas](/proposals/p3848.md).
> [#3848: Lambdas](/proposals/p003848-lambdas.md).
Functions are the core building block for applications. Carbon's basic function
syntax is:
@@ -170,10 +170,10 @@ Other designs build upon basic function syntax to add advanced features:
## Alternatives considered
- [Function keyword](/proposals/p0438.md#function-keyword)
- [Only allow `auto` return types if parameters are compile-time](/proposals/p0826.md#only-allow-auto-return-types-if-parameters-are-generic)
- [Provide alternate function syntax for concise return type inference](/proposals/p0826.md#provide-alternate-function-syntax-for-concise-return-type-inference)
- [Allow separate declaration and definition](/proposals/p0826.md#allow-separate-declaration-and-definition)
- [Function keyword](/proposals/p000438-functions.md#function-keyword)
- [Only allow `auto` return types if parameters are compile-time](/proposals/p000826-function-return-type-inference.md#only-allow-auto-return-types-if-parameters-are-generic)
- [Provide alternate function syntax for concise return type inference](/proposals/p000826-function-return-type-inference.md#provide-alternate-function-syntax-for-concise-return-type-inference)
- [Allow separate declaration and definition](/proposals/p000826-function-return-type-inference.md#allow-separate-declaration-and-definition)
## References
docs/design/generics/details.md
+57 -54
View File
@@ -333,7 +333,7 @@ and doesn't change afterwards.
**References:** Carbon's interface implementation syntax was first defined in
[proposal #553](https://github.com/carbon-language/carbon-lang/pull/553). In
particular, see
[the alternatives considered](/proposals/p0553.md#interface-implementation-syntax).
[the alternatives considered](/proposals/p000553-generics-details-part-1.md#interface-implementation-syntax).
This syntax was changed to use `extend` in
[proposal #2760: Consistent `class` and `interface` syntax](https://github.com/carbon-language/carbon-lang/pull/2760).
@@ -450,7 +450,7 @@ impl Point_ExtendForward as Vector {
> **TODO:** The second `impl` in this example is no longer a valid redeclaration
> of the first after
> [p5366: The name of an `impl` in `class` scope](/proposals/p5366.md).
> [#5366: The name of an `impl` in `class` scope](/proposals/p005366-the-name-of-an-impl-in-class-scope.md).
More about forward declaring implementations in
[its dedicated section](#declaring-implementations).
@@ -1346,7 +1346,7 @@ fn DoHashAndEquals[T:! Hashable](x: T) {
> **TODO:** Update this section as needed to reflect the fact that an impl of an
> interface doesn't impl the interfaces it extends, as adopted in
> [p5168: Forward `impl` declaration of an incomplete interface](/proposals/p5168.md).
> [#5168: Forward `impl` declaration of an incomplete interface](/proposals/p005168-forward-impl-declaration-of-an-incomplete-interface.md).
When implementing an interface, we allow implementing the aliased names as well.
In the case of `Hashable` above, this includes all the members of `Equatable`,
@@ -1376,7 +1376,7 @@ We expect this concept to be common enough to warrant dedicated `interface`
syntax:
> **TODO:** Update this section to reflect the new syntax adopted in
> [p5337: Interface extension and `final impl` update](/proposals/p5337.md).
> [#5337: Interface extension and `final impl` update](/proposals/p005337-interface-extension-and-final-impl-update.md).
```carbon
interface Equatable { fn Equals(self, rhs: Self) -> bool; }
@@ -1588,7 +1588,7 @@ interface MovieCodec {
#### Diamond dependency issue
> **TODO:** Update this section to reflect the changes in
> [p5168: Forward `impl` declaration of an incomplete interface](/proposals/p5168.md).
> [#5168: Forward `impl` declaration of an incomplete interface](/proposals/p005168-forward-impl-declaration-of-an-incomplete-interface.md).
Consider this set of interfaces, simplified from
[this example generic graph library doc](https://docs.google.com/document/d/15Brjv8NO_96jseSesqer5HbghqSTJICJ_fTaZOH0Mg4/edit?usp=sharing&resourcekey=0-CYSbd6-xF8vYHv9m1rolEQ):
@@ -2144,7 +2144,7 @@ keyword `private` before `adapt`, so you might write
> **TODO:** Update this section to reflect the new rules and guidance on
> associated constants in
> [p5168: Forward `impl` declaration of an incomplete interface](/proposals/p5168.md).
> [#5168: Forward `impl` declaration of an incomplete interface](/proposals/p005168-forward-impl-declaration-of-an-incomplete-interface.md).
In addition to associated methods, we allow other kinds of
[associated entities](terminology.md#associated-entity). For consistency, we use
@@ -2275,7 +2275,7 @@ type.
> **TODO:** Document rules on where associated function implementations can be
> declared, as adopted in
> [p5168: Forward `impl` declaration of an incomplete interface](/proposals/p5168.md).
> [#5168: Forward `impl` declaration of an incomplete interface](/proposals/p005168-forward-impl-declaration-of-an-incomplete-interface.md).
## Associated facets
@@ -2344,7 +2344,7 @@ impl VeryLongTypeName as Add
```
> **Alternatives considered:** See
> [other syntax options considered in #731 for specifying associated facets](/proposals/p0731.md#syntax-for-associated-constants).
> [other syntax options considered in #731 for specifying associated facets](/proposals/p000731-generics-details-2-adapters-associated-types-parameterized-interfaces.md#syntax-for-associated-constants).
> In particular, it was deemed that
> [Swift's approach of inferring an associated facet from method signatures in the impl](https://docs.swift.org/swift-book/LanguageGuide/Generics.html#ID190)
> was unneeded complexity.
@@ -2727,15 +2727,15 @@ Implements constraints switched to using the `impls` keyword in
**Alternatives considered:**
- [Different equality constraint operators for symbolic and constants](/proposals/p2173.md#status-quo)
- [Single one-step equality constraint operators that merges constraints](/proposals/p2173.md#equal-types-with-different-interfaces)
- [Restrict constraints to allow computable type equality](/proposals/p2173.md#restrict-constraints-to-allow-computable-type-equality)
- [Find a fully transitive approach to type equality](/proposals/p2173.md#find-a-fully-transitive-approach-to-type-equality)
- [Different syntax for rewrite constraint](/proposals/p2173.md#different-syntax-for-rewrite-constraint)
- [Different syntax for same-type constraint](/proposals/p2173.md#different-syntax-for-same-type-constraint)
- [Required ordering for rewrites](/proposals/p2173.md#required-ordering-for-rewrites)
- [Multi-constraint `where` clauses](/proposals/p2173.md#multi-constraint-where-clauses)
- [Rewrite constraints in `require` constraints](/proposals/p2173.md#rewrite-constraints-in-impl-as-constraints)
- [Different equality constraint operators for symbolic and constants](/proposals/p002173-associated-constant-assignment-versus-equality.md#status-quo)
- [Single one-step equality constraint operators that merges constraints](/proposals/p002173-associated-constant-assignment-versus-equality.md#equal-types-with-different-interfaces)
- [Restrict constraints to allow computable type equality](/proposals/p002173-associated-constant-assignment-versus-equality.md#restrict-constraints-to-allow-computable-type-equality)
- [Find a fully transitive approach to type equality](/proposals/p002173-associated-constant-assignment-versus-equality.md#find-a-fully-transitive-approach-to-type-equality)
- [Different syntax for rewrite constraint](/proposals/p002173-associated-constant-assignment-versus-equality.md#different-syntax-for-rewrite-constraint)
- [Different syntax for same-type constraint](/proposals/p002173-associated-constant-assignment-versus-equality.md#different-syntax-for-same-type-constraint)
- [Required ordering for rewrites](/proposals/p002173-associated-constant-assignment-versus-equality.md#required-ordering-for-rewrites)
- [Multi-constraint `where` clauses](/proposals/p002173-associated-constant-assignment-versus-equality.md#multi-constraint-where-clauses)
- [Rewrite constraints in `require` constraints](/proposals/p002173-associated-constant-assignment-versus-equality.md#rewrite-constraints-in-impl-as-constraints)
#### Recursive constraints
@@ -2927,21 +2927,22 @@ Note that `T:! C where .R = i32` can result in a type `T.R` whose behavior is
different from the behavior of `T.R` given `T:! C`. For example, member lookup
into `T.R` can find different results and operations can therefore have
different behavior. However, this does not violate
[coherence](/proposals/p2173.md#coherence) because the facet types `C` and
`C where .R = i32` don't differ by merely having more type information; rather,
they are different facet types that have an isomorphic set of values, somewhat
like `i32` and `u32`. An `=` constraint is not merely learning a new fact about
a type, it is requesting different behavior.
[coherence](/proposals/p002173-associated-constant-assignment-versus-equality.md#coherence)
because the facet types `C` and `C where .R = i32` don't differ by merely having
more type information; rather, they are different facet types that have an
isomorphic set of values, somewhat like `i32` and `u32`. An `=` constraint is
not merely learning a new fact about a type, it is requesting different
behavior.
This approach has some good properties that
[same-type constraints](#same-type-constraints) have problems with:
- [Equal types with different interfaces](/proposals/p2173.md#equal-types-with-different-interfaces):
- [Equal types with different interfaces](/proposals/p002173-associated-constant-assignment-versus-equality.md#equal-types-with-different-interfaces):
When an associated facet is constrained to be a concrete type, it is
desirable for the associated facet to behave like that concrete type.
- [Type canonicalization](/proposals/p2173.md#type-canonicalization): to
enable efficient type equality.
- [Transitivity of equality of types](/proposals/p2173.md#transitivity-of-equality)
- [Type canonicalization](/proposals/p002173-associated-constant-assignment-versus-equality.md#type-canonicalization):
to enable efficient type equality.
- [Transitivity of equality of types](/proposals/p002173-associated-constant-assignment-versus-equality.md#transitivity-of-equality)
The precise rules governing rewrite constraints are described in
[an appendix](appendix-rewrite-constraints.md).
@@ -3560,7 +3561,7 @@ redundant ways to express a restriction, following the
**Alternative considered:** This rule was added in proposal
[#2376](https://github.com/carbon-language/carbon-lang/pull/2376), which
[considered whether this rule should be added](/proposals/p2376.md#alternatives-considered).
[considered whether this rule should be added](/proposals/p002376-constraints-must-use-self.md#alternatives-considered).
### Referencing names in the interface being defined
@@ -4094,8 +4095,8 @@ There are four facet types related to
specific optimizations.
**Note:** The names `Deletable` and `Destructible` are
[**placeholders**](/proposals/p1154.md#type-of-type-naming) since they do not
conform to the decision on
[**placeholders**](/proposals/p001154-destructors.md#type-of-type-naming) since
they do not conform to the decision on
[question-for-leads issue #1058: "How should interfaces for core functionality be named?"](https://github.com/carbon-language/carbon-lang/issues/1058).
The facet types `Concrete`, `Deletable`, and `TrivialDestructor` all extend
@@ -4598,7 +4599,7 @@ unambiguously picking one as most specific.
Only the implementing interface and types (self type and type parameters) in the
type structure are relevant here; an interface mentioned in a constraint is not
sufficient since it
[need not be imported](/proposals/p0920.md#orphan-rule-could-consider-interface-requirements-in-blanket-impls).
[need not be imported](/proposals/p000920-generic-blanket-impls-details-5.md#orphan-rule-could-consider-interface-requirements-in-blanket-impls).
Since Carbon in addition requires there be no cyclic library dependencies, we
conclude that there is at most one library that can contain `impl` definitions
@@ -4631,7 +4632,7 @@ difference.
#### Prioritization rule
> **TODO:** Document the changes to prioritization adopted in
> [p5337: Interface extension and `final impl` update](/proposals/p5337.md).
> [#5337: Interface extension and `final impl` update](/proposals/p005337-interface-extension-and-final-impl-update.md).
Since at most one library can contain `impl` definitions with a given type
structure, all `impl` definitions with a given type structure must be in the
@@ -4856,7 +4857,7 @@ count decreases. So `Optional(Optional(i32))` is strictly more complicated than
This rule, when combined with [the acyclic rule](#acyclic-rule) that a query
can't repeat exactly,
[guarantees termination](/proposals/p2687.md#proof-of-termination).
[guarantees termination](/proposals/p002687-termination-algorithm-for-impl-selection.md#proof-of-termination).
Consider the example from before,
@@ -4920,12 +4921,12 @@ let V:! B = i32;
> **Alternatives considered:**
>
> - [Recursion limit](/proposals/p2687.md#problem)
> - [Measure complexity using type tree depth](/proposals/p2687.md#measure-complexity-using-type-tree-depth)
> - [Consider each type parameter in an `impl` declaration separately](/proposals/p2687.md#consider-each-type-parameter-in-an-impl-declaration-separately)
> - [Consider types in the interface being implemented as distinct](/proposals/p2687.md#consider-types-in-the-interface-being-implemented-as-distinct)
> - [Require some count to decrease](/proposals/p2687.md#require-some-count-to-decrease)
> - [Require non-type values to stay the same](/proposals/p2687.md#require-non-type-values-to-stay-the-same)
> - [Recursion limit](/proposals/p002687-termination-algorithm-for-impl-selection.md#problem)
> - [Measure complexity using type tree depth](/proposals/p002687-termination-algorithm-for-impl-selection.md#measure-complexity-using-type-tree-depth)
> - [Consider each type parameter in an `impl` declaration separately](/proposals/p002687-termination-algorithm-for-impl-selection.md#consider-each-type-parameter-in-an-impl-declaration-separately)
> - [Consider types in the interface being implemented as distinct](/proposals/p002687-termination-algorithm-for-impl-selection.md#consider-types-in-the-interface-being-implemented-as-distinct)
> - [Require some count to decrease](/proposals/p002687-termination-algorithm-for-impl-selection.md#require-some-count-to-decrease)
> - [Require non-type values to stay the same](/proposals/p002687-termination-algorithm-for-impl-selection.md#require-non-type-values-to-stay-the-same)
> **References:** This algorithm is from proposal
> [#2687: Termination algorithm for impl selection](https://github.com/carbon-language/carbon-lang/pull/2687),
@@ -5033,7 +5034,7 @@ class Optional(T:! type) {
> **TODO:** Update the following passage to reflect the relaxed overlap rule
> adopted in
> [p5337: Interface extension and `final impl` update](/proposals/p5337.md).
> [#5337: Interface extension and `final impl` update](/proposals/p005337-interface-extension-and-final-impl-update.md).
This prevents any higher-priority impl that overlaps a final impl from being
defined unless it agrees with the `final` impl on the overlap. Overlap is
@@ -5074,13 +5075,13 @@ fn F[T:! type](x: T) {
> **Alternatives considered:**
>
> - [Allow interfaces with member functions to compare equal](/proposals/p2868.md#allow-interfaces-with-member-functions-to-compare-equal)
> - [Allow interfaces with member functions to compare equal](/proposals/p002868-allow-overlap-with-a-final-impl-if-identical.md#allow-interfaces-with-member-functions-to-compare-equal)
> - Mark associated constants as `final` instead of an `impl` declaration, in
> proposals
> [#983](/proposals/p0983.md#final-associated-constants-instead-of-final-impls)
> [#983](/proposals/p000983-generics-details-7-final-impls.md#final-associated-constants-instead-of-final-impls)
> and
> [#2868](/proposals/p2868.md#mark-associated-constants-as-final-instead-of-an-impl-declaration)
> - [Prioritize a `final impl` over a more specific `impl` on the overlap](/proposals/p2868.md#prioritize-a-final-impl-over-a-more-specific-impl-on-the-overlap)
> [#2868](/proposals/p002868-allow-overlap-with-a-final-impl-if-identical.md#mark-associated-constants-as-final-instead-of-an-impl-declaration)
> - [Prioritize a `final impl` over a more specific `impl` on the overlap](/proposals/p002868-allow-overlap-with-a-final-impl-if-identical.md#prioritize-a-final-impl-over-a-more-specific-impl-on-the-overlap)
#### Libraries that can contain a `final` impl
@@ -5169,7 +5170,7 @@ differences between the Carbon design and Rust plans:
> **TODO:** Update this section to distinguish between _defined_ and _complete_,
> as adopted in
> [p5087: Qualified lookup into types being defined](/proposals/p5087.md).
> [#5087: Qualified lookup into types being defined](/proposals/p005087-qualified-lookup-into-types-being-defined.md).
Interfaces, named constraints, and their implementations may be forward declared
and then later defined. This is needed to allow cyclic references, for example
@@ -5191,7 +5192,7 @@ used.
> **TODO:** Update this section to reflect the additional things you can do with
> a defined but incomplete type, as adoped in
> [p5087: Qualified lookup into types being defined](/proposals/p5087.md).
> [#5087: Qualified lookup into types being defined](/proposals/p005087-qualified-lookup-into-types-being-defined.md).
The declaration for an interface or named constraint consists of:
@@ -5280,7 +5281,7 @@ An incomplete `C` cannot be used in the following contexts:
### Declaring implementations
> **TODO:** Update this section to reflect the new rules adopted in
> [p5168: Forward `impl` declaration of an incomplete interface](/proposals/p5168.md).
> [#5168: Forward `impl` declaration of an incomplete interface](/proposals/p005168-forward-impl-declaration-of-an-incomplete-interface.md).
The declaration of an interface implementation consists of:
@@ -5298,7 +5299,7 @@ The declaration of an interface implementation consists of:
[associated facets](#associated-facets).
> **TODO:** Document the redeclaration syntax `impl C.(as I)` adopted in
> [p5366: The name of an `impl` in `class` scope](/proposals/p5366.md).
> [#5366: The name of an `impl` in `class` scope](/proposals/p005366-the-name-of-an-impl-in-class-scope.md).
**Note:** The type before the `as` is required except in class scope, where it
defaults to `Self` as described in the
@@ -5340,9 +5341,10 @@ these rules:
### Matching and agreeing
> **TODO:** Update this section to reflect the new terminology and rules adopted
> in [p3763: Matching redeclarations](/proposals/p3763.md), and the new rules
> adopted in
> [p5168: Forward `impl` declaration of an incomplete interface](/proposals/p5168.md).
> in
> [#3763: Matching redeclarations](/proposals/p003763-matching-redeclarations.md),
> and the new rules adopted in
> [#5168: Forward `impl` declaration of an incomplete interface](/proposals/p005168-forward-impl-declaration-of-an-incomplete-interface.md).
Carbon needs to determine if two declarations match in order to say which
definition a forward declaration corresponds to and to verify that nothing is
@@ -5381,7 +5383,7 @@ expressions match along with
> **TODO:** Document the matching rules for the redeclaration syntax
> `impl C.(as I)` adopted in
> [p5366: The name of an `impl` in `class` scope](/proposals/p5366.md).
> [#5366: The name of an `impl` in `class` scope](/proposals/p005366-the-name-of-an-impl-in-class-scope.md).
For implementations to agree:
@@ -5921,7 +5923,7 @@ interface B(T:! type) {
An implementation of `B` for a set of types can only be valid if there is a
visible implementation of `A` with the same `T` parameter for those types with
the `.Result` associated facet set to `i32`. That is
[not sufficient](/proposals/p1088.md#less-strict-about-requirements-with-where-clauses),
[not sufficient](/proposals/p001088-generic-details-10-interface-implemented-requirements.md#less-strict-about-requirements-with-where-clauses),
though, unless the implementation of `A` can't be specialized, either because it
is [marked `final`](#final-impl-declarations) or is not
[parameterized](#parameterized-impl-declarations). Implementations in other
@@ -6636,7 +6638,8 @@ class Optional(T:! Movable) {
```
> **Alternative considered:** Direct support for specialization of types was
> considered in [proposal #1146](/proposals/p1146.md#alternatives-considered).
> considered in
> [proposal #1146](/proposals/p001146-generic-details-12-parameterized-types.md#alternatives-considered).
## Future work
@@ -6737,7 +6740,7 @@ template parameters. For example, we might support a predicate that constrains
an integer to live inside a specified range. See
[question-for-leads issue #2153: Checked generics calling templates](https://github.com/carbon-language/carbon-lang/issues/2153)
and
[future work in proposal #2200: Template generics](/proposals/p2200.md#predicates-constraints-on-values).
[future work in proposal #2200: Template generics](/proposals/p002200-template-generics.md#predicates-constraints-on-values).
## References
docs/design/lambdas.md
+4 -4
View File
@@ -481,7 +481,7 @@ function fields with a `self` parameter.
## Alternatives considered
- [Terse vs Elaborated](/proposals/p3848.md#alternative-considered-terse-vs-elaborated)
- [Sigil](/proposals/p3848.md#alternative-considered-sigil)
- [Additional Positional Parameter Restriction](/proposals/p3848.md#alternative-considered-additional-positional-parameter-restriction)
- [Recursive Self](/proposals/p3848.md#alternative-considered-recursive-self)
- [Terse vs Elaborated](/proposals/p003848-lambdas.md#alternative-considered-terse-vs-elaborated)
- [Sigil](/proposals/p003848-lambdas.md#alternative-considered-sigil)
- [Additional Positional Parameter Restriction](/proposals/p003848-lambdas.md#alternative-considered-additional-positional-parameter-restriction)
- [Recursive Self](/proposals/p003848-lambdas.md#alternative-considered-recursive-self)
docs/design/lexical_conventions/comments.md
+5 -5
View File
@@ -46,11 +46,11 @@ line in the region.
## Alternatives considered
- [Intra-line comments](/proposals/p0198.md#intra-line-comments)
- [Multi-line text comments](/proposals/p0198.md#multi-line-text-comments)
- [Block comments](/proposals/p0198.md#block-comments-2)
- [Documentation comments](/proposals/p0198.md#documentation-comments)
- [Code folding comments](/proposals/p0198.md#code-folding-comments)
- [Intra-line comments](/proposals/p000198-comments.md#intra-line-comments)
- [Multi-line text comments](/proposals/p000198-comments.md#multi-line-text-comments)
- [Block comments](/proposals/p000198-comments.md#block-comments-2)
- [Documentation comments](/proposals/p000198-comments.md#documentation-comments)
- [Code folding comments](/proposals/p000198-comments.md#code-folding-comments)
## References
docs/design/lexical_conventions/numeric_literals.md
+11 -11
View File
@@ -138,17 +138,17 @@ cases for the goal of not leaving room for a lower level language:
## Alternatives considered
- [Integer bases](/proposals/p0143.md#integer-bases)
- [Octal literals](/proposals/p0143.md#octal-literals)
- [Decimal literals](/proposals/p0143.md#decimal-literals)
- [Case sensitivity](/proposals/p0143.md#case-sensitivity)
- [Real number syntax](/proposals/p0143.md#real-number-syntax)
- [Disallow ties](/proposals/p0866.md)
- [Digit separator syntax](/proposals/p0143.md#digit-separator-syntax)
- [3-digit decimal groupings](/proposals/p1983.md#3-digit-decimal-groupings)
- [2-digit or 4-digit hexadecimal digit groupings](/proposals/p1983.md#2-digit-or-4-digit-hexadecimal-digit-groupings)
- [Disallow digit separators in fractions](/proposals/p1983.md#disallow-digit-separators-in-fractions)
- [No octal literals](/proposals/p6910.md#no-octal-literals)
- [Integer bases](/proposals/p000143-numeric-literals.md#integer-bases)
- [Octal literals](/proposals/p000143-numeric-literals.md#octal-literals)
- [Decimal literals](/proposals/p000143-numeric-literals.md#decimal-literals)
- [Case sensitivity](/proposals/p000143-numeric-literals.md#case-sensitivity)
- [Real number syntax](/proposals/p000143-numeric-literals.md#real-number-syntax)
- [Disallow ties](/proposals/p000866-allow-ties-in-floating-literals.md)
- [Digit separator syntax](/proposals/p000143-numeric-literals.md#digit-separator-syntax)
- [3-digit decimal groupings](/proposals/p001983-weaken-digit-separator-placement-rules.md#3-digit-decimal-groupings)
- [2-digit or 4-digit hexadecimal digit groupings](/proposals/p001983-weaken-digit-separator-placement-rules.md#2-digit-or-4-digit-hexadecimal-digit-groupings)
- [Disallow digit separators in fractions](/proposals/p001983-weaken-digit-separator-placement-rules.md#disallow-digit-separators-in-fractions)
- [No octal literals](/proposals/p006910-support-octal-literals.md#no-octal-literals)
## References
docs/design/lexical_conventions/string_literals.md
+11 -11
View File
@@ -326,18 +326,18 @@ string in the type system. In such string literals, we should consider rejecting
## Alternatives considered
- [Block string literals](/proposals/p0199.md#block-string-literals)
- [Leading whitespace removal](/proposals/p0199.md#leading-whitespace-removal)
- [Terminating newline](/proposals/p0199.md#terminating-newline)
- [Escape sequences](/proposals/p0199.md#escape-sequences-1)
- [Block string literals](/proposals/p000199-string-literals.md#block-string-literals)
- [Leading whitespace removal](/proposals/p000199-string-literals.md#leading-whitespace-removal)
- [Terminating newline](/proposals/p000199-string-literals.md#terminating-newline)
- [Escape sequences](/proposals/p000199-string-literals.md#escape-sequences-1)
- Unicode escape sequences:
- [Allow zero digits](/proposals/p2040.md#allow-zero-digits)
- [Allow any number of hexadecimal characters](/proposals/p2040.md#allow-any-number-of-hexadecimal-characters)
- [Limiting to 6 digits versus 8](/proposals/p2040.md#limiting-to-6-digits-versus-8)
- [Raw string literals](/proposals/p0199.md#raw-string-literals-1)
- [Trailing whitespace](/proposals/p0199.md#trailing-whitespace)
- [Line separators](/proposals/p0199.md#line-separators)
- [Internal whitespace](/proposals/p0199.md#internal-whitespace)
- [Allow zero digits](/proposals/p002040-unicode-escape-code-length.md#allow-zero-digits)
- [Allow any number of hexadecimal characters](/proposals/p002040-unicode-escape-code-length.md#allow-any-number-of-hexadecimal-characters)
- [Limiting to 6 digits versus 8](/proposals/p002040-unicode-escape-code-length.md#limiting-to-6-digits-versus-8)
- [Raw string literals](/proposals/p000199-string-literals.md#raw-string-literals-1)
- [Trailing whitespace](/proposals/p000199-string-literals.md#trailing-whitespace)
- [Line separators](/proposals/p000199-string-literals.md#line-separators)
- [Internal whitespace](/proposals/p000199-string-literals.md#internal-whitespace)
- [Different restrictions for file type indicators](https://github.com/carbon-language/carbon-lang/issues/2140)
## References
docs/design/lexical_conventions/symbolic_tokens.md
+1 -1
View File
@@ -101,7 +101,7 @@ source file:
## Alternatives considered
[Alternatives from proposal #601](/proposals/p0601.md#alternatives-considered):
[Alternatives from proposal #601](/proposals/p000601-operator-tokens.md#alternatives-considered):
- lex the longest sequence of symbolic characters rather than lexing only the
longest known operator
docs/design/lexical_conventions/whitespace.md
+1 -1
View File
@@ -21,7 +21,7 @@ The exact lexical form of Carbon whitespace has not yet been settled. However,
Carbon will follow lexical conventions for whitespace based on
[Unicode Annex #31](https://unicode.org/reports/tr31/). TODO: Update this once
the precise rules are decided; see the
[Unicode source files](/proposals/p0142.md#characters-in-identifiers-and-whitespace)
[Unicode source files](/proposals/p000142-unicode-source-files.md#characters-in-identifiers-and-whitespace)
proposal.
Unicode Annex #31 suggests selecting whitespace characters based on the
docs/design/lexical_conventions/words.md
+11 -11
View File
@@ -29,7 +29,7 @@ The exact lexical form of words has not yet been settled. However, Carbon will
follow lexical conventions for identifiers based on
[Unicode Annex #31](https://unicode.org/reports/tr31/). TODO: Update this once
the precise rules are decided; see the
[Unicode source files](/proposals/p0142.md#characters-in-identifiers-and-whitespace)
[Unicode source files](/proposals/p000142-unicode-source-files.md#characters-in-identifiers-and-whitespace)
proposal.
Carbon source files, including comments and string literals, are required to be
@@ -131,22 +131,22 @@ then `word` and `r#word` have the same meaning.
Overview:
- [Character encoding: We could restrict words to ASCII.](/proposals/p0142.md#character-encoding-1)
- [Normalization form alternatives considered](/proposals/p0142.md#normalization-forms)
- [Character encoding: We could restrict words to ASCII.](/proposals/p000142-unicode-source-files.md#character-encoding-1)
- [Normalization form alternatives considered](/proposals/p000142-unicode-source-files.md#normalization-forms)
Type literals:
- [Use C++ type keywords with LP64 convention](/proposals/p2015.md#c-lp64-convention)
- [Use full type name with length suffix](/proposals/p2015.md#type-name-with-length-suffix)
- [Use uppercase for type names](/proposals/p2015.md#uppercase-suffixes)
- [Support additional bit widths](/proposals/p2015.md#additional-bit-sizes)
- [Use C++ type keywords with LP64 convention](/proposals/p002015-numeric-type-literal-syntax.md#c-lp64-convention)
- [Use full type name with length suffix](/proposals/p002015-numeric-type-literal-syntax.md#type-name-with-length-suffix)
- [Use uppercase for type names](/proposals/p002015-numeric-type-literal-syntax.md#uppercase-suffixes)
- [Support additional bit widths](/proposals/p002015-numeric-type-literal-syntax.md#additional-bit-sizes)
Raw identifiers:
- [Other raw identifier syntaxes](/proposals/p3797.md#other-raw-identifier-syntaxes)
- [Restrict raw identifier syntax to current and future keywords](/proposals/p3797.md#restrict-raw-identifier-syntax-to-current-and-future-keywords)
- [Don't require syntax for references to raw identifiers](/proposals/p3797.md#dont-require-syntax-for-references-to-raw-identifiers)
- [Don't provide raw identifier syntax](/proposals/p3797.md#dont-provide-raw-identifier-syntax)
- [Other raw identifier syntaxes](/proposals/p003797-raw-identifier-syntax.md#other-raw-identifier-syntaxes)
- [Restrict raw identifier syntax to current and future keywords](/proposals/p003797-raw-identifier-syntax.md#restrict-raw-identifier-syntax-to-current-and-future-keywords)
- [Don't require syntax for references to raw identifiers](/proposals/p003797-raw-identifier-syntax.md#dont-require-syntax-for-references-to-raw-identifiers)
- [Don't provide raw identifier syntax](/proposals/p003797-raw-identifier-syntax.md#dont-provide-raw-identifier-syntax)
## References
docs/design/naming_conventions.md
+2 -2
View File
@@ -95,8 +95,8 @@ will make decisions on future naming.
## Alternatives considered
- [Other naming conventions](/proposals/p0861.md#other-naming-conventions)
- [Other conventions for naming Carbon types](/proposals/p0861.md#other-conventions-for-naming-carbon-types)
- [Other naming conventions](/proposals/p000861-naming-conventions.md#other-naming-conventions)
- [Other conventions for naming Carbon types](/proposals/p000861-naming-conventions.md#other-conventions-for-naming-carbon-types)
## References
docs/design/pattern_matching.md
+26 -24
View File
@@ -123,7 +123,7 @@ would, in the cases where they overlap.
#### Alternatives considered
- [Introducer syntax for expression patterns](/proposals/p2188.md#introducer-syntax-for-expression-patterns)
- [Introducer syntax for expression patterns](/proposals/p002188-pattern-matching-syntax-and-semantics.md#introducer-syntax-for-expression-patterns)
### Binding patterns
@@ -225,8 +225,10 @@ fn F(n: i32) {
}
```
As specified in [#1084](/proposals/p1084.md), function redeclarations may
replace binding names with `_`s but may not use different names.
As specified in
[#1084](/proposals/p001084-generics-details-9-forward-declarations.md), function
redeclarations may replace binding names with `_`s but may not use different
names.
```carbon
fn G(n: i32);
@@ -241,11 +243,11 @@ fn H(m: i32) {}
##### Alternatives considered
- [Commented names](/proposals/p2022.md#commented-names)
- [Only short form support with `_`](/proposals/p2022.md#only-short-form-support-with-_)
- [Named identifiers prefixed with `_`](/proposals/p2022.md#named-identifiers-prefixed-with-_)
- [Anonymous, named identifiers](/proposals/p2022.md#anonymous-named-identifiers)
- [Attributes](/proposals/p2022.md#attributes)
- [Commented names](/proposals/p002022-unused-pattern-bindings-unused-function-parameters.md#commented-names)
- [Only short form support with `_`](/proposals/p002022-unused-pattern-bindings-unused-function-parameters.md#only-short-form-support-with-_)
- [Named identifiers prefixed with `_`](/proposals/p002022-unused-pattern-bindings-unused-function-parameters.md#named-identifiers-prefixed-with-_)
- [Anonymous, named identifiers](/proposals/p002022-unused-pattern-bindings-unused-function-parameters.md#anonymous-named-identifiers)
- [Attributes](/proposals/p002022-unused-pattern-bindings-unused-function-parameters.md#attributes)
#### `auto` and type deduction
@@ -290,7 +292,7 @@ specified.
#### Alternatives considered
- [Shorthand for `auto`](/proposals/p2188.md#shorthand-for-auto)
- [Shorthand for `auto`](/proposals/p002188-pattern-matching-syntax-and-semantics.md#shorthand-for-auto)
### `var`
@@ -328,9 +330,9 @@ _pattern_ `=` _expression_ `;`.
#### Alternatives considered
- [Treat all bindings under `var` as variable bindings](/proposals/p5164.md#treat-all-bindings-under-var-as-variable-bindings)
- [Make `var` a binding pattern modifier](/proposals/p5164.md#make-var-a-binding-pattern-modifier)
- [Initialize storage once pattern matching succeeds](/proposals/p5164.md#initialize-storage-once-pattern-matching-succeeds)
- [Treat all bindings under `var` as variable bindings](/proposals/p005164-updates-to-pattern-matching-for-objects.md#treat-all-bindings-under-var-as-variable-bindings)
- [Make `var` a binding pattern modifier](/proposals/p005164-updates-to-pattern-matching-for-objects.md#make-var-a-binding-pattern-modifier)
- [Initialize storage once pattern matching succeeds](/proposals/p005164-updates-to-pattern-matching-for-objects.md#initialize-storage-once-pattern-matching-succeeds)
### `unused`
@@ -350,10 +352,10 @@ bindings in a pattern. Nesting `unused` markers is an error. When an `unused`
marker applies only to anonymous bindings `_` and is thus redundant, a warning
is produced. `var` and `unused` may appear in any order in a pattern.
As specified in [#3763](/proposals/p3763.md), `unused` markers may only appear
on definitions, not on non-defining declarations. Function redeclarations that
are also definitions may have difference due to `unused` markers, but they may
not have different names.
As specified in [#3763](/proposals/p003763-matching-redeclarations.md), `unused`
markers may only appear on definitions, not on non-defining declarations.
Function redeclarations that are also definitions may have difference due to
`unused` markers, but they may not have different names.
```carbon
fn J(n: i32);
@@ -444,7 +446,7 @@ This is valid even if all fields are actually named in the pattern.
#### Alternatives considered
- [Struct pattern syntax](/proposals/p2188.md#struct-pattern-syntax)
- [Struct pattern syntax](/proposals/p002188-pattern-matching-syntax-and-semantics.md#struct-pattern-syntax)
### Alternative patterns
@@ -677,8 +679,8 @@ We will diagnose the following situations:
#### Alternatives considered
- [Treat expression patterns as exhaustive if they cover all possible values](/proposals/p2188.md#treat-expression-patterns-as-exhaustive-if-they-cover-all-possible-values)
- [Allow non-exhaustive `match` statements](/proposals/p2188.md#allow-non-exhaustive-match-statements)
- [Treat expression patterns as exhaustive if they cover all possible values](/proposals/p002188-pattern-matching-syntax-and-semantics.md#treat-expression-patterns-as-exhaustive-if-they-cover-all-possible-values)
- [Allow non-exhaustive `match` statements](/proposals/p002188-pattern-matching-syntax-and-semantics.md#allow-non-exhaustive-match-statements)
## Pattern usage
@@ -768,7 +770,7 @@ fn F(x: X) {
#### Alternatives considered
- [Allow variable binding patterns to alias across `case`s](/proposals/p5164.md#allow-variable-binding-patterns-to-alias-across-cases)
- [Allow variable binding patterns to alias across `case`s](/proposals/p005164-updates-to-pattern-matching-for-objects.md#allow-variable-binding-patterns-to-alias-across-cases)
#### Guards
@@ -928,8 +930,8 @@ evaluation order will be evaluated.
### Alternatives considered
- [Breadth-first evaluation order](/proposals/p5545.md#breadth-first-evaluation-order)
- [Depth-first evaluation with a different "horizontal" order](/proposals/p5545.md#depth-first-evaluation-with-a-different-horizontal-order)
- [Breadth-first evaluation order](/proposals/p005545-expression-form-basics.md#breadth-first-evaluation-order)
- [Depth-first evaluation with a different "horizontal" order](/proposals/p005545-expression-form-basics.md#depth-first-evaluation-with-a-different-horizontal-order)
## Open questions
@@ -945,8 +947,8 @@ pattern matching machinery, what (if any) restrictions are imposed, etc.
## Alternatives considered
- [Type pattern matching](/proposals/p2188.md#type-pattern-matching)
- [Allow guards on arbitrary patterns](/proposals/p2188.md#allow-guards-on-arbitrary-patterns)
- [Type pattern matching](/proposals/p002188-pattern-matching-syntax-and-semantics.md#type-pattern-matching)
- [Allow guards on arbitrary patterns](/proposals/p002188-pattern-matching-syntax-and-semantics.md#allow-guards-on-arbitrary-patterns)
## References
docs/design/sum_types.md
+6 -6
View File
@@ -228,15 +228,15 @@ return an index that identifies the `case` body to be executed.
## Alternatives considered
- [Providing `choice` types only](/proposals/p0157.md#choice-types-only), with
no support for user-defined sum types.
- [Indexing alternatives by type](/proposals/p0157.md#indexing-by-type)
- [Providing `choice` types only](/proposals/p000157-design-direction-for-sum-types.md#choice-types-only),
with no support for user-defined sum types.
- [Indexing alternatives by type](/proposals/p000157-design-direction-for-sum-types.md#indexing-by-type)
instead of by name.
- Implementing user-defined sum types in terms of
[`choice` type proxies](/proposals/p0157.md#pattern-matching-proxies) rather
than callbacks.
[`choice` type proxies](/proposals/p000157-design-direction-for-sum-types.md#pattern-matching-proxies)
rather than callbacks.
- Implementing user-defined sum types in terms of invertible
[pattern functions](/proposals/p0157.md#pattern-functions).
[pattern functions](/proposals/p000157-design-direction-for-sum-types.md#pattern-functions).
## References
docs/design/tuples.md
+4 -4
View File
@@ -174,10 +174,10 @@ answer here:
## Alternatives considered
- [Indexing with square brackets](/proposals/p3646.md#square-bracket-notation)
- [Indexing from the end of a tuple](/proposals/p3646.md#negative-indexing-from-the-end-of-the-tuple)
- [Restrict indexes to decimal integers](/proposals/p3646.md#decimal-indexing-restriction)
- [Alternatives to trailing commas](/proposals/p3646.md#trailing-commas)
- [Indexing with square brackets](/proposals/p003646-tuples-and-tuple-indexing.md#square-bracket-notation)
- [Indexing from the end of a tuple](/proposals/p003646-tuples-and-tuple-indexing.md#negative-indexing-from-the-end-of-the-tuple)
- [Restrict indexes to decimal integers](/proposals/p003646-tuples-and-tuple-indexing.md#decimal-indexing-restriction)
- [Alternatives to trailing commas](/proposals/p003646-tuples-and-tuple-indexing.md#trailing-commas)
## References
docs/design/type_inference.md
+1 -1
View File
@@ -48,7 +48,7 @@ return types.
## Alternatives considered
- [Use `_` instead of `auto`](/proposals/p0851.md#use-_-instead-of-auto)
- [Use `_` instead of `auto`](/proposals/p000851-variable-type-inference.md#use-_-instead-of-auto)
## References
docs/design/values.md
+37 -36
View File
@@ -597,7 +597,7 @@ fn F(s_value: S) {
```
The specific tradeoff here is covered in a proposal
[alternative](/proposals/p2006.md#value-expression-escape-hatches).
[alternative](/proposals/p002006-values-variables-pointers-and-references.md#value-expression-escape-hatches).
## Initializing expressions
@@ -727,10 +727,11 @@ proper.
#### Deferred initialization from values and references
TODO: This section needs to be updated to reflect the addition of `-> val`
returns in [proposal #5434](/proposals/p5434.md). This section could be replaced
by a statement that initializing returns may be replaced by value returns when
that is safe and correct, moving much of this content into a description of how
value returns works.
returns in
[proposal #5434](/proposals/p005434-ref-parameters-arguments-returns-and-val-returns.md).
This section could be replaced by a statement that initializing returns may be
replaced by value returns when that is safe and correct, moving much of this
content into a description of how value returns works.
Carbon also makes the evaluation of function calls and return statements tightly
linked in order to enable more efficiency improvements. It allows the actual
@@ -1107,7 +1108,7 @@ specialized constructs given the specialized nature of these operations.
### Reference types
TODO: This section needs to be updated to reflect
[proposal #5434](/proposals/p5434.md).
[proposal #5434](/proposals/p005434-ref-parameters-arguments-returns-and-val-returns.md).
Unlike C++, Carbon does not currently have reference types. The only form of
indirect access are pointers. There are a few aspects to this decision that need
@@ -1136,9 +1137,9 @@ distinction between indirect access and direct access.
For a full discussion of the tradeoffs of these design decisions, see the
alternatives considered section of [P2006]:
- [References in addition to pointers](/proposals/p2006.md#references-in-addition-to-pointers)
- [Syntax-free or automatic dereferencing](/proposals/p2006.md#syntax-free-or-automatic-dereferencing)
- [Exclusively using references](/proposals/p2006.md#exclusively-using-references)
- [References in addition to pointers](/proposals/p002006-values-variables-pointers-and-references.md#references-in-addition-to-pointers)
- [Syntax-free or automatic dereferencing](/proposals/p002006-values-variables-pointers-and-references.md#syntax-free-or-automatic-dereferencing)
- [Exclusively using references](/proposals/p002006-values-variables-pointers-and-references.md#exclusively-using-references)
### Pointer syntax
@@ -1159,7 +1160,7 @@ pointer types as they are commonly written in code and are expected to be
extremely common and a key anchor of syntactic similarity between the languages.
The different alternatives and tradeoffs for this syntax issue were discussed
extensively in [#523] and are summarized in the
[proposal](/proposals/p2006.md#alternative-pointer-syntaxes).
[proposal](/proposals/p002006-values-variables-pointers-and-references.md#alternative-pointer-syntaxes).
[#523]: https://github.com/carbon-language/carbon-lang/issues/523
@@ -1486,33 +1487,33 @@ itself.
## Alternatives considered
- [No `var` introducer keyword](/proposals/p0339.md#no-var-introducer-keyword)
- [Name of the `var` statement introducer](/proposals/p0339.md#name-of-the-var-statement-introducer)
- [Colon between type and identifier](/proposals/p0339.md#colon-between-type-and-identifier)
- [Type elision](/proposals/p0339.md#type-elision)
- [Type ordering](/proposals/p0618.md#type-ordering)
- [Elide the type instead of using `auto`](/proposals/p0851.md#elide-the-type-instead-of-using-auto)
- [Value expression escape hatches](/proposals/p2006.md#value-expression-escape-hatches)
- [References in addition to pointers](/proposals/p2006.md#references-in-addition-to-pointers)
- [Syntax-free or automatic dereferencing](/proposals/p2006.md#syntax-free-or-automatic-dereferencing)
- [Exclusively using references](/proposals/p2006.md#exclusively-using-references)
- [Alternative pointer syntaxes](/proposals/p2006.md#alternative-pointer-syntaxes)
- [Alternative syntaxes for locals](/proposals/p2006.md#alternative-syntaxes-for-locals)
- [Mixed expression categories](/proposals/p5545.md#mixed-expression-categories)
- [Don't implicitly convert to less-primitive forms](/proposals/p5545.md#dont-implicitly-convert-to-less-primitive-forms)
- [No `var` introducer keyword](/proposals/p000339-var-statement.md#no-var-introducer-keyword)
- [Name of the `var` statement introducer](/proposals/p000339-var-statement.md#name-of-the-var-statement-introducer)
- [Colon between type and identifier](/proposals/p000339-var-statement.md#colon-between-type-and-identifier)
- [Type elision](/proposals/p000339-var-statement.md#type-elision)
- [Type ordering](/proposals/p000618-var-ordering.md#type-ordering)
- [Elide the type instead of using `auto`](/proposals/p000851-variable-type-inference.md#elide-the-type-instead-of-using-auto)
- [Value expression escape hatches](/proposals/p002006-values-variables-pointers-and-references.md#value-expression-escape-hatches)
- [References in addition to pointers](/proposals/p002006-values-variables-pointers-and-references.md#references-in-addition-to-pointers)
- [Syntax-free or automatic dereferencing](/proposals/p002006-values-variables-pointers-and-references.md#syntax-free-or-automatic-dereferencing)
- [Exclusively using references](/proposals/p002006-values-variables-pointers-and-references.md#exclusively-using-references)
- [Alternative pointer syntaxes](/proposals/p002006-values-variables-pointers-and-references.md#alternative-pointer-syntaxes)
- [Alternative syntaxes for locals](/proposals/p002006-values-variables-pointers-and-references.md#alternative-syntaxes-for-locals)
- [Mixed expression categories](/proposals/p005545-expression-form-basics.md#mixed-expression-categories)
- [Don't implicitly convert to less-primitive forms](/proposals/p005545-expression-form-basics.md#dont-implicitly-convert-to-less-primitive-forms)
## References
- [Proposal #257: Initialization of memory and values][p0257]
- [Proposal #339: `var` statement][p0339]
- [Proposal #618: `var` ordering][p0618]
- [Proposal #851: auto keyword for vars][p0851]
- [Proposal #2006: Values, variables, and pointers][p2006]
- [Proposal #5545: Expression form basics][p5545]
- [Proposal #257: Initialization of memory and values][#257]
- [Proposal #339: `var` statement][#339]
- [Proposal #618: `var` ordering][#618]
- [Proposal #851: auto keyword for vars][#851]
- [Proposal #2006: Values, variables, and pointers][#2006]
- [Proposal #5545: Expression form basics][#5545]
[p0257]: /proposals/p0257.md
[p0339]: /proposals/p0339.md
[p0618]: /proposals/p0618.md
[p0851]: /proposals/p0851.md
[p2006]: /proposals/p2006.md
[p5545]: /proposals/p5545.md
[#257]: /proposals/p000257-initialization-of-memory-and-variables.md
[#339]: /proposals/p000339-var-statement.md
[#618]: /proposals/p000618-var-ordering.md
[#851]: /proposals/p000851-variable-type-inference.md
[#2006]: /proposals/p002006-values-variables-pointers-and-references.md
[#5545]: /proposals/p005545-expression-form-basics.md
docs/design/variadics.md
+19 -19
View File
@@ -921,25 +921,25 @@ any further merging, so this must be the canonical form.
## Alternatives considered
- [Member packs](/proposals/p2240.md#member-packs)
- [Single semantic model for pack expansions](/proposals/p2240.md#single-semantic-model-for-pack-expansions)
- [Generalize `expand`](/proposals/p2240.md#generalize-expand)
- [Omit `expand`](/proposals/p2240.md#omit-expand)
- [Support expanding arrays](/proposals/p2240.md#support-expanding-arrays)
- [Omit each-names](/proposals/p2240.md#omit-each-names)
- [Disallow pack-type bindings](/proposals/p2240.md#disallow-pack-type-bindings)
- [Fold expressions](/proposals/p2240.md#fold-expressions)
- [Allow multiple pack expansions in a tuple pattern](/proposals/p2240.md#allow-multiple-pack-expansions-in-a-tuple-pattern)
- [Allow nested pack expansions](/proposals/p2240.md#allow-nested-pack-expansions)
- [Use postfix instead of prefix `...`](/proposals/p2240.md#use-postfix-instead-of-prefix-)
- [Avoid context-sensitity in pack expansions](/proposals/p2240.md#avoid-context-sensitity-in-pack-expansions)
- [Fold-like syntax](/proposals/p2240.md#fold-like-syntax)
- [Variadic blocks](/proposals/p2240.md#variadic-blocks)
- [Keyword syntax](/proposals/p2240.md#keyword-syntax)
- [Require parentheses around `each`](/proposals/p2240.md#require-parentheses-around-each)
- [Fused expansion tokens](/proposals/p2240.md#fused-expansion-tokens)
- [No parameter merging](/proposals/p2240.md#no-parameter-merging)
- [Exhaustive function call typechecking](/proposals/p2240.md#exhaustive-function-call-typechecking)
- [Member packs](/proposals/p002240-variadics.md#member-packs)
- [Single semantic model for pack expansions](/proposals/p002240-variadics.md#single-semantic-model-for-pack-expansions)
- [Generalize `expand`](/proposals/p002240-variadics.md#generalize-expand)
- [Omit `expand`](/proposals/p002240-variadics.md#omit-expand)
- [Support expanding arrays](/proposals/p002240-variadics.md#support-expanding-arrays)
- [Omit each-names](/proposals/p002240-variadics.md#omit-each-names)
- [Disallow pack-type bindings](/proposals/p002240-variadics.md#disallow-pack-type-bindings)
- [Fold expressions](/proposals/p002240-variadics.md#fold-expressions)
- [Allow multiple pack expansions in a tuple pattern](/proposals/p002240-variadics.md#allow-multiple-pack-expansions-in-a-tuple-pattern)
- [Allow nested pack expansions](/proposals/p002240-variadics.md#allow-nested-pack-expansions)
- [Use postfix instead of prefix `...`](/proposals/p002240-variadics.md#use-postfix-instead-of-prefix-)
- [Avoid context-sensitity in pack expansions](/proposals/p002240-variadics.md#avoid-context-sensitity-in-pack-expansions)
- [Fold-like syntax](/proposals/p002240-variadics.md#fold-like-syntax)
- [Variadic blocks](/proposals/p002240-variadics.md#variadic-blocks)
- [Keyword syntax](/proposals/p002240-variadics.md#keyword-syntax)
- [Require parentheses around `each`](/proposals/p002240-variadics.md#require-parentheses-around-each)
- [Fused expansion tokens](/proposals/p002240-variadics.md#fused-expansion-tokens)
- [No parameter merging](/proposals/p002240-variadics.md#no-parameter-merging)
- [Exhaustive function call typechecking](/proposals/p002240-variadics.md#exhaustive-function-call-typechecking)
## References
docs/project/design_style_guide.md
+2 -2
View File
@@ -42,7 +42,7 @@ documentation.
- Links to specific sections of a proposal should link to the repository copy
of the proposal file, using the section title or other appropriate link
text. For example,
`[Painting details](/proposals/p0123.md#painting-details)`
`[Painting details](/proposals/p000123-bikeshed-design.md#painting-details)`
## Document structure
@@ -75,7 +75,7 @@ that were considered, along with references to the proposals in which those
designs were discussed. For example:
```md
- [Paint widgets from bottom to top](/proposals/p0123.md#alternatives-considered).
- [Paint widgets from bottom to top](/proposals/p000123-bikeshed-design.md#alternatives-considered).
```
### References
docs/project/evolution.md
+6 -5
View File
@@ -165,7 +165,6 @@ issues for longer discussion:
- When you both have
[approval](/docs/project/code_review.md#approving-the-change) from the
assigned lead and the last blocking issue is addressed, merge!
- If you end up making significant changes when incorporating resolved
issues after the approval from the assigned lead, circle back for a
fresh approval before merging, just like you would with code review.
@@ -201,7 +200,6 @@ issues for longer discussion:
- If there is an open question or a critical blocking issue that needs to get
resolved, move it to its own issue that the PR depends on, and focus the
discussion there.
- The issue should focus on surfacing the important aspects of the
tradeoff represented by the issue or open question, not on advocacy.
@@ -276,8 +274,11 @@ edit both as necessary to ensure they give the best high-level understanding of
the proposal possible.
A proposal PR will include a "P-numbered" _proposal document_,
`proposals/pNNNN.md`, where `NNNN` is the pull request number. This file should
be based on the [proposal template file](/proposals/scripts/template.md).
`proposals/p######-slug.md`, where `######` is the pull request number (padded
to 6 digits) and `slug` is a robust
["slug"-compatible](https://en.wikipedia.org/wiki/Clean_URL#Slug) version of the
title. This file should be based on the
[proposal template file](/proposals/scripts/template.md).
When writing a proposal, try to keep it brief and focused to maximize the
community's engagement in it. Beyond the above structure, try to use
@@ -326,7 +327,7 @@ date, and can easily find out what has changed. For example:
```md
> **TODO:** Document the redeclaration syntax `impl C.(as I)` adopted in
> [p5366](/proposals/p5366.md).
> [#5366](/proposals/p005366-the-name-of-an-impl-in-class-scope.md).
```
See the `docs/design` changes in
docs/project/faq.md
+5 -4
View File
@@ -333,8 +333,9 @@ But deduced parameters aren't the same thing as template parameters. In
particular, deduced parameters are never mentioned at the callsite, so those
square brackets are never part of the expression syntax.
See [Proposal #676: `:!` generic syntax](/proposals/p0676.md) for more
background on how and why we chose our current compile-time parameter syntax.
See [Proposal #676: `:!` generic syntax](/proposals/p000676-generic-syntax.md)
for more background on how and why we chose our current compile-time parameter
syntax.
### Why do variable declarations have to start with `var` or `let`?
@@ -386,8 +387,8 @@ match `42` with the value of the expression `the_answer`, which requires a
variable named `the_answer` to already exist.
The pattern matching proposal details alternative
[shorthand for `auto`](/proposals/p2188.md#shorthand-for-auto) and the tradeoffs
that were considered.
[shorthand for `auto`](/proposals/p002188-pattern-matching-syntax-and-semantics.md#shorthand-for-auto)
and the tradeoffs that were considered.
References:
docs/project/principles/information_accumulation.md
+6 -5
View File
@@ -96,8 +96,9 @@ enclosing class, like in C++.
## Alternatives considered
- Allow information to be used before it is provided
[globally](/proposals/p0875.md#strict-global-consistency),
[within a file](/proposals/p0875.md#context-sensitive-local-consistency), or
[within a top-level declaration](/proposals/p0875.md#top-down-with-minimally-deferred-type-checking).
- [Do not allow inline method bodies to use members before they are declared](/proposals/p0875.md#strict-top-down)
- [Do not allow separate declaration and definition](/proposals/p0875.md#disallow-separate-declaration-and-definition)
[globally](/proposals/p000875-principle-information-accumulation.md#strict-global-consistency),
[within a file](/proposals/p000875-principle-information-accumulation.md#context-sensitive-local-consistency),
or
[within a top-level declaration](/proposals/p000875-principle-information-accumulation.md#top-down-with-minimally-deferred-type-checking).
- [Do not allow inline method bodies to use members before they are declared](/proposals/p000875-principle-information-accumulation.md#strict-top-down)
- [Do not allow separate declaration and definition](/proposals/p000875-principle-information-accumulation.md#disallow-separate-declaration-and-definition)
docs/project/principles/library_apis_only.md
+1 -1
View File
@@ -97,4 +97,4 @@ class definitions.
## Alternatives considered
- [Built-in primitive types](/proposals/p1280.md#built-in-primitive-types)
- [Built-in primitive types](/proposals/p001280-principle-all-apis-are-library-apis.md#built-in-primitive-types)
docs/project/principles/low_context_sensitivity.md
+2 -2
View File
@@ -153,13 +153,13 @@ in Carbon that reflect applications of this principle:
- Carbon doesn't provide an analogy to C++'s
[`using namespace`](https://en.cppreference.com/w/cpp/language/namespace#Using-directives)
or a
["wildcard imports" mechanisms](/proposals/p0107.md#broader-imports-either-all-names-or-arbitrary-code)
["wildcard imports" mechanisms](/proposals/p000107-code-and-name-organization.md#broader-imports-either-all-names-or-arbitrary-code)
that merge the names from one namespace into another. Either would introduce
ambiguity in where a name is coming from, making the code more
context-sensitive.
- Carbon doesn't support large blocks of code
[inside a namespace declaration](/proposals/p0107.md#scoped-namespaces),
[inside a namespace declaration](/proposals/p000107-code-and-name-organization.md#scoped-namespaces),
where the reader would have to search for the beginning of the block to see
what namespace applies.
docs/project/principles/namespace_cleanliness.md
+2 -2
View File
@@ -118,5 +118,5 @@ avoid collisions between the package name `Cpp` and a top-level entity named
## Alternatives considered
- [Have both predeclared identifiers and keywords](/proposals/p4864.md#have-both-predeclared-identifiers-and-keywords)
- [Reserve words with a certain spelling](/proposals/p4864.md#reserve-words-with-a-certain-spelling)
- [Have both predeclared identifiers and keywords](/proposals/p004864-no-predeclared-identifiers-core-is-a-keyword.md#have-both-predeclared-identifiers-and-keywords)
- [Reserve words with a certain spelling](/proposals/p004864-no-predeclared-identifiers-core-is-a-keyword.md#reserve-words-with-a-certain-spelling)
docs/project/principles/one_way.md
+6 -5
View File
@@ -82,18 +82,19 @@ motivation:
- Where C++ allows logical operators to be written with either symbols (for
example, `&&`) or text (for example, `and`), Carbon will only support one
form (in this case, [text](/proposals/p0680.md)).
form (in this case, [text](/proposals/p000680-and-or-not.md)).
- Where C++ allows hexadecimal numeric literals to be either lowercase
(`0xaa`) or uppercase (`0xAA`), and with `x` optionally uppercase as well,
Carbon will only allow the [`0xAA` casing](/proposals/p0143.md).
Carbon will only allow the
[`0xAA` casing](/proposals/p000143-numeric-literals.md).
- Where C++ provides both `struct` and `class` with the only difference is
access control defaults, Carbon will only provide one (`class`, albeit with
default public visibility diverging from C++).
However, sometimes language tools are the primary motivation. For example, where
C++ allows braces to be omitted for single-statement control flow blocks, Carbon
will [require braces](/proposals/p0623.md). This offers a syntax simplification
that should allow for better error detection.
will [require braces](/proposals/p000623-require-braces.md). This offers a
syntax simplification that should allow for better error detection.
## Caveats
@@ -152,4 +153,4 @@ overlapping features without a plan to remove the corresponding legacy version.
## Alternatives considered
- [Provide multiple ways of doing a given thing](/proposals/p0829.md#provide-multiple-ways-of-doing-a-given-thing)
- [Provide multiple ways of doing a given thing](/proposals/p000829-one-way-principle.md#provide-multiple-ways-of-doing-a-given-thing)
docs/project/versioning.md
+1 -1
View File
@@ -267,4 +267,4 @@ and minimizing cache impact.
## Relevant proposal
- [Proposal p4105](/proposals/p4105.md)
- [Proposal #4105](/proposals/p004105-establish-toolchain-and-language-versioning.md)
proposals/README.md
+6 -5
View File
@@ -17,9 +17,10 @@ This directory contains accepted proposals for the carbon-lang repository. For
information about declined/deferred proposals, please view the proposal's
original pull request.
For accepted proposals, where `####` is the corresponding proposal's pull
request:
For accepted proposals, where `######` is the corresponding proposal's pull
request number (padded to 6 digits):
- `p####.md` will contain the main proposal text.
- `p####` may be present as an optional subdirectory for related files (for
example, images).
- `p######-slug.md` will contain the main proposal text, where `slug` is a
robust slugification of the title of the proposal.
- `p######-slug` may be present as an optional subdirectory for related files
(for example, images).
proposals/p0024.md → proposals/p000024-generics-goals.md
View File
proposals/p0029.md → proposals/p000029-linear-rebase-and-pull-request-github-workflow.md
View File
proposals/p0042.md → proposals/p000042-create-code-review-guidelines.md
View File
proposals/p0044.md → proposals/p000044-proposal-tracking.md
View File
proposals/p0051.md → proposals/p000051-goals.md
View File
proposals/p0063.md → proposals/p000063-criteria-for-carbon-to-go-public.md
View File
proposals/p0074.md → proposals/p000074-change-comment-decision-timelines-in-proposal-process.md
View File
proposals/p0083.md → proposals/p000083-in-progress-design-overview.md
View File
proposals/p0107.md → proposals/p000107-code-and-name-organization.md
View File
proposals/p0113.md → proposals/p000113-add-a-c-style-guide.md
View File
proposals/p0120.md → proposals/p000120-add-idiomatic-code-performance-and-developer-facing-docs-to-goals.md
View File
proposals/p0140.md → proposals/p000140-create-initial-rough-framework-for-specification.md
View File
proposals/p0142.md → proposals/p000142-unicode-source-files.md
View File
proposals/p0143.md → proposals/p000143-numeric-literals.md
View File
proposals/p0144.md → proposals/p000144-numeric-literal-semantics.md
View File
proposals/p0149.md → proposals/p000149-change-documentation-style-guide.md
View File
proposals/p0157.md → proposals/p000157-design-direction-for-sum-types.md
+4 -3
View File
@@ -229,8 +229,9 @@ supply the missing functionality identified above. These features are largely
separable, although there are some dependencies between them, so their detailed
design will be addressed in future proposals, and the details discussed here
should be considered provisional. This proposal merely establishes the overall
design direction for sum types, in the same way that [#83](p0083.md) established
the overall design direction for the language as a whole.
design direction for sum types, in the same way that
[#83](p000083-in-progress-design-overview.md) established the overall design
direction for the language as a whole.
To support manual lifetime control and storage sharing, I propose introducing at
least one and preferably both of the following:
@@ -1012,7 +1013,7 @@ This ensures that a sum type's API is defined using essentially the same syntax,
regardless of how the type author chooses to implement it.
This approach is described in much more detail in an
[earlier draft](https://github.com/carbon-language/carbon-lang/blob/4dbd31d71e02895892f97a211df4b5fff8cae5c3/proposals/p0157.md)
[earlier draft](https://github.com/carbon-language/carbon-lang/blob/4dbd31d71e02895892f97a211df4b5fff8cae5c3/proposals/p000157-design-direction-for-sum-types.md)
of this document, where it was the primary proposal. It has a number of
advantages over the primary proposal:
proposals/p0162.md → proposals/p000162-basic-syntax.md
+5 -5
View File
@@ -528,11 +528,11 @@ proposal stage, which will help us avoid wasting time and effort implementing
designs that turn out to be unworkable.
This can be considered as sort of a counterpart to
[In-progress design overview #83](p0083.md), in that the design specifics are
being approved in order to bootstrap the specification process. We aren't
necessarily adopting the specific syntax and semantics expressed by this
proposal, and those choices will need to be presented and justified from scratch
by future proposals.
[In-progress design overview #83](p000083-in-progress-design-overview.md), in
that the design specifics are being approved in order to bootstrap the
specification process. We aren't necessarily adopting the specific syntax and
semantics expressed by this proposal, and those choices will need to be
presented and justified from scratch by future proposals.
This decision is deferring the implementation to code review. The specific
tooling used to implement the syntax checker, such as Bison, is a detail which
proposals/p0175.md → proposals/p000175-c-interoperability-goals.md
View File
proposals/p0179.md → proposals/p000179-create-a-toolchain-team.md
View File
proposals/p0196.md → proposals/p000196-language-level-safety-strategy.md
View File
proposals/p0198.md → proposals/p000198-comments.md
View File
proposals/p0199.md → proposals/p000199-string-literals.md
View File
proposals/p0253.md → proposals/p000253-2021-roadmap.md
View File
proposals/p0257.md → proposals/p000257-initialization-of-memory-and-variables.md
View File
proposals/p0285.md → proposals/p000285-if-else.md
View File
proposals/p0301.md → proposals/p000301-principle-errors-are-values.md
View File
proposals/p0339.md → proposals/p000339-var-statement.md
+2 -2
View File
@@ -221,8 +221,8 @@ something like `let mut` in Rust. However, this is not assumed by this proposal:
appropriately
[focuses on encouraging appropriate usage of features rather than restricting misuse](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write)).
- Lower verbosity syntax for variables is more
[consistent with C++](p0285.md#c-as-baseline), even if constants are made
less verbose by way of `let`.
[consistent with C++](p000285-if-else.md#c-as-baseline), even if constants
are made less verbose by way of `let`.
### Multiple identifiers in one statement
proposals/p0340.md → proposals/p000340-while-loops.md
View File
proposals/p0353.md → proposals/p000353-for-loops.md
View File
proposals/p0415.md → proposals/p000415-syntax-return.md
View File
proposals/p0426.md → proposals/p000426-governance-evolution-revamp.md
View File
proposals/p0438.md → proposals/p000438-functions.md
View File
proposals/p0444.md → proposals/p000444-github-discussions.md
View File
proposals/p0447.md → proposals/p000447-generics-terminology.md
View File
proposals/p0524.md → proposals/p000524-generics-overview.md
View File
proposals/p0538.md → proposals/p000538-return-with-no-argument.md
View File
proposals/p0540.md → proposals/p000540-remove-void.md
View File
proposals/p0553.md → proposals/p000553-generics-details-part-1.md
View File
proposals/p0555.md → proposals/p000555-operator-precedence.md
+4 -4
View File
@@ -96,7 +96,7 @@ left-to-right arrow meaning a left-associative operator.
For example:
<div align="center">
<img src="p0555/example.svg" alt="Example operator precedence diagram">
<img src="p000555-operator-precedence/example.svg" alt="Example operator precedence diagram">
</div>
... would depict a higher-precedence `*` operator and a lower-precedence `+`
@@ -111,8 +111,8 @@ With those precedence rules:
- `a + b << c` would be an error, requiring parentheses, because the
precedence levels of `+` and `<<` are unordered.
A [python script](p0555/figures.py) to generate these diagrams is included with
this proposal.
A [python script](p000555-operator-precedence/figures.py) to generate these
diagrams is included with this proposal.
### When to add precedence edges
@@ -228,7 +228,7 @@ this ambiguity by excluding `primary_expression` from `add_expression` and
systematically for any precedence partial ordering.
A complete example of a yacc parser with operator precedence partial ordering is
available [alongside this proposal](p0555/yacc-parser).
available [alongside this proposal](p000555-operator-precedence/yacc-parser).
## Rationale based on Carbon's goals
proposals/p0555/example.svg → proposals/p000555-operator-precedence/example.svg
View File
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

proposals/p0555/figures.py → proposals/p000555-operator-precedence/figures.py
View File
proposals/p0555/yacc-parser/Makefile → proposals/p000555-operator-precedence/yacc-parser/Makefile
View File
proposals/p0555/yacc-parser/example.l → proposals/p000555-operator-precedence/yacc-parser/example.l
View File
proposals/p0555/yacc-parser/example.y → proposals/p000555-operator-precedence/yacc-parser/example.y
View File
proposals/p0561.md → proposals/p000561-basic-classes-use-cases-struct-literals-struct-types-and-future-work.md
View File
proposals/p0601.md → proposals/p000601-operator-tokens.md
View File
proposals/p0618.md → proposals/p000618-var-ordering.md
View File
proposals/p0623.md → proposals/p000623-require-braces.md
+3 -2
View File
@@ -36,8 +36,9 @@ for (Shape x : shapes)
```
Carbon adopted this design choice by default in proposals
[#285](/proposals/p0285.md), [#340](/proposals/p0340.md), and
[#353](/proposals/p0353.md). But should we keep it?
[#285](/proposals/p000285-if-else.md),
[#340](/proposals/p000340-while-loops.md), and
[#353](/proposals/p000353-for-loops.md). But should we keep it?
## Background
proposals/p0646.md → proposals/p000646-low-context-sensitivity-principle.md
View File
proposals/p0676.md → proposals/p000676-generic-syntax.md
View File

Some files were not shown because too many files have changed in this diff Show More