Merge pull request #1311 from AleoHQ/rfc-tweak

[RFC] Streamline RFC author information.

docs/rfc/001-initial-strings.md

@@ -2,15 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Pratyush Mishra
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/002-bounded-recursion.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/003-imports-stabilization.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 
@@ -18,7 +11,7 @@ FINAL
 # Summary
 
 This proposal aims to improve the import management system in Leo programs to
-make program environment more reproducible, predictable and compatible. To achieve 
+make program environment more reproducible, predictable and compatible. To achieve
 that we suggest few changes to Leo CLI and Manifest:
 
 - add a "dependencies" section to Leo Manifest and add a command to pull those dependencies;
@@ -29,19 +22,19 @@ that we suggest few changes to Leo CLI and Manifest:
 
 # Motivation
 
-The current design of imports does not provide any guarantees on what's stored 
+The current design of imports does not provide any guarantees on what's stored
-in program imports and published with the program to Aleo Package Manager. 
+in program imports and published with the program to Aleo Package Manager.
 When a dependency is "added," it is stored inside imports folder, and it is possible
 to manually edit and/or add packages in this folder.
 
 Also, imports are stored under the package name which makes it impossible to import
-two different packages with the same name. 
+two different packages with the same name.
 
 Another important detail in the scope of this proposal is that in future Leo
-programs will have the ability to be run with different proving systems 
+programs will have the ability to be run with different proving systems
-and curves, possibly creating incompatibility between programs written 
+and curves, possibly creating incompatibility between programs written
 for different proving systems or curves. To make a foundation for these features,
-imports need to be managed with include/exclude lists for allowed (compatible) 
+imports need to be managed with include/exclude lists for allowed (compatible)
 proving systems and curves.
 
 # Design
@@ -67,7 +60,7 @@ curve = "Bls12_377"
 proving_system = "Groth16"
 ```
 
-These fields are meant to be used to determine whether imported program is 
+These fields are meant to be used to determine whether imported program is
 compatible to the original when support for different curves and proving systems
 is added.
 
@@ -88,7 +81,7 @@ version = "1.0"
 
 ### Parameters description
 
-`name` field sets the name of the dependency in Leo code. That way we allow 
+`name` field sets the name of the dependency in Leo code. That way we allow
 developer to resolve collisions in import names manually. So, for example,
 if a developer is adding `howard/silly-sudoku` package to his program, he
 might define its in-code name as `sudoku` and import it with that name:
@@ -97,13 +90,13 @@ might define its in-code name as `sudoku` and import it with that name:
 import sudoku;
 ```
 
-`package`, `author` and `version` are package name, package author and 
+`package`, `author` and `version` are package name, package author and
-version respectively. They are already used as arguments in `leo add` 
+version respectively. They are already used as arguments in `leo add`
 command, so these fields are already understood by the Leo developers.
 
-## Leo CLI 
+## Leo CLI
 
-To support updated Manifest new command should be added to Leo CLI. 
+To support updated Manifest new command should be added to Leo CLI.
 
 ```bash
 # pull imports
@@ -113,11 +106,11 @@ leo fetch
 ## Imports Restructurization
 
 One of the goals of proposed changes is to allow importing packages with the
-same name but different authors. This has to be solved not only on the 
+same name but different authors. This has to be solved not only on the
-language level but also on the level of storing program imports. 
+language level but also on the level of storing program imports.
 
 We suggest using set of all 3 possible program identifiers for import
-folder name: `author-package@version`. Later it can be extended to 
+folder name: `author-package@version`. Later it can be extended to
 include hash for version, but having the inital set already solves name
 collisions.
 
@@ -140,7 +133,7 @@ leo-program
 
 This change would also affect the way imports are being processed on the ASG
 level, and we'd need to add an imports map as an argument to the Leo compiler.
-The Leo Manifest's dependencies sections needs to be parsed and passed as 
+The Leo Manifest's dependencies sections needs to be parsed and passed as
 a hashmap to the compiler:
 
 ```
@@ -184,7 +177,7 @@ The format described here allows the Leo binary to form an imports map which can
 passed to the compiler.
 
 It is important to note that Leo.lock file is created only when a package has dependencies.
-For programs with no dependencies, a lock file is not required and not created. 
+For programs with no dependencies, a lock file is not required and not created.
 
 ## Recursive Dependencies
 
@@ -208,12 +201,12 @@ It also introduces the danger of having recursive dependencies, this problem is
 # Effect on Ecosystem
 
 Proposed improvement provides safety inside Leo programs and should not affect
-ecosystem except for the tools which use Leo directly (such as Aleo Studio). 
+ecosystem except for the tools which use Leo directly (such as Aleo Studio).
 
-It is possible that some of the proposed features will open new features on Aleo PM. 
+It is possible that some of the proposed features will open new features on Aleo PM.
 
 # Alternatives
 
 Another approach to the stated cases is to keep everything as we have now but change
-the way programs are imported and stored and make names unique. Also, current 
+the way programs are imported and stored and make names unique. Also, current
-implementation provides some guarantees on import stablitity and consistency. 
+implementation provides some guarantees on import stablitity and consistency.

docs/rfc/004-integer-type-casts.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/005-countdown-loops.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 
@@ -67,7 +60,7 @@ function bubble_sort(a: [u32; 10]) -> [u32; 10] {
 Having a countdown loop in the examples above could improve readability and
 usability of the language by making it more natural to the developer.
 
-However, if we imagined this example using a countdown loop, we would see that 
+However, if we imagined this example using a countdown loop, we would see that
 it wouldn't be possible to count to 0; because the first bound of the range is
 inclusive and the second is exclusive, and loops ranges must use only unsigned integers.
 
@@ -75,19 +68,19 @@ inclusive and the second is exclusive, and loops ranges must use only unsigned i
 // loop goes 0,1,2,3,4,5,6,7,8
 for i in 0..9 { /* ... */ }
 
-// loop goes 9,8,7,6,5,4,3,2,1 
+// loop goes 9,8,7,6,5,4,3,2,1
 for i in 9..0 { /* ... */ }
 ```
 
 Hence direct implementation of the coundown loop ranges would create asymmetry (1)
-and would not allow loops to count down to 0 (2). To implement coundown loops and 
+and would not allow loops to count down to 0 (2). To implement coundown loops and
 solve these two problems we suggest adding an inclusive range bounds.
 
 # Design
 
 ## Coundown loops
 
-Countdown ranges do not need any changes to the existing syntax. However their 
+Countdown ranges do not need any changes to the existing syntax. However their
 functionality needs to be implemented in the compiler.
 
 ```ts
@@ -96,9 +89,9 @@ for i in 5..0 {}
 
 ## Inclusive ranges
 
-To solve loop asymmetry and to improve loop ranges in general we suggest adding 
+To solve loop asymmetry and to improve loop ranges in general we suggest adding
-inclusive range operator to Leo. Inclusive range would extend the second bound 
+inclusive range operator to Leo. Inclusive range would extend the second bound
-of the loop making it inclusive (instead of default - exclusive) 
+of the loop making it inclusive (instead of default - exclusive)
 therefore allowing countdown loops to reach 0 value.
 
 ```ts

docs/rfc/006-arrays-without-size.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/007-type-aliases.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/008-built-in-declarations.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/009-bit-byte-conversions.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/010-native-functions.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 

docs/rfc/011-scalar-type-accesses-and-methods.md

@@ -2,14 +2,7 @@
 
 ## Authors
 
-- Max Bruce
+The Aleo Team.
-- Collin Chin
-- Alessandro Coglio
-- Eric McCarthy
-- Jon Pavlik
-- Damir Shamanaev
-- Damon Sicore
-- Howard Wu
 
 ## Status
 
@@ -52,7 +45,7 @@ postfix-expression = primary-expression
                    / identifier function-arguments
                    / postfix-expression "." identifier function-arguments
                    / named-type "::" identifier function-arguments ; this used to be a circuit-type
-                   / named-type "::" identifier ; this is new to allow static members on 
+                   / named-type "::" identifier ; this is new to allow static members on
                    / postfix-expression "[" expression "]"
                    / postfix-expression "[" [expression] ".." [expression] "]"
 ```