A few changes:
- Merge content from the `primitive_types.md` design doc into the overall design `README.md` since there was so much overlap and no need for two copies.
- Consistently spell integer types `Carbon.Int(N)` and `Carbon.UInt(N)`, including the `Carbon.` prefix and avoiding `Unsigned(N)`.
- Consistently use a comprehensive set of floating-point types.
- Incorporates #2015 into the design docs.
Previous overview is changed to an introduction that includes a modified first example, and adding a brief tour of Carbon in the form of an explanation of the features demonstrated in that example. Also update to reflect that we expect `Print` to be available in some package imported by default, which we are currently calling `Carbon`.
Co-authored-by: Wolff Dobson <wolffg@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Also references were added to clarify that some features are not provisional.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Geoff Romer <gromer@google.com>
The original sentence was grammatically unsound, specified the three options of copy, move or pointer binding in parenthesis and some words around it.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Fix `-` -> `+` in `Distance`. Typo noticed by gingerBill in https://www.youtube.com/watch?v=Z_8lV0nwsc4 .
Also update factory function names `Create` -> `Make`, to reflect latest thinking.
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 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>
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>
I was doing this for #851 initially, but I think #438 and #826 hadn't made it in (possibly intentionally due to #851? I don't recall).
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Add support for nominal (or "named") classes with encapsulation. Inheritance will be in a later proposal. Here is an example of the proposed syntax:
```
class Circle {
fn Create(c: Point, r: f32) -> Self {
return {.center = c, .radius = r};
}
fn Diameter[me: Self]() -> f32 {
return me.radius * 2;
}
fn Expand[addr me: Self*](distance: f32);
private var center: Point;
private var radius: f32;
}
fn Circle.Expand[addr me: Self*](distance: f32) {
me->radius += distance;
}
```
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This proposal defines the very basics of `class` types, primarily focused on:
- use cases including: data classes, encapsulated types, inheritance with and without `virtual`, interfaces as base classes, and mixins for code reuse;
- anonymous data types for called _structural data classes_ or _struct types_. Struct literals are used to initialize class values and ad-hoc parameter and return types with named components; and
- future work, including the provisional syntax already in use for features that have not been decided.
The intent is to both make some small incremental progress and get agreement on direction. As such it doesn't include things like nominal types, methods, access control, inheritance, etc.
It proposes this struct type and literal syntax:
```
var p: {.x: Int, .y: Int} = {.x = 0, .y = 1};
```
Note that it uses commas (`,`) between fields instead of semicolons (`;`), and no introducer for types or literal values.
Incorporates decisions from #665 , #653 , #651
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Expand the description of the structure of a proposal PR. Clarify that
the full PR is the proposal, not only the P-numbered document. Start a
design style guide and use it to describe which parts of a proposal
should not end up in the design.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Propose the decision from #542, noting implementation from #563
Also integrates some of #339 into `variables.md` because that's actually how this started, looking for a proposal reference for #542
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
One implication here is that both proposals/README.md and the website should use basically the same format for their proposal lists. Another subtle change is that the website sidebar was previously sorted by *filename*, and is now sorted by *title*, which seems better because it's something that readers can see.
Enumerating why files change:
- gen_sidebar.py is the centerpiece, with a couple helpful functions for re-use elsewhere
- Delete the old sidebar html includes
- Modify the Makefile to handle gen_sidebar.py reasonably well (let's be honest... I'm not great at Makefiles)
- Move proposal listing out to its own file (proposals.py) for re-use
- Add a few PYTHONPATH things + `__init__.py` files to get modules importing correctly (may be a better way at this, I've hit a wall though).
Adopts new copyright and markdown toc checks.
The new toc check generates the toc header, so that's why all the md files changed (this had felt better to me for the long-term, more auto-generated content)
Co-authored by: chandlerc
- Based on [PR 22](https://github.com/carbon-language/carbon-lang/pull/83)
- [Idea topic](https://forums.carbon-lang.dev/t/proposal-for-an-incomplete-rough-high-level-overview-ready-for-early-feedback/52)
- [RFC](https://forums.carbon-lang.dev/t/rfc-an-incomplete-early-and-in-progress-overview-of-the-language-design/73)
- [Decision announcement](https://forums.carbon-lang.dev/t/accepted-an-incomplete-early-and-in-progress-overview-of-the-language-design/110)
This proposal should be considered a starting point of the language design. It's not intended to be final; language details may change. This is intended to offer a reasonable starting point for:
- Example code.
- Conceptualizing Carbon at a high level.
- Reasonable, but not necessarily final, approaches to features in README.md.
- If any idea is obviously bad, we can clean it up here.
This proposal is not intended to achieve:
- A whole language design.
- This is way too much work for a single proposal; this is a skeletal framework only.
- As we work on feature-specific designs, we may decide to use other approaches. That's fine: we only need somewhere to start.
- The summaries in README.md may be expected to change over time.
- Feature-specific files aren't intended to be well-written or comprehensive. They are a quick jot of prior thoughts.
- We want to avoid getting stuck on language details that we should consider
more carefully regardless. If you're passionate about a feature, please feel
free to start a new proposal for it.
- Each and every aspect of the suggested overview should be subject to careful
examination and justification before it becomes a settled plan of record.
Chandler started this with https://github.com/carbon-language/carbon-lang/pull/22. I've taken it over with the following changes:
- More of a directory hierarchy.
- Trying to thin out the main file (now README.md) to lighter summaries of features.
- Details/rationale/alternatives should be in feature-specific files.
- Draft files are linked as references where added.
For an example of how we may proceed with feature-specific designs, see https://github.com/carbon-language/carbon-lang/pull/80. In this structure:
- docs/design/README.md mentions interoperability, with a light overview.
- The light overview is not yet in https://github.com/carbon-language/carbon-lang/pull/80.
- docs/design/interoperability/README.md goes into more depth on interoperability, covering key points of the approach.
- Individual files in docs/design/interoperability/* go into more depth on interoperability.
Simple designs may not have a subdirectory. All current feature-specific designs do not -- they may be moved later.
Jon Ross-Perkins
Geoff Romer
Prithvi Jamadagni
Shakeel MahateandJon Ross-Perkins
Josh Soref
Arno Gourdol
Ryan Russell
Jon Meow
