From a33d6eca6d7087b8863ff425a9f5465068aaa191 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 7 Apr 2021 14:02:56 -0700 Subject: [PATCH 01/23] Filling out template with PR 438 --- proposals/README.md | 1 + proposals/p0438.md | 44 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+) create mode 100644 proposals/p0438.md diff --git a/proposals/README.md b/proposals/README.md index 9ab09c21dd6a3..79dc77920d24d 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -66,5 +66,6 @@ request: - [0253 - 2021 Roadmap](p0253.md) - [0253 - Decision](p0253_decision.md) - [0285 - if/else](p0285.md) +- [0438 - functions](p0438.md) diff --git a/proposals/p0438.md b/proposals/p0438.md new file mode 100644 index 0000000000000..d4e6e209b5ae9 --- /dev/null +++ b/proposals/p0438.md @@ -0,0 +1,44 @@ +# functions + + + +[Pull request](https://github.com/carbon-language/carbon-lang/pull/438) + + + +## Table of contents + +- [Problem](#problem) +- [Background](#background) +- [Proposal](#proposal) +- [Details](#details) +- [Alternatives considered](#alternatives-considered) + + + +## Problem + +TODO: What problem are you trying to solve? How important is that problem? Who +is impacted by it? + +## Background + +TODO: Is there any background that readers should consider to fully understand +this problem and your approach to solving it? + +## Proposal + +TODO: Briefly and at a high level, how do you propose to solve the problem? Why +will that in fact solve it? + +## Details + +TODO: Fully explain the details of the proposed solution. + +## Alternatives considered + +TODO: What alternative solutions have you considered? From 7d81f97ab4e3993f91cbfd6328e44166e654e6e1 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 7 Apr 2021 15:36:22 -0700 Subject: [PATCH 02/23] Draft --- proposals/README.md | 2 +- proposals/p0438.md | 372 ++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 362 insertions(+), 12 deletions(-) diff --git a/proposals/README.md b/proposals/README.md index 79dc77920d24d..76e8646ecb70b 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -66,6 +66,6 @@ request: - [0253 - 2021 Roadmap](p0253.md) - [0253 - Decision](p0253_decision.md) - [0285 - if/else](p0285.md) -- [0438 - functions](p0438.md) +- [0438 - Functions](p0438.md) diff --git a/proposals/p0438.md b/proposals/p0438.md index d4e6e209b5ae9..ef6c1602c7c92 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -1,4 +1,4 @@ -# functions +# Functions ## Problem -TODO: What problem are you trying to solve? How important is that problem? Who -is impacted by it? +We currently have +[placeholder guidance on functions](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/functions.md). +The intent of this proposal is to establish agreement on the basics, providing a +baseline for future evolution. ## Background -TODO: Is there any background that readers should consider to fully understand -this problem and your approach to solving it? +### C++ syntax + +C++ syntax for function declarations comes in two forms: + +```cpp +std::int64_t Sum(std::int64_t a, std::int64_t b) { + return a + b; +} + +// Or with trailing return type syntax: +auto Sum(std::int64_t a, std::int64_t b) -> std::int64_t { + return a + b; +} +``` + +Bodies are always wrapped by braces. + +### Other languages + +To summarize keyword use from other languages: + +- Type: C# and Java +- `-`: Objective-C +- `def`: Python and Ruby +- `fn`: Rust +- `fun`: Kotlin +- `func`: Go and Swift +- `function`: JavaScript, MatLab, PHP, R, and TypeScript + +For exhaustive function examples: + +- C# + + ```csharp + int Sum(int a, int b) { + return a + b; + } + ``` + +- Go + + ```go + func add(a int, b int) int { + return a + b + } + ``` + +- Java + + ```java + Int Sum(Int a, Int b) { + return a + b; + } + ``` + +- JavaScript + + ```javascript + function Sum(a, b) { + return a + b; + } + ``` + +- Kotlin + + ```kotlin + fun add(a: Int, b: Int): Int { + return a + b + } + ``` + +- Matlab + + ```matlab + function s = sum(a,b) + s = a+b; + end + ``` + +- Objective-C + + ```objc + - (int)sum:(int)a + (int)b { + return a + b; + } + ``` + +- PHP + + ```php + function sum(int $a, int $b) { + return $a + $b; + } + ``` + +- Python + + ```python + def sum(a: int, b:int) -> int: + return a + b + + def sum(a: int, b:int) -> int: + return a + b + ``` + +- R + + ```r + sum <- function(a, b) { + a + b + } + ``` + +- Ruby + + ```ruby + def sum(a, b) + return a + b + end + ``` + +- Rust + + ```rust + fn sum(a: i64, b: i64) -> i64 { + a + b + } + ``` + +- Swift + + ```swift + func sum(a: Int, b: Int) -> Int { + return a + b + } + ``` + +- TypeScript + + ```typescript + function sum(a: number, b: number): number { + return a + b; + } + ``` + +### Forward declarations + +[Forward declarations](https://en.wikipedia.org/wiki/Forward_declaration) of +functions are largely unique to C++. Objective-C also has this. However, most +other languages being discussed do not. ## Proposal -TODO: Briefly and at a high level, how do you propose to solve the problem? Why -will that in fact solve it? +### Functions -## Details +Function declarations and definitions should look like: -TODO: Fully explain the details of the proposed solution. +`` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _]_ +`{` _body_ `}` + +Arguments should be comma-separated and imitate +[`var` syntax](https://github.com/carbon-language/carbon-lang/pull/339), +although `var` itself is not required. + +For example: + +```carbon + Sum(Int a, Int b) -> Int { + +} +``` + +The return type may be omitted if `Void`. For example: + +```carbon + Print(String s) { + +} +``` + +### Forward declarations + +Forward declarations will be supported in order to support separation of API and +implementation, as explained in +[code and name organization](https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design/code_and_name_organization). +For example: + +```carbon +package Math api; + + Sum(Int a, Int b) -> Int; +``` + +Forward declarations will experimentally _only_ be allowed in `api` files, and +_only_ when the definition is not in the same file. The intent is to minimize +use, consistent with most other languages that have no forward declaration +support at all. ## Alternatives considered -TODO: What alternative solutions have you considered? +### Function keyword + +We may have anchored on `fn` without much consideration. A key piece of this +proposal is to suggest reconsidering the choice, even if we end up with the +same. + +### Type + +Advantages: + +- Echoes C++, C#, and Java +- Simpler to write; a type will often be present for the return regardless. + +Disadvantages: + +- Makes function syntax more difficult to parse. + - In C++, it's notable that functions with a trailing return still start + with `auto` to indicate a "type". + +There's a consensus that _some_ keyword should be used in order to simplify +parsing, so this option is not expected to receive much support. + +### `-` (dash) + +Advantages: + +- Echoes Objective-C +- This is the most succinct option. + +Disadvantages: + +- Easy to miss, and hard to read as a result. + +Although this alternative is mentioned, it is not expected to receive much +support due to its readability problem. + +### `def` + +Advantages: + +- Echoes Python and Ruby + +Disadvantages: + +- `def` is presumably short for "define", which may not be as obvious as a + "function" derivative. + +### `fn` + +Advantages: + +- Echoes Rust +- The shortest "function" derivative. + - Likely comes from the [fn key](https://en.wikipedia.org/wiki/Fn_key). + +Disadvantages: + +- Abbreviation by removing letters in the middle of a word is + [disallowed by Carbon's C++ style](https://google.github.io/styleguide/cppguide.html#General_Naming_Rules). + - Even though the abbreviation is in Wikipedia, it is not associated with + [functions in programming](https://en.wikipedia.org/wiki/Subroutine). + +### `fun` + +Advantages: + +- Echoes Kotlin + +Disadvantages: + +- "fun" is a common English word and may be a mildly confusing choice as a + result. + +### `func` + +Advantages: + +- Echoes Go and Swift + +Disadvantages: + +- ? + +### `function` + +Advantages: + +- Echoes JavaScript, MatLab, PHP, R, and TypeScript +- Clear meaning without any abbreviation. + +Disadvantages: + +- The longest "function" derivative. + +### Forward declaration differences with C++ + +This proposal suggests only allowing forward declarations in `api` files where +the corresponding definition is not present. + +C++ supports forward declaring functions in a `.cpp` file, and this may be +useful for handling interdependencies between functions. In Carbon, we should +instead aim to allow having a function able to call a function defined later in +the same file without requiring a forward declaration. + +Advantages: + +- Minimize accidents with forward declarations not matching implementation. +- Fewer forward declarations for developers to find while reading. + +Disadvantages: + +- Shifts burden onto how code is parsed and executed. + +This is proposed as an experiment in order to see if it's sustainable. + +#### Struct and interface methods + +This is intended to extend to forward declarations of struct and interface to +methods. That is to say, this code is also problematic when the forward +declaration and definition are in the same file: + +```carbon +package Geometry impl; + +struct Circle { + Print(); +}; + + Circle::Print() { +} +``` + +Instead, either the definition would need to be put inside `Circle`, or +`Circle`'s declaration should be moved to the `api`. + +### Rationale + +- This proposal borrows portions of trailing return function syntax from C++. + - Although other languages have different trailing return syntax, we + prefer C++'s syntax given no strong reason to switch. + - We prefer trailing return syntax because we expect increased + readability, and it allows the identifier to be adjacent to TBD KEYWORD. +- Carbon is using TBD KEYWORD for similarity to LANGUAGE(S). +- Forward declarations are minimized because they hurt readability when used + excessively. + - If we need more forward declarations later, it will be easy to ease + restrictions. From ec253e784d8fb50a30b5d42153704b4df5d6e1e3 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 7 Apr 2021 16:12:37 -0700 Subject: [PATCH 03/23] Minor update --- proposals/p0438.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index ef6c1602c7c92..9ea74b4b325af 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -255,7 +255,7 @@ same. Advantages: -- Echoes C++, C#, and Java +- Echoes C++, C#, and Java. - Simpler to write; a type will often be present for the return regardless. Disadvantages: @@ -271,7 +271,7 @@ parsing, so this option is not expected to receive much support. Advantages: -- Echoes Objective-C +- Echoes Objective-C. - This is the most succinct option. Disadvantages: @@ -285,7 +285,7 @@ support due to its readability problem. Advantages: -- Echoes Python and Ruby +- Echoes Python and Ruby. Disadvantages: @@ -296,7 +296,7 @@ Disadvantages: Advantages: -- Echoes Rust +- Echoes Rust. - The shortest "function" derivative. - Likely comes from the [fn key](https://en.wikipedia.org/wiki/Fn_key). @@ -306,12 +306,16 @@ Disadvantages: [disallowed by Carbon's C++ style](https://google.github.io/styleguide/cppguide.html#General_Naming_Rules). - Even though the abbreviation is in Wikipedia, it is not associated with [functions in programming](https://en.wikipedia.org/wiki/Subroutine). + - Would likely be the only keyword abbreviated this way. ### `fun` Advantages: -- Echoes Kotlin +- Echoes Kotlin. +- Could be used with `var` as a push towards three letter abbreviations. + - Not clear there are other examples of three letter abbreviations. + - `let` may be used in a similar way, although it's not an abbreviation. Disadvantages: @@ -322,17 +326,17 @@ Disadvantages: Advantages: -- Echoes Go and Swift +- Echoes Go and Swift. Disadvantages: -- ? +- The longest abbreviated form of "function". ### `function` Advantages: -- Echoes JavaScript, MatLab, PHP, R, and TypeScript +- Echoes JavaScript, MatLab, PHP, R, and TypeScript. - Clear meaning without any abbreviation. Disadvantages: From 38e5b09b1bfd1bfdd3871ec1b68d22f5ccf5d450 Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 11:14:09 -0700 Subject: [PATCH 04/23] Apply suggestions from code review Co-authored-by: Geoff Romer --- proposals/p0438.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/p0438.md b/proposals/p0438.md index 9ea74b4b325af..333cdcc788d8a 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -391,6 +391,8 @@ Instead, either the definition would need to be put inside `Circle`, or prefer C++'s syntax given no strong reason to switch. - We prefer trailing return syntax because we expect increased readability, and it allows the identifier to be adjacent to TBD KEYWORD. + It may also simplify the implementation, particularly in cases where the + return type is defined in terms of the function parameters. - Carbon is using TBD KEYWORD for similarity to LANGUAGE(S). - Forward declarations are minimized because they hurt readability when used excessively. From c6a61ce21e1cde059f2e69ced06b299f698c0ce3 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 11:14:15 -0700 Subject: [PATCH 05/23] Rephrase --- proposals/p0438.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 9ea74b4b325af..0ee46b9dd6692 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -239,9 +239,9 @@ package Math api; ``` Forward declarations will experimentally _only_ be allowed in `api` files, and -_only_ when the definition is not in the same file. The intent is to minimize -use, consistent with most other languages that have no forward declaration -support at all. +_only_ when the definition is in the library's `impl` file. The intent is to +minimize use, consistent with most other languages that have no forward +declaration support at all. ## Alternatives considered From e6daa3817cc2e39f6d521a0ffd089ddb71ef9d3d Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 12:00:25 -0700 Subject: [PATCH 06/23] Argue for func --- proposals/p0438.md | 88 +++++++++++++++++++++++++++++++++------------- 1 file changed, 63 insertions(+), 25 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index e1378d23a2447..a35491ba8e0fb 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -22,13 +22,14 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Forward declarations](#forward-declarations-1) - [Alternatives considered](#alternatives-considered) - [Function keyword](#function-keyword) - - [Type](#type) - - [`-` (dash)](#--dash) - - [`def`](#def) - - [`fn`](#fn) - - [`fun`](#fun) - - [`func`](#func) - - [`function`](#function) + - [Type](#type) + - [`-` (dash)](#--dash) + - [`def`](#def) + - [`fn`](#fn) + - [`fun`](#fun) + - [`func`](#func) + - [`function`](#function) + - [Conclusion](#conclusion) - [Forward declaration differences with C++](#forward-declaration-differences-with-c) - [Struct and interface methods](#struct-and-interface-methods) - [Rationale](#rationale) @@ -202,8 +203,8 @@ other languages being discussed do not. Function declarations and definitions should look like: -`` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _]_ -`{` _body_ `}` +`func` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _]_ `{` _body_ +`}` Arguments should be comma-separated and imitate [`var` syntax](https://github.com/carbon-language/carbon-lang/pull/339), @@ -212,7 +213,7 @@ although `var` itself is not required. For example: ```carbon - Sum(Int a, Int b) -> Int { +func Sum(Int a, Int b) -> Int { } ``` @@ -220,7 +221,7 @@ For example: The return type may be omitted if `Void`. For example: ```carbon - Print(String s) { +func Print(String s) { } ``` @@ -235,7 +236,7 @@ For example: ```carbon package Math api; - Sum(Int a, Int b) -> Int; +func Sum(Int a, Int b) -> Int; ``` Forward declarations will experimentally _only_ be allowed in `api` files, and @@ -251,7 +252,7 @@ We may have anchored on `fn` without much consideration. A key piece of this proposal is to suggest reconsidering the choice, even if we end up with the same. -### Type +#### Type Advantages: @@ -267,7 +268,7 @@ Disadvantages: There's a consensus that _some_ keyword should be used in order to simplify parsing, so this option is not expected to receive much support. -### `-` (dash) +#### `-` (dash) Advantages: @@ -281,7 +282,7 @@ Disadvantages: Although this alternative is mentioned, it is not expected to receive much support due to its readability problem. -### `def` +#### `def` Advantages: @@ -292,7 +293,7 @@ Disadvantages: - `def` is presumably short for "define", which may not be as obvious as a "function" derivative. -### `fn` +#### `fn` Advantages: @@ -308,7 +309,7 @@ Disadvantages: [functions in programming](https://en.wikipedia.org/wiki/Subroutine). - Would likely be the only keyword abbreviated this way. -### `fun` +#### `fun` Advantages: @@ -322,7 +323,7 @@ Disadvantages: - "fun" is a common English word and may be a mildly confusing choice as a result. -### `func` +#### `func` Advantages: @@ -332,7 +333,7 @@ Disadvantages: - The longest abbreviated form of "function". -### `function` +#### `function` Advantages: @@ -343,6 +344,41 @@ Disadvantages: - The longest "function" derivative. +### Conclusion + +`fn` and `func` are the favored options. This proposal chooses `func` over `fn` +for three reasons: + +- Length: there's a desire for writing less than "function", so we are + pursuing an abbreviation. + - `func` is 4 characters; `fn` is 2 characters. +- Consistency: + - We are using abbreviations like `var`, and something like `mut` or + `const` seems likely. `ptr` is possible. + - `func` is consistent with abbreviation by removing letters at the + end. + - `fn` is more consistent with abbreviations like `ptr` that remove + letters in the middle, but `fcn` or `pr` would be more consistent. + - We are using + [Google C++ style](https://google.github.io/styleguide/cppguide.html#General_Naming_Rules) + as a base, which explicitly discourages abbreviating by deleting letters + within a word. + - `fn` deletes letters in the middle of "function", `func` does not. +- Familiarity: both will likely be immediately familiar to many developers, + but `func` will likely be more familiar as a keyword. + - `func` is used by Go and Swift, both of which are common languages. + - [`func`](https://www.google.com/search?q=func) is very searchable. + - `fn` is only used by Rust, which by most measures has less adoption than + either Go or Swift at present. However, it is used in + [hungarian notation](https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions), + which many C++ developers may be familiar with already. + - It's also used for the + [fn key](https://en.wikipedia.org/wiki/Fn_key), although assumptions + about the meaning of "n" as "abbreviation for function" versus + "number" may be initially misleading. + - [`fn`](https://www.google.com/search?q=fn) is difficult to search + for. + ### Forward declaration differences with C++ This proposal suggests only allowing forward declarations in `api` files where @@ -374,10 +410,10 @@ declaration and definition are in the same file: package Geometry impl; struct Circle { - Print(); + func Print(); }; - Circle::Print() { +func Circle::Print() { } ``` @@ -390,10 +426,12 @@ Instead, either the definition would need to be put inside `Circle`, or - Although other languages have different trailing return syntax, we prefer C++'s syntax given no strong reason to switch. - We prefer trailing return syntax because we expect increased - readability, and it allows the identifier to be adjacent to TBD KEYWORD. - It may also simplify the implementation, particularly in cases where the - return type is defined in terms of the function parameters. -- Carbon is using TBD KEYWORD for similarity to LANGUAGE(S). + readability, and it allows the identifier to be adjacent to `func`. + - It may also simplify the implementation, particularly in cases where + the return type is defined in terms of the function parameters. +- Carbon is using `func`, which echoes Go and Swift. This gives familiarity to + a significant amount of engineers while also offering significant + abbreviation the longer "function". - Forward declarations are minimized because they hurt readability when used excessively. - If we need more forward declarations later, it will be easy to ease From 9261c495345be188de7930ec5171f78ca9cd23bd Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 12:04:42 -0700 Subject: [PATCH 07/23] Iterate --- proposals/p0438.md | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index a35491ba8e0fb..d6a132616529f 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -203,8 +203,8 @@ other languages being discussed do not. Function declarations and definitions should look like: -`func` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _]_ `{` _body_ -`}` +`TBDKEYWORD` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _]_ `{` +_body_ `}` Arguments should be comma-separated and imitate [`var` syntax](https://github.com/carbon-language/carbon-lang/pull/339), @@ -213,7 +213,7 @@ although `var` itself is not required. For example: ```carbon -func Sum(Int a, Int b) -> Int { +TBDKEYWORD Sum(Int a, Int b) -> Int { } ``` @@ -221,7 +221,7 @@ func Sum(Int a, Int b) -> Int { The return type may be omitted if `Void`. For example: ```carbon -func Print(String s) { +TBDKEYWORD Print(String s) { } ``` @@ -236,7 +236,7 @@ For example: ```carbon package Math api; -func Sum(Int a, Int b) -> Int; +TBDKEYWORD Sum(Int a, Int b) -> Int; ``` Forward declarations will experimentally _only_ be allowed in `api` files, and @@ -346,13 +346,11 @@ Disadvantages: ### Conclusion -`fn` and `func` are the favored options. This proposal chooses `func` over `fn` -for three reasons: +`fn` and `func` are the favored options: -- Length: there's a desire for writing less than "function", so we are - pursuing an abbreviation. - - `func` is 4 characters; `fn` is 2 characters. -- Consistency: +- Desire to abbreviate "function", although `fn` is clearly shorter than + `func`. +- Consistency with other abbreviations: - We are using abbreviations like `var`, and something like `mut` or `const` seems likely. `ptr` is possible. - `func` is consistent with abbreviation by removing letters at the @@ -364,8 +362,7 @@ for three reasons: as a base, which explicitly discourages abbreviating by deleting letters within a word. - `fn` deletes letters in the middle of "function", `func` does not. -- Familiarity: both will likely be immediately familiar to many developers, - but `func` will likely be more familiar as a keyword. +- Familiarity for developers: - `func` is used by Go and Swift, both of which are common languages. - [`func`](https://www.google.com/search?q=func) is very searchable. - `fn` is only used by Rust, which by most measures has less adoption than @@ -379,6 +376,9 @@ for three reasons: - [`fn`](https://www.google.com/search?q=fn) is difficult to search for. +Note that both are argued here as reasonable solutions that would satisfy many. +We are using TBDKEYWORD. + ### Forward declaration differences with C++ This proposal suggests only allowing forward declarations in `api` files where @@ -410,10 +410,10 @@ declaration and definition are in the same file: package Geometry impl; struct Circle { - func Print(); + TBDKEYWORD Print(); }; -func Circle::Print() { +TBDKEYWORD Circle::Print() { } ``` @@ -426,12 +426,13 @@ Instead, either the definition would need to be put inside `Circle`, or - Although other languages have different trailing return syntax, we prefer C++'s syntax given no strong reason to switch. - We prefer trailing return syntax because we expect increased - readability, and it allows the identifier to be adjacent to `func`. + readability, and it allows the identifier to be adjacent to + `TBDKEYWORD`. - It may also simplify the implementation, particularly in cases where the return type is defined in terms of the function parameters. -- Carbon is using `func`, which echoes Go and Swift. This gives familiarity to - a significant amount of engineers while also offering significant - abbreviation the longer "function". +- Carbon is using `TBDKEYWORD`, which echoes Go and Swift. This gives + familiarity to a significant amount of engineers while also offering + significant abbreviation the longer "function". - Forward declarations are minimized because they hurt readability when used excessively. - If we need more forward declarations later, it will be easy to ease From fbc18a7bcf19afcb9d55b8ce7c783f0ac2588ce8 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 13:32:08 -0700 Subject: [PATCH 08/23] hungarian --- proposals/p0438.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index d6a132616529f..010a2c5535275 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -367,8 +367,9 @@ Disadvantages: - [`func`](https://www.google.com/search?q=func) is very searchable. - `fn` is only used by Rust, which by most measures has less adoption than either Go or Swift at present. However, it is used in - [hungarian notation](https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions), - which many C++ developers may be familiar with already. + [Hungarian notation](https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions), + so some C++ developers will be familiar with it that way, if they've + used Hungarian with function pointers. - It's also used for the [fn key](https://en.wikipedia.org/wiki/Fn_key), although assumptions about the meaning of "n" as "abbreviation for function" versus From 2f9526fb611571838e6caeec34aa3469991d8d56 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 13:32:38 -0700 Subject: [PATCH 09/23] hungarian --- proposals/p0438.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 010a2c5535275..dc0cc721d5d56 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -368,8 +368,7 @@ Disadvantages: - `fn` is only used by Rust, which by most measures has less adoption than either Go or Swift at present. However, it is used in [Hungarian notation](https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions), - so some C++ developers will be familiar with it that way, if they've - used Hungarian with function pointers. + so some C++ developers will be familiar with `fn` for function pointers. - It's also used for the [fn key](https://en.wikipedia.org/wiki/Fn_key), although assumptions about the meaning of "n" as "abbreviation for function" versus From afe23c44357e39c5ed1c1ffd5be55f4124167bb2 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 13:34:30 -0700 Subject: [PATCH 10/23] abbv --- proposals/p0438.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index dc0cc721d5d56..6c9c43c9f9d8b 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -348,8 +348,8 @@ Disadvantages: `fn` and `func` are the favored options: -- Desire to abbreviate "function", although `fn` is clearly shorter than - `func`. +- Desire to abbreviate "function": + - `fn` is clearly shorter than `func`. Both are shorter than "function". - Consistency with other abbreviations: - We are using abbreviations like `var`, and something like `mut` or `const` seems likely. `ptr` is possible. From 121fd3e5d1884ba80142e1084a1c0a6997302989 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 13:35:36 -0700 Subject: [PATCH 11/23] Fn --- proposals/p0438.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 6c9c43c9f9d8b..af14e21c1f586 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -370,7 +370,7 @@ Disadvantages: [Hungarian notation](https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions), so some C++ developers will be familiar with `fn` for function pointers. - It's also used for the - [fn key](https://en.wikipedia.org/wiki/Fn_key), although assumptions + [Fn key](https://en.wikipedia.org/wiki/Fn_key), although assumptions about the meaning of "n" as "abbreviation for function" versus "number" may be initially misleading. - [`fn`](https://www.google.com/search?q=fn) is difficult to search From c5f73b00509ea12742965ed91b9857e5399ab4e5 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 14:36:00 -0700 Subject: [PATCH 12/23] indent --- proposals/p0438.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index af14e21c1f586..d41ca9ae0d5e2 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -322,6 +322,18 @@ Disadvantages: - "fun" is a common English word and may be a mildly confusing choice as a result. +- When wrapping function definitions, the function name and wrapped types + would end up on the same column when indenting by 4 spaces. These use the + same casing, so it may be harder to read. + + - For example: + + ```carbon + fun Print( + String message) { + ... + } + ``` #### `func` @@ -371,8 +383,8 @@ Disadvantages: so some C++ developers will be familiar with `fn` for function pointers. - It's also used for the [Fn key](https://en.wikipedia.org/wiki/Fn_key), although assumptions - about the meaning of "n" as "abbreviation for function" versus - "number" may be initially misleading. + about the meaning of "Fn" as abbreviation for "function" versus + "F-number key" (as in F5) may mislead some developers. - [`fn`](https://www.google.com/search?q=fn) is difficult to search for. From a61890acf350d713f3a7fb97065bf06211f42c82 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Thu, 8 Apr 2021 14:38:32 -0700 Subject: [PATCH 13/23] more fun --- proposals/p0438.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index d41ca9ae0d5e2..66f9a4fe617e6 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -324,7 +324,7 @@ Disadvantages: result. - When wrapping function definitions, the function name and wrapped types would end up on the same column when indenting by 4 spaces. These use the - same casing, so it may be harder to read. + same casing, so it may make it slower to understand code. - For example: @@ -335,6 +335,9 @@ Disadvantages: } ``` + - This is also true for `var`, but wrapping arguments is expected to be + more common for functions, and the casing more likely to match. + #### `func` Advantages: From b90bcacc8409681feda36312527cc943533603cd Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Tue, 13 Apr 2021 14:03:27 -0700 Subject: [PATCH 14/23] Fix # --- proposals/p0438.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 66f9a4fe617e6..dec0a412dd5e4 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -32,7 +32,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Conclusion](#conclusion) - [Forward declaration differences with C++](#forward-declaration-differences-with-c) - [Struct and interface methods](#struct-and-interface-methods) - - [Rationale](#rationale) +- [Rationale](#rationale) @@ -435,7 +435,7 @@ TBDKEYWORD Circle::Print() { Instead, either the definition would need to be put inside `Circle`, or `Circle`'s declaration should be moved to the `api`. -### Rationale +## Rationale - This proposal borrows portions of trailing return function syntax from C++. - Although other languages have different trailing return syntax, we From a10ad2083e566bef72e40e9523518bf1f0763415 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 14 Apr 2021 16:51:46 -0700 Subject: [PATCH 15/23] Pronunciation --- proposals/p0438.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/p0438.md b/proposals/p0438.md index dec0a412dd5e4..4ec9a216435b6 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -390,6 +390,14 @@ Disadvantages: "F-number key" (as in F5) may mislead some developers. - [`fn`](https://www.google.com/search?q=fn) is difficult to search for. +- Pronunciation: + - Both may be pronounced as "function", but may also be pronounced by + their abbreviation. + - `func` would be as "funk", defined as a music genre or state of + depression. + - `fn` would be as "eff en", which has no direct meaning but could be + misheard as "effing", or profanity. However, it's not clear that this + potential mishearing is a pragmatic issue. Note that both are argued here as reasonable solutions that would satisfy many. We are using TBDKEYWORD. From 656e57f99e15a35f2476cde590f40df1687680eb Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Mon, 19 Apr 2021 13:29:39 -0700 Subject: [PATCH 16/23] Apply suggestions from code review Co-authored-by: josh11b --- proposals/p0438.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 4ec9a216435b6..4cda27bf24fd0 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -333,6 +333,11 @@ Disadvantages: String message) { ... } + // Similar confusion if the body of the function is indented 4 spaces. + fun Print(String message) { + SomeFunctionCall(); + ... + } ``` - This is also true for `var`, but wrapping arguments is expected to be @@ -400,7 +405,7 @@ Disadvantages: potential mishearing is a pragmatic issue. Note that both are argued here as reasonable solutions that would satisfy many. -We are using TBDKEYWORD. +We are using `TBDKEYWORD`. ### Forward declaration differences with C++ @@ -425,7 +430,7 @@ This is proposed as an experiment in order to see if it's sustainable. #### Struct and interface methods -This is intended to extend to forward declarations of struct and interface to +This is intended to extend to forward declarations of struct and interface methods. That is to say, this code is also problematic when the forward declaration and definition are in the same file: From 20a71d4b4832845940ce4d8dae8c93af595ef1be Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Mon, 19 Apr 2021 14:40:06 -0700 Subject: [PATCH 17/23] Addressing comments --- proposals/p0438.md | 137 +++++++++++++++++++++------------------------ 1 file changed, 64 insertions(+), 73 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 4cda27bf24fd0..814c022182b70 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -20,6 +20,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Proposal](#proposal) - [Functions](#functions) - [Forward declarations](#forward-declarations-1) +- [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) +- [Open questions](#open-questions) + - [Calling functions defined later in the same file](#calling-functions-defined-later-in-the-same-file) - [Alternatives considered](#alternatives-considered) - [Function keyword](#function-keyword) - [Type](#type) @@ -30,9 +33,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [`func`](#func) - [`function`](#function) - [Conclusion](#conclusion) - - [Forward declaration differences with C++](#forward-declaration-differences-with-c) - - [Struct and interface methods](#struct-and-interface-methods) -- [Rationale](#rationale) @@ -144,7 +144,7 @@ For exhaustive function examples: - Python ```python - def sum(a: int, b:int) -> int: + def sum(a, b): return a + b def sum(a: int, b:int) -> int: @@ -203,12 +203,12 @@ other languages being discussed do not. Function declarations and definitions should look like: -`TBDKEYWORD` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _]_ `{` -_body_ `}` +`TBDKEYWORD` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _] [_ +`{` _body_ `}` _|_ `;` _]_ Arguments should be comma-separated and imitate [`var` syntax](https://github.com/carbon-language/carbon-lang/pull/339), -although `var` itself is not required. +although `var` itself is not used. For example: @@ -244,6 +244,49 @@ _only_ when the definition is in the library's `impl` file. The intent is to minimize use, consistent with most other languages that have no forward declaration support at all. +## Rationale based on Carbon's goals + +Carbon needs functions in order to be writable by developers. That functionality +needs a syntax. + +Relevant goals are: + +- [3. Code that is easy to read, understand, and write](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write): + Adding a keyword makes it easy for developers to visually identify + functions. Trailing return syntax should be easier to understand than C++'s + older preceding return syntax. Only allowing one avoids requiring developers + to recognize and choose between equivalent syntaxes. + +- [5. Fast and scalable development](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#fast-and-scalable-development): + The addition of a keyword should make parsing easy. + +- [7. Interoperability with and migration from existing C++ code](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code): + Keeping syntax close to C++ will make it easier for developers to + transition. + +## Open questions + +### Calling functions defined later in the same file + +C++ supports forward declaring functions in a `.cpp` file, and this may be +useful for handling interdependencies between functions. In Carbon, we should +instead aim to allow having a function able to call a function defined later in +the same file without requiring a forward declaration. + +Advantages: + +- Minimize accidents with forward declarations not matching implementation. +- Fewer forward declarations for developers to find while reading. + +Disadvantages: + +- Shifts burden onto how code is parsed and executed. + +We'll need to evaluate how this works. There is tracked by +[#472](https://github.com/carbon-language/carbon-lang/issues/472). This does not +need to block this proposal, as we can allow it later if that's the decision; it +may also be helpful to give more time to consider how name lookup should work. + ## Alternatives considered ### Function keyword @@ -272,12 +315,14 @@ parsing, so this option is not expected to receive much support. Advantages: -- Echoes Objective-C. +- Echoes Objective-C instance method syntax. + - Class methods use `+` and we could echo that too. - This is the most succinct option. Disadvantages: - Easy to miss, and hard to read as a result. +- Might be ambiguous with the `-` operator. Although this alternative is mentioned, it is not expected to receive much support due to its readability problem. @@ -376,7 +421,8 @@ Disadvantages: - `func` is consistent with abbreviation by removing letters at the end. - `fn` is more consistent with abbreviations like `ptr` that remove - letters in the middle, but `fcn` or `pr` would be more consistent. + letters in the middle, but a three letter abbreviation like `fcn` + would be more consistent. - We are using [Google C++ style](https://google.github.io/styleguide/cppguide.html#General_Naming_Rules) as a base, which explicitly discourages abbreviating by deleting letters @@ -398,70 +444,15 @@ Disadvantages: - Pronunciation: - Both may be pronounced as "function", but may also be pronounced by their abbreviation. - - `func` would be as "funk", defined as a music genre or state of + - `func` could be as "funk", defined as a music genre or state of depression. - - `fn` would be as "eff en", which has no direct meaning but could be - misheard as "effing", or profanity. However, it's not clear that this - potential mishearing is a pragmatic issue. + - `fn` could be as: + - "eff en", which has no direct meaning but could be misheard as + "effing", or profanity. However, it's not clear that this potential + mishearing is a pragmatic issue. + - "fun", defined as enjoyment. Note that both are argued here as reasonable solutions that would satisfy many. -We are using `TBDKEYWORD`. - -### Forward declaration differences with C++ - -This proposal suggests only allowing forward declarations in `api` files where -the corresponding definition is not present. - -C++ supports forward declaring functions in a `.cpp` file, and this may be -useful for handling interdependencies between functions. In Carbon, we should -instead aim to allow having a function able to call a function defined later in -the same file without requiring a forward declaration. - -Advantages: - -- Minimize accidents with forward declarations not matching implementation. -- Fewer forward declarations for developers to find while reading. - -Disadvantages: - -- Shifts burden onto how code is parsed and executed. - -This is proposed as an experiment in order to see if it's sustainable. - -#### Struct and interface methods - -This is intended to extend to forward declarations of struct and interface -methods. That is to say, this code is also problematic when the forward -declaration and definition are in the same file: - -```carbon -package Geometry impl; - -struct Circle { - TBDKEYWORD Print(); -}; - -TBDKEYWORD Circle::Print() { -} -``` - -Instead, either the definition would need to be put inside `Circle`, or -`Circle`'s declaration should be moved to the `api`. - -## Rationale - -- This proposal borrows portions of trailing return function syntax from C++. - - Although other languages have different trailing return syntax, we - prefer C++'s syntax given no strong reason to switch. - - We prefer trailing return syntax because we expect increased - readability, and it allows the identifier to be adjacent to - `TBDKEYWORD`. - - It may also simplify the implementation, particularly in cases where - the return type is defined in terms of the function parameters. -- Carbon is using `TBDKEYWORD`, which echoes Go and Swift. This gives - familiarity to a significant amount of engineers while also offering - significant abbreviation the longer "function". -- Forward declarations are minimized because they hurt readability when used - excessively. - - If we need more forward declarations later, it will be easy to ease - restrictions. +This was asked on +[#463](https://github.com/carbon-language/carbon-lang/issues/463). We are using +`TBDKEYWORD`. From 3a77cd69b3f18d8c5c58c9a9b1a27cc3200e483c Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Mon, 19 Apr 2021 15:38:06 -0700 Subject: [PATCH 18/23] Drafting syntax --- proposals/p0438.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 814c022182b70..6a11fb33aa626 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -203,12 +203,15 @@ other languages being discussed do not. Function declarations and definitions should look like: -`TBDKEYWORD` _function name_ `(` _arguments_ `)` _[_ `->` _return type_ _] [_ -`{` _body_ `}` _|_ `;` _]_ +`TBDKEYWORD` _function name_ `(` _type [identifier] \[_ `,` _type [identifier] +]..._ `)` _[_ `->` _return type_ _] [_ `{` _body_ `}` _|_ `;` _]_ Arguments should be comma-separated and imitate [`var` syntax](https://github.com/carbon-language/carbon-lang/pull/339), -although `var` itself is not used. +although `var` itself is not used. The identifier is optional; that is, `Int` +and `Int a` forms are allowed as arguments. When an identifier is provided, the +argument may be referenced from the body; when an identifier is not provided, it +means the value is unused. For example: From 1e417cb7daab067c663bcaa5125bfdcded329d50 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Mon, 19 Apr 2021 16:34:53 -0700 Subject: [PATCH 19/23] Optional open question --- proposals/p0438.md | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 6a11fb33aa626..6c27caddc6563 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -23,6 +23,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals) - [Open questions](#open-questions) - [Calling functions defined later in the same file](#calling-functions-defined-later-in-the-same-file) + - [Optional argument names](#optional-argument-names) - [Alternatives considered](#alternatives-considered) - [Function keyword](#function-keyword) - [Type](#type) @@ -203,15 +204,12 @@ other languages being discussed do not. Function declarations and definitions should look like: -`TBDKEYWORD` _function name_ `(` _type [identifier] \[_ `,` _type [identifier] -]..._ `)` _[_ `->` _return type_ _] [_ `{` _body_ `}` _|_ `;` _]_ +`TBDKEYWORD` _function name_ `(` _type identifier \[_ `,` _type identifier ]..._ +`)` _[_ `->` _return type_ _] [_ `{` _body_ `}` _|_ `;` _]_ Arguments should be comma-separated and imitate [`var` syntax](https://github.com/carbon-language/carbon-lang/pull/339), -although `var` itself is not used. The identifier is optional; that is, `Int` -and `Int a` forms are allowed as arguments. When an identifier is provided, the -argument may be referenced from the body; when an identifier is not provided, it -means the value is unused. +although `var` itself is not used. For example: @@ -219,6 +217,10 @@ For example: TBDKEYWORD Sum(Int a, Int b) -> Int { } + +TBDKEYWORD UnusedArgument(Int _) -> Int { + +} ``` The return type may be omitted if `Void`. For example: @@ -254,16 +256,16 @@ needs a syntax. Relevant goals are: -- [3. Code that is easy to read, understand, and write](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write): +- [3. Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write): Adding a keyword makes it easy for developers to visually identify functions. Trailing return syntax should be easier to understand than C++'s older preceding return syntax. Only allowing one avoids requiring developers to recognize and choose between equivalent syntaxes. -- [5. Fast and scalable development](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#fast-and-scalable-development): +- [5. Fast and scalable development](/docs/project/goals.md#fast-and-scalable-development): The addition of a keyword should make parsing easy. -- [7. Interoperability with and migration from existing C++ code](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code): +- [7. Interoperability with and migration from existing C++ code](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code): Keeping syntax close to C++ will make it easier for developers to transition. @@ -290,6 +292,12 @@ We'll need to evaluate how this works. There is tracked by need to block this proposal, as we can allow it later if that's the decision; it may also be helpful to give more time to consider how name lookup should work. +### Optional argument names + +Argument names are required under this proposal. It's likely that developers +will want a way to indicate unused arguments. This is tracked by +[#476](https://github.com/carbon-language/carbon-lang/issues/476). + ## Alternatives considered ### Function keyword From d5cf849a8a5b9a74942c19388fcb62eb8bcf9981 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Tue, 20 Apr 2021 08:16:37 -0700 Subject: [PATCH 20/23] bullets --- proposals/p0438.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 6c27caddc6563..20845d5ab4389 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -257,10 +257,12 @@ needs a syntax. Relevant goals are: - [3. Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write): - Adding a keyword makes it easy for developers to visually identify - functions. Trailing return syntax should be easier to understand than C++'s - older preceding return syntax. Only allowing one avoids requiring developers - to recognize and choose between equivalent syntaxes. + + - Adding a keyword makes it easy for developers to visually identify + functions. + - Trailing return syntax should be easier to understand than C++'s older + preceding return syntax. Only allowing one avoids requiring developers + to recognize and choose between equivalent syntaxes. - [5. Fast and scalable development](/docs/project/goals.md#fast-and-scalable-development): The addition of a keyword should make parsing easy. From 6bba316b7f10263325c8b700e60e5d5eb3198bdd Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Fri, 23 Apr 2021 15:41:38 -0700 Subject: [PATCH 21/23] fn --- proposals/p0438.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 20845d5ab4389..faef8ffc6a10f 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -204,8 +204,8 @@ other languages being discussed do not. Function declarations and definitions should look like: -`TBDKEYWORD` _function name_ `(` _type identifier \[_ `,` _type identifier ]..._ -`)` _[_ `->` _return type_ _] [_ `{` _body_ `}` _|_ `;` _]_ +`fn` _function name_ `(` _type identifier \[_ `,` _type identifier ]..._ `)` _[_ +`->` _return type_ _] [_ `{` _body_ `}` _|_ `;` _]_ Arguments should be comma-separated and imitate [`var` syntax](https://github.com/carbon-language/carbon-lang/pull/339), @@ -214,11 +214,11 @@ although `var` itself is not used. For example: ```carbon -TBDKEYWORD Sum(Int a, Int b) -> Int { +fn Sum(Int a, Int b) -> Int { } -TBDKEYWORD UnusedArgument(Int _) -> Int { +fn UnusedArgument(Int _) -> Int { } ``` @@ -226,7 +226,7 @@ TBDKEYWORD UnusedArgument(Int _) -> Int { The return type may be omitted if `Void`. For example: ```carbon -TBDKEYWORD Print(String s) { +fn Print(String s) { } ``` @@ -241,7 +241,7 @@ For example: ```carbon package Math api; -TBDKEYWORD Sum(Int a, Int b) -> Int; +fn Sum(Int a, Int b) -> Int; ``` Forward declarations will experimentally _only_ be allowed in `api` files, and @@ -468,4 +468,4 @@ Disadvantages: Note that both are argued here as reasonable solutions that would satisfy many. This was asked on [#463](https://github.com/carbon-language/carbon-lang/issues/463). We are using -`TBDKEYWORD`. +`fn`. From 243cee782d07c885ad9cef0365443278eb8af162 Mon Sep 17 00:00:00 2001 From: jonmeow <46229924+jonmeow@users.noreply.github.com> Date: Mon, 17 May 2021 15:19:57 -0700 Subject: [PATCH 22/23] Void -> () --- proposals/p0438.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index faef8ffc6a10f..4c4e8d6ee2df2 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -223,12 +223,12 @@ fn UnusedArgument(Int _) -> Int { } ``` -The return type may be omitted if `Void`. For example: +The return type may optionally be omitted if `()`. For example, these two +function declarations both return `()`: ```carbon -fn Print(String s) { - -} +fn Print(String s) -> (); +fn Print(String s); ``` ### Forward declarations From 002977fe27476b6ec5ef64e3c3e62004ab631db6 Mon Sep 17 00:00:00 2001 From: Jon Meow <46229924+jonmeow@users.noreply.github.com> Date: Wed, 19 May 2021 10:19:14 -0700 Subject: [PATCH 23/23] Update proposals/p0438.md Co-authored-by: josh11b --- proposals/p0438.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/p0438.md b/proposals/p0438.md index 4c4e8d6ee2df2..d0cf9019c1f95 100644 --- a/proposals/p0438.md +++ b/proposals/p0438.md @@ -148,7 +148,7 @@ For exhaustive function examples: def sum(a, b): return a + b - def sum(a: int, b:int) -> int: + def sum(a: int, b: int) -> int: return a + b ```