Update broken links to aid in following links while perusing the
documentation. Closes#3778
I don't imagine I got every one of these right. Some 404s may be
reported due to permissions.
Using the lychee command in #3778, only the following link is reported
as not found, but it's just a permission issue:
```
[proposals/p1367.md]:
✗ [404] https://github.com/carbon-language/carbon-lang/settings/access | Failed: Network error: Not Found
```
I tried to get it down to as few as possible, partially so that future
link scans won't run into repeat errors.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
Improve the exposition of the design changes from #3646 to integrate
better into the overall description of member access design.
This fixes the incorrect description of the rules for `->` by instead
relying on the general rule that `->` is rewritten to use `*` and `.`
before any other processing is done, and generally makes
*integer-literal* names be less of a special case.
Add support for extracting elements of a tuple by their numerical index.
Also formally add the well-established basic syntactic and semantic
rules for
tuples, for which we have had leads issues but no proposal, into the
design.
The version of `flake8` was too old to support with Python 3.12 -- there
is new F-string support that caused false positives sadly. The updated
version has fixes for all of these.
This in turn updates codespell which has picked up several new fixes
that actually fire in our code, so also fix everything. While we don't
do more in-depth updates to old proposals, similar to simply fixing
broken links, fixing automatically detected typos seems scalable and
fine.
All edits were automatically generated here.
- Require namespace members be declared in the same name scope as the
namespace is declared.
- Allow binding patterns to directly declare names in namespaces.
- Disallow using different namespaces in the same binding pattern.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
When there is no `package` directive, default to `Main//default api`
instead of
`Main//default impl`. This means:
- The extension will be `.carbon`, not `.impl.carbon`.
- There can only be one such file when compiling.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Continued from part 1: #3231. Second step updating
`docs/design/generics/details.md`. There remains some work to
incorporate proposal #2200.
- The biggest changes are incorporating much of the text of proposals:
- #2173
- #2687
- It incorporates changes from proposals:
- #989
- #1178
- #2138
- #2200
- #2360
- #2964
- #3162
- It also updates the text to reflect the latest thinking from leads
issues:
- #996
- #2153 -- most notably deleting the section on `TypeId`.
- Update to rule for prioritization blocks with mixed type structures
from [discussion on
2023-07-18](https://docs.google.com/document/d/1gnJBTfY81fZYvI_QXjwKk1uQHYBNHGqRLI2BS_cYYNQ/edit?resourcekey=0-ql1Q1WvTcDvhycf8LbA9DQ#heading=h.7jxges9ojgy3)
- Adds reference links to proposals, issues, and discussions relevant to
the text.
- Also tries to use more precise language when talking about
implementations, to avoid confusing `impl` declaration and definitions
with the `impls` operator used in `where` clauses, an issue brought up
in
- #2495
- #2483
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Includes proposals:
- #990
- #2188
- #2138
- #2200
- #2360
- #2760
- #2964
- #3162
Also tries to use more precise language when talking about:
- implementations, to avoid confusing `impl` declaration and definitions
with the `impls` operator used in `where` clauses, an issue brought up
in #2495 and #2483;
- "binding patterns", like `x: i32`, and "bindings" like `x`.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
First step in updating `docs/design/generics/details.md`. It
incorporates changes from proposals: #989#2138#2173#2200#2360#2964#3162 , but there are still more changes from those proposals to be
made.
It also switches away from suggesting static-dispatch witness tables,
and creates an appendix to describe that decision.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Change terminology away from terms that are ambiguous:
- Reserve "generic type" for types with (compile-time) parameters, like
`Vector` in `Vector(T:! type)`. Don't use that term to refer to `T`, as
it would with
[#2360](https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p2360.md#terminology).
- Use the term "compile-time" instead of "constant" to mean "template or
symbolic." Expand the term "constant" to include values, such as from
`let` bindings.
The semicolon is part of the statement's syntax, and including it will
hopefully help clarify that we're not using `var` as a placeholder and
talking about `return` _variablename_ `;`.
This reflects changes from a number of approved proposals:
- #2138 : "generic" -> "checked generic", "template" -> "template
generic"
- #2360 : "type", "facet type", "facet". Note: I am not using the term
"generic type" from #2360 since that meaning conflicts with the
generally accepted meaning of "generic type" of a type with a
compile-time parameter.
- #2760 / #2770 : internal/external impl -> extending impl
- #2964 : "symbolic constant" and "template constant"
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Also indicate what can appear within parentheses.
This is intended to be a clarification, not a design change. Note that
while we previously described the operand of `++` or `--` as being
simply an expression, the operand can never be anything other than the
kinds of expression the diagram now shows due to the expression category
rules added in #2006.
Fixes#3079.
Currently, they are marked as left-associative which isn't completely
obvious for unary operators and wouldn't match the fact that we have
both prefix and postfix unary operators we intend to allow to repeat
without parentheses: `***x` and `T***`.
This fixes the graph by making the left-associative marker only for
binary operators, and using a separate marker for repeating unary
operators: a diamond.
It also adds a note that Carbon currently only has left-associativity
because the right-associative operators like assignment are statements
in Carbon.
This isn't intended ta be a change of anything in Carbon's design, just
an improvement to the documentation.
Introduce a concrete design for how Carbon values, objects, storage,
variables,
and pointers will work. This includes fleshing out the design for:
- The expression categories used in Carbon to represent values and
objects,
how they interact, and terminology that anchors on their expression
nature.
- An expression category model for readonly, abstract values that can
efficiently support function inputs.
- A customization system for value expression representations,
especially as
seen on function boundaries in the calling convention.
- An expression category model for references instead of a type system
model.
- How patterns match different expression categories.
- How initialization works in conjunction with function returns.
- Specific pointer syntax, semantics, and library customization
mechanisms.
- A `const` type qualifier for use when the value expression category
system
is too abstracted from the underlying objects in storage.
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Adrien Leravat <Pixep@users.noreply.github.com>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This reflects changes from a number of approved proposals:
- #920 : concrete statements about orphan and overlap in Carbon
- #2138 : "generic" -> "checked generic", "template" -> "template
generic"
- #2188 : binding patterns are forbidden in type position
- #2360 : "type", "facet type", "facet". Note: I am not using the term
"generic type" from #2360 since that meaning conflicts with the
generally accepted meaning of "generic type" of a type with a
compile-time parameter.
- #2760 / #2770 : internal/external impl -> extending impl
- #2964 : "symbolic constant" and "template constant"
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Make the preamble of simple programs more ergonomic, by removing the
`package Main` from the main package and removing the `package`
declaration
entirely from the main source file. Imports within a single package no
longer
need to, and are not permitted to, specify the package name.
Partially covers #2001 / #1136.
Covers #1869.
Supersedes #2265.
Addresses design idea #2323.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Updated string_literals.md to mitigate confusion around newline behavior
in the context of block string literals.
Addresses #2887
---------
Co-authored-by: jonmeow <jperkins@google.com>
This includes:
- Syntax changes from this chart:
| Before | After |
| ------------------------------- | --------------------------------------- |
| `class D extends B { ... }` | `class D { extend base: B; ... }` |
| `external impl C as Sub;` | `impl C as Sub;` |
| `class C { impl as Sortable; }` | `class C { extend impl as Sortable; }` |
| `adapter A for C { ... }` | `class A { adapt C; ... }` |
| `adapter A extends C { ... }` | `class A { extend adapt C; ... }` |
| `interface I { impl as J; }` | `interface I { require Self impls J; }` |
| `interface I { extends J; }` | `interface I { extend J; }` |
- Dropping the syntax for conditionally implemented internal interfaces.
This does not include:
- terminology changes from #2760 ("internal" and "external")
- changes to code, such as explorer, toolchain, language grammars, or other tooling
Allow an `impl` to overlap with a `final impl` if they agree on the overlap. Agreement is defined as all values comparing equal, and functions never comparing equal. Implements the decision in question-for-leads issue #1077.
Use the keyword `impls` instead of `is` when writing a `where` constraint that a type variable needs to implement an interface or named constraint.
What was previously (provisionally) written:
```
fn Sort[T:! Container where .ElementType is Ordered](x: T*);
```
will now be written:
```
fn Sort[T:! Container where .ElementType impls Ordered](x: T*);
```
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This tries to make it clearer that user code is responsible for ignoring observable differences between the possible behaviors, and uses "alias" instead of "pointer" to describe the reference-like option. It also avoids taking a stance on how we address the possibility of the original value being mutated after it is aliased.
Statements, declarations, and definitions will terminate with either a semicolon
(`;`) or a close curly brace (`}`). Semicolons are never optional.
For example, with a semicolon, `x = x + 2;`. With a close curly brace,
`for ( ... ) { ... }`, or `class C { ...}`.
This does not affect any approved proposal; rather, it makes an important
assumption explicit.
Based on lead decision #1924Fixes#2002
### Greater symbol issue in doc file of comparison_operators
In doc, symbol of greater or greater than equal is write but word is miswritten
so i just fix the word which is miswritten.
**### There is issue in conditionals.md readme file**
**In example of fruits conditionals**
**there are fruits.IsGreen() if it is False then continue.
if it is True then print "Apple" but in readme file there is "Orange"**
I replaced "Orange" with "Apple" because in example there is "Apple"
```carbon
if (fruit.IsYellow()) {
Print("Banana!");
} else if (fruit.IsOrange()) {
Print("Orange!");
} else if (fruit.IsGreen()) {
Print("Apple!");
} else {
Print("Vegetable!");
}
fruit.Eat();
```
cui fliter
Richard Smith
Chandler Carruth
Geoff Romer
josh11b
mx42andjosh11b
T.J. Givenandjonmeow
Aswin ShailajanandAvi Aaron
Aadarsh Raj
Amr Hesham