mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-29 15:34:58 +01:00
Jon Meow
d031f3cdab
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.
81 lines
2.4 KiB
Markdown
81 lines
2.4 KiB
Markdown
# Control flow
|
|
|
|
<!--
|
|
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
|
Exceptions. See /LICENSE for license information.
|
|
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
-->
|
|
|
|
## Table of contents
|
|
|
|
<!-- toc -->
|
|
|
|
- [TODO](#todo)
|
|
- [Overview](#overview)
|
|
- [Open questions](#open-questions)
|
|
- [`if` blocks](#if-blocks)
|
|
- [`break` and `continue`](#break-and-continue)
|
|
|
|
<!-- tocstop -->
|
|
|
|
## TODO
|
|
|
|
This is a skeletal design, added to support [the overview](README.md). It should
|
|
not be treated as accepted by the core team; rather, it is a placeholder until
|
|
we have more time to examine this detail. Please feel welcome to rewrite and
|
|
update as appropriate.
|
|
|
|
At least summarize `if` and `else` to cover basics. Especially important to
|
|
surface the idea of using basic conditionals as both expressions and statements
|
|
to avoid needing conditional operators.
|
|
|
|
Looping is an especially interesting topic to explore as there are lots of
|
|
challenges posed by the C++ loop structure. Even C++ itself has been seeing
|
|
significant interest and pressure to improve its looping facilities.
|
|
|
|
## Overview
|
|
|
|
Blocks of statements are generally executed linearly. However, statements are
|
|
the primary place where this flow of execution can be controlled. Carbon's
|
|
control flow constructs are mostly similar to those in C, C++, and other
|
|
languages.
|
|
|
|
```
|
|
fn Foo(Int: x) {
|
|
if (x < 42) {
|
|
Bar();
|
|
} else if (x > 77) {
|
|
Baz();
|
|
}
|
|
}
|
|
```
|
|
|
|
Loops will at least be supported with a low-level primitive `while` statement,
|
|
with `break` and `continue` statements which work the same as in C++.
|
|
|
|
Last but not least, for the basics we need to include the `return` statement.
|
|
This statement ends the flow of execution within a function, returning it to the
|
|
caller. If the function returns a value to the caller, that value is provided by
|
|
an expression in the return statement. This allows us to complete the definition
|
|
of our `Sum` function from earlier as:
|
|
|
|
```
|
|
fn Sum(Int: a, Int: b) -> Int {
|
|
return a + b;
|
|
}
|
|
```
|
|
|
|
## Open questions
|
|
|
|
### `if` blocks
|
|
|
|
It is an open question whether a block is required or a single statement may be
|
|
nested in an `if` statement. Similarly, it is an open question whether `else if`
|
|
is a single keyword versus a nested `if` statement, and if it is a single
|
|
construct whether it should be spelled `elif` or something else.
|
|
|
|
### `break` and `continue`
|
|
|
|
If and how to support a "labeled break" or "labeled continue" is still a point
|
|
of open discussion.
|