|
| 1 | +% Rust Design FAQ |
| 2 | + |
| 3 | +This document describes decisions were arrived at after lengthy discussion and |
| 4 | +experimenting with alternatives. Please do not propose reversing them unless |
| 5 | +you have a new, extremely compelling argument. Note that this document |
| 6 | +specifically talks about the *language* and not any library or implementation. |
| 7 | + |
| 8 | +A few general guidelines define the philosophy: |
| 9 | + |
| 10 | +- [Memory safety][mem] must never be compromised |
| 11 | +- [Abstraction][abs] should be zero-cost, while still maintaining safety |
| 12 | +- Practicality is key |
| 13 | + |
| 14 | +[mem]: http://en.wikipedia.org/wiki/Memory_safety |
| 15 | +[abs]: http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 |
| 16 | + |
| 17 | +# Semantics |
| 18 | + |
| 19 | +## Data layout is unspecified |
| 20 | + |
| 21 | +In the general case, `enum` and `struct` layout is undefined. This allows the |
| 22 | +compiler to potentially do optimizations like re-using padding for the |
| 23 | +discriminant, compacting variants of nested enums, reordering fields to remove |
| 24 | +padding, etc. `enum`s which carry no data ("C-like") are eligible to have a |
| 25 | +defined representation. Such `enum`s are easily distinguished in that they are |
| 26 | +simply a list of names that carry no data: |
| 27 | + |
| 28 | +``` |
| 29 | +enum CLike { |
| 30 | + A, |
| 31 | + B = 32, |
| 32 | + C = 34, |
| 33 | + D |
| 34 | +} |
| 35 | +``` |
| 36 | + |
| 37 | +The [repr attribute][repr] can be applied to such `enum`s to give them the same |
| 38 | +representation as a primitive. This allows using Rust `enum`s in FFI where C |
| 39 | +`enum`s are also used, for most use cases. The attribute can also be applied |
| 40 | +to `struct`s to get the same layout as a C struct would. |
| 41 | + |
| 42 | +[repr]: http://doc.rust-lang.org/rust.html#miscellaneous-attributes |
| 43 | + |
| 44 | +## There is no GC |
| 45 | + |
| 46 | +A language that requires a GC is a language that opts into a larger, more |
| 47 | +complex runtime than Rust cares for. Rust is usable on bare metal with no |
| 48 | +extra runtime. Additionally, garbage collection is frequently a source of |
| 49 | +non-deterministic behavior. Rust provides the tools to make using a GC |
| 50 | +possible and even pleasant, but it should not be a requirement for |
| 51 | +implementing the language. |
| 52 | + |
| 53 | +## Non-`Share` `static mut` is unsafe |
| 54 | + |
| 55 | +Types which are [`Share`][share] are thread-safe when multiple shared |
| 56 | +references to them are used concurrently. Types which are not `Share` are not |
| 57 | +thread-safe, and thus when used in a global require unsafe code to use. |
| 58 | + |
| 59 | +[share]: http://doc.rust-lang.org/core/kinds/trait.Share.html |
| 60 | + |
| 61 | +### If mutable static items that implement `Share` are safe, why is taking &mut SHARABLE unsafe? |
| 62 | + |
| 63 | +Having multiple aliasing `&mut T`s is never allowed. Due to the nature of |
| 64 | +globals, the borrow checker cannot possibly ensure that a static obeys the |
| 65 | +borrowing rules, so taking a mutable reference to a static is always unsafe. |
| 66 | + |
| 67 | +## There is no life before or after main (no static ctors/dtors) |
| 68 | + |
| 69 | +Globals can not have a non-constant-expression constructor and cannot have a |
| 70 | +destructor at all. This is an opinion of the language. Static constructors are |
| 71 | +undesirable because they can slow down program startup. Life before main is |
| 72 | +often considered a misfeature, never to be used. Rust helps this along by just |
| 73 | +not having the feature. |
| 74 | + |
| 75 | +See [the C++ FQA][fqa] about the "static initialization order fiasco", and |
| 76 | +[Eric Lippert's blog][elp] for the challenges in C#, which also has this |
| 77 | +feature. |
| 78 | + |
| 79 | +A nice replacement is the [lazy constructor macro][lcm] by [Marvin |
| 80 | +Löbel][kim]. |
| 81 | + |
| 82 | +[fqa]: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003815.html |
| 83 | +[elp]: http://ericlippert.com/2013/02/06/static-constructors-part-one/ |
| 84 | +[lcm]: https://gist.github.com/Kimundi/8782487 |
| 85 | +[kim]: https://github.com/Kimundi |
| 86 | + |
| 87 | +## The language does not require a runtime |
| 88 | + |
| 89 | +See the above entry on GC. Requiring a runtime limits the utility of the |
| 90 | +language, and makes it undeserving of the title "systems language". All Rust |
| 91 | +code should need to run is a stack. |
| 92 | + |
| 93 | +## `match` must be exhaustive |
| 94 | + |
| 95 | +`match` being exhaustive has some useful properties. First, if every |
| 96 | +possibility is covered by the `match`, adding further variants to the `enum` |
| 97 | +in the future will prompt a compilation failure, rather than runtime failure. |
| 98 | +Second, it makes cost explicit. In general, only safe way to have a |
| 99 | +non-exhaustive match would be to fail the task if nothing is matched, though |
| 100 | +it could fall through if the type of the `match` expression is `()`. This sort |
| 101 | +of hidden cost and special casing is against the language's philosophy. It's |
| 102 | +easy to ignore certain cases by using the `_` wildcard: |
| 103 | + |
| 104 | +```rust,ignore |
| 105 | +match val.do_something() { |
| 106 | + Cat(a) => { /* ... */ } |
| 107 | + _ => { /* ... */ } |
| 108 | +} |
| 109 | +``` |
| 110 | + |
| 111 | +[#3101][iss] is the issue that proposed making this the only behavior, with |
| 112 | +rationale and discussion. |
| 113 | + |
| 114 | +[iss]: https://github.com/mozilla/rust/issues/3101 |
| 115 | + |
| 116 | +## No guaranteed tail-call optimization |
| 117 | + |
| 118 | +In general, tail-call optimization is not guaranteed: see for a detailed |
| 119 | +explanation with references. There is a [proposed extension][tce] that would |
| 120 | +allow tail-call elimination in certain contexts. The compiler is still free to |
| 121 | +optimize tail-calls [when it pleases][sco], however. |
| 122 | + |
| 123 | +[tml]: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html |
| 124 | +[sco]: http://llvm.org/docs/CodeGenerator.html#sibling-call-optimization |
| 125 | +[tce]: https://github.com/rust-lang/rfcs/pull/81 |
| 126 | + |
| 127 | +## No constructors |
| 128 | + |
| 129 | +Functions can serve the same purpose as constructors without adding any |
| 130 | +language complexity. |
| 131 | + |
| 132 | +## No copy constructors |
| 133 | + |
| 134 | +Types which implement [`Copy`][copy], will do a standard C-like "shallow copy" |
| 135 | +with no extra work (similar to "plain old data" in C++). It is impossible to |
| 136 | +implement `Copy` types that require custom copy behavior. Instead, in Rust |
| 137 | +"copy constructors" are created by implementing the [`Clone`][clone] trait, |
| 138 | +and explicitly calling the `clone` method. Making user-defined copy operators |
| 139 | +explicit surfaces the underlying complexity, forcing the developer to opt-in |
| 140 | +to potentially expensive operations. |
| 141 | + |
| 142 | +[copy]: http://doc.rust-lang.org/core/kinds/trait.Copy.html |
| 143 | +[clone]: http://doc.rust-lang.org/core/clone/trait.Clone.html |
| 144 | + |
| 145 | +## No move constructors |
| 146 | + |
| 147 | +Values of all types are moved via `memcpy`. This makes writing generic unsafe |
| 148 | +code much simpler since assignment, passing and returning are known to never |
| 149 | +have a side effect like unwinding. |
| 150 | + |
| 151 | +# Syntax |
| 152 | + |
| 153 | +## Macros require balanced delimiters |
| 154 | + |
| 155 | +This is to make the language easier to parse for machines. Since the body of a |
| 156 | +macro can contain arbitrary tokens, some restriction is needed to allow simple |
| 157 | +non-macro-expanding lexers and parsers. This comes in the form of requiring |
| 158 | +that all delimiters be balanced. |
| 159 | + |
| 160 | +## `->` for function return type |
| 161 | + |
| 162 | +This is to make the language easier to parse for humans, especially in the face |
| 163 | +of higher-order functions. `fn foo<T>(f: fn(int): int, fn(T): U): U` is not |
| 164 | +particularly easy to read. |
| 165 | + |
| 166 | +## `let` is used to introduce variables |
| 167 | + |
| 168 | +`let` not only defines variables, but can do pattern matching. One can also |
| 169 | +redeclare immutable variables with `let`. This is useful to avoid unnecessary |
| 170 | +`mut` annotations. An interesting historical note is that Rust comes, |
| 171 | +syntactically, most closely from ML, which also uses `let` to introduce |
| 172 | +bindings. |
| 173 | + |
| 174 | +See also [a long thread][alt] on renaming `let mut` to `var`. |
| 175 | + |
| 176 | +[alt]: https://mail.mozilla.org/pipermail/rust-dev/2014-January/008319.html |
0 commit comments