Carbon has functions. We should write down how those functions indicate their code should stop running and, if applicable, what result should be provided back to their caller.
The Carbon overview contains a "skeletal
design" for return.
Carbon aims for
familiarity for experienced C++ developers with a gentle learning curve.
C++ returns from functions with a return statement, which is documented well
here.
Carbon will have a return statement that is unsurprising to C++ programmers.
Each of these is a valid Carbon function:
// A function that returns no value
fn NoReturn() {
// This function intentionally left blank
}
// A function that returns no value in a different way
fn ReturnNoValue() {
// Usually no expression in a function with no return value.
return;
}
// A function that returns a value
fn ReturnFive() -> Int {
// Must include an expression "convertible" to `Int`.
// The (lack of) definition for "convertible" is addressed later.
return 5;
}
We define a return statement in Carbon. It can occur any place a statement is
allowed. It takes one optional expression, the return value. Functions may
contain multiple return statements.
A function that returns Void may have return statements. Most will have no
return value, though some may provide a Void-type expression, for example the
result of another Void-returning function.
This last affordance is provided to avoid making
Voida special case in templating.
Functions returning Void are also defined to end with an implicit return
statement.
This implicit
returnis intended to make it easier for later designs to refer to "the (now always present)returnstatement" rather than the less well-defined "the point the function returns".
A function that returns anything other than Void must have at least one
return statement. All return statements in the function must provide an
expression "convertible" to the function's return type. If a control flow path
reaches the end of the function without executing a return statement, it is a
compile error.
This proposal is limited to the syntax and simple static semantics of the
return statement.
Some questions about the full validity and meaning of a return statement in
context are left unresolved, in the expectation they will be addressed when
adjacent parts of the language are specified.
Those include:
-
What does "convertible" mean?
When a function returns a value, we say the
returnstatement takes an expression "convertible" to the function's return type. As a coarse approximation, this may mean "assignable to a variable of the function's return type", but there are likely to be subtleties. We assume this question will be addressed as the type system develops. -
What optimizations are encouraged or guaranteed for return values?
C++ has copy elision and it's a good bet Carbon will too. But first we need to decide what copying means.
-
What code, if any, runs between
returnand returning?Carbon is likely to have approaches for deterministic cleanup that trigger when a function's code stops executing -- analogues to C++ destructors, Golang deferred functions, or Java's
finallyblocks. Once we know what they are and how we intend them to work, we can determine how to slot them in next toreturn.
Some C-family languages allow an unadorned expression in the right context to serve as a return value.
In Rust, for example, function bodies are block expressions, which may have an expression as their final clause and which take the value of that expression.
This Rust function returns 5:
fn return_five() -> i32 {
perhaps_unrelated_action();
5
}Rust still has a return statement, so this is entirely an ergonomic feature.
We can choose to add a similar feature to Carbon in the future as long as we can unambiguously discern expressions and statements in parsing.