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.
2.4 KiB
Functions
Table of contents
TODO
This is a skeletal design, added to support the overview. 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.
Basic functions
Programs written in Carbon, much like those written in other languages, are primarily divided up into "functions" (or "procedures", "subroutines", or "subprograms"). These are the core unit of behavior for the programming language. Let's look at a simple example to understand how these work:
fn Sum(Int: a, Int: b) -> Int;
This declares a function called Sum which accepts two Int parameters, the
first called a and the second called b, and returns an Int result. C++
might declare the same thing:
std::int64_t Sum(std::int64_t a, std::int64_t b);
// Or with trailing return type syntax:
auto Sum(std::int64_t a, std::int64_t b) -> std::int64_t;
Let's look at how some specific parts of this work. The function declaration is
introduced with a keyword fn followed by the name of the function Sum. This
declares that name in the surrounding scope and opens up a new scope for this
function. We declare the first parameter as Int: a. The Int part is an
expression (here referring to a constant) that computes the type of the
parameter. The : marks the end of the type expression and introduces the
identifier for the parameter, a. The parameter names are introduced into the
function's scope and can be referenced immediately after they are introduced.
The return type is indicated with -> Int, where again Int is just an
expression computing the desired type. The return type can be completely omitted
in the case of functions which do not return a value.
Calling functions involves a new form of expression: Sum(1, 2) for example.
The first part, Sum, is an expression referring to the name of the function.
The second part, (1, 2) is a parenthesized list of arguments to the function.
The juxtaposition of one expression with parentheses forms the core of a call
expression, similar to a postfix operator.