This follows #1274 , #1325 , #1328 , #1336 , and #1347 . This has miscellaneous changes to the design overview without a particular focus.
Also adds some missing keywords to our list of keywords.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
This is a proposal to make the Carbon experiment public.
We have not yet hit many of the originally suggested criteria for going
public. However, this proposal suggests that increasingly there is more
value to moving public sooner rather than waiting to hit these criteria.
We are increasingly unable to substantially learn more about the broader
interest in Carbon without it being public and we increasingly see value
in working with the industry to build and shape the language.
Given this, the proposal removes the old plan-of-record and suggests
a concrete set of steps to make the experiment public in the immediate
future.
This is not a change that we can make lightly to the project, and so we
worked to check with as many folks as we could first and all three
leads were unanimous to move forward here.
Note that this proposal was originally discussed in PR #1315.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This proposal establishes a plan for moving away from the embedded copy
of LLVM and instead downloading it with Bazel.
The goal is that after this lands, we will do a history-rewrite to
cleanup the repository. There are instructions on how folks can move any
in-flight work over to the newly tidied repo.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
This follows #1274 , #1325 , and #1328 . It fills in the "Bidirectional interoperability with C and C++" section.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Geoff Romer <gromer@google.com>
This follows #1274 and #1325 and fills in the "safety" section. It only covers our approach in general terms.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This follows #1274 . It mainly fills in the "generics" section, with smaller updates to other section.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Prior to this change, the section headings for the 7 main goals are visually indistinguishable (in GitHub's rendering) from the boldfaced paragraph headings in those sections. This makes the doc hard to navigate because the structure is hidden.
Reorganizes the sections, and makes a pass filling in and updating the first sections including: types, functions, user-defined types. The following sections are left for part 2, including names, generics, and interop.
Also some smaller updates to, not revisiting the text: `pattern_matching.md`, `control_flow/return.md`, and `lexical_conventions/numeric_literals.md`
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Some review feedback from outside the team directly working on Carbon suggested
two pretty significant updates here. First, we didn't do a good job of
motivating Carbon. This takes two parts, first explaining what we'd like to
accomplish with this approach generally, and second explaining why alternative
approaches don't work. A particularly difficult case here is articulating
effectively the difficulties that motivate an approach other than improving C++
incrementally.
Co-authored-by: Jon Meow <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
This proposal:
- Adds support for interfaces requiring other types than `Self` to implement interfaces, as in:
```
interface IntLike {
impl i32 as As(Self);
// ...
}
```
- Defines requirements on how to satisfy those requirements that have a `where` clause.
- Extends `observe` declarations to include saying a type implements an interface, so code can provide a proof instead of the compiler having to perform a recursive search.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
A rephrasing was suggested on https://github.com/carbon-language/carbon-lang/pull/1188#discussion_r851416370 because "explorer" alone could be hard to parse; I'm suggesting just replacing with "Carbon explorer" to get precision without changing phrasing, as well as rephrasing "Executable semantic" as "Carbon explorer" (which... the former *may* have meant "executable semantics", but the difference in pluralization made it vague, so I'm not sure this is right -- but it also didn't explain _where_, so "executable semantics" seems the right reading)
Co-authored-by: Geoff Romer <gromer@google.com>
Encourage reviewers to merge when they feel okay doing so. Let reviewers make
that choice. Let authors say they'll merge themselves.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Add concrete design for interfaces for comparison.
Rename interfaces for arithmetic following current thinking in #1058.
Update rules for mixed-type comparisons for data classes following #710.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Right now, the text is disallowing appeals to logic (which are persuasive methods, per the linked wikipedia article). Consensus seems to be that this is unintentional.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This proposal has three main contributions:
- Types with generic parameters have an identity that consists of the types names plus the values of those parameters.
- The parameters of a type may be deduced from a function's argument.
- Types with generic parameters do not support specialization. Instead, a type can delegate to an interface to opt in to allowing specific customization points.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Given repeated concerns about C++ interop priorities: taking a pass at being more direct about priorities and tradeoffs.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Allow interfaces and implementations to be forward declared.
```
// Forward declare interface `F`
interface F;
class C {
// Forward declare `C` implements `F`
impl as F;
}
// Definitions corresponding to forward declarations
interface F { ... }
impl C as F { ... }
```
To allow members of interfaces with default definitions to be forward declared, prefix them with the keyword `default`, following #1082.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Operators rewrite to calls of specific operator interface functions, so you overload an operator for a type by implementing an interface for it. There is a `like` operator for defining a set if implementations for supporting implicit conversions more conveniently.
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Add support for arithmetic operators:
- Unary `+`.
- Binary `+`, `-`, `*`, `/`, `%`.
Specify their behavior for integer and floating-point types. Signed integer overflow is a programming error, handled in various ways. Unsigned integer overflow is specified as wrapping around, intended for hashing / crypto / PRNG use cases.
Co-authored-by: jonmeow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Provide an initial rough structure for the specification so we can add things
as they are decided.
Split the specification into a language and a library section. In the language
section, use one file per broad area of functionality. Divide the language up
based on the intended layering of the language design.
Jon Ross-Perkins
Ryan Russell
Matt Godbolt
Laurent Le Brun
