mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-30 22:02:41 +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.
64 lines
2.4 KiB
Markdown
64 lines
2.4 KiB
Markdown
# Functions
|
|
|
|
<!--
|
|
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)
|
|
- [Basic functions](#basic-functions)
|
|
|
|
<!-- 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.
|
|
|
|
## 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.
|