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.
8 A few general guidelines define the philosophy:
10 - [Memory safety][mem] must never be compromised
11 - [Abstraction][abs] should be zero-cost, while still maintaining safety
14 [mem]: http://en.wikipedia.org/wiki/Memory_safety
15 [abs]: http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29
19 ## Data layout is unspecified
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:
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.
42 [repr]: http://doc.rust-lang.org/rust.html#miscellaneous-attributes
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.
53 ## Non-`Sync` `static mut` is unsafe
55 Types which are [`Sync`][sync] are thread-safe when multiple shared
56 references to them are used concurrently. Types which are not `Sync` are not
57 thread-safe, and thus when used in a global require unsafe code to use.
59 [sync]: http://doc.rust-lang.org/core/kinds/trait.Sync.html
61 ### If mutable static items that implement `Sync` are safe, why is taking &mut SHARABLE unsafe?
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.
67 ## There is no life before or after main (no static ctors/dtors)
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.
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
79 A nice replacement is the [lazy constructor macro][lcm] by [Marvin
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
87 ## The language does not require a runtime
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.
93 ## `match` must be exhaustive
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:
105 match val.do_something() {
106 Cat(a) => { /* ... */ }
111 [#3101][iss] is the issue that proposed making this the only behavior, with
112 rationale and discussion.
114 [iss]: https://github.com/rust-lang/rust/issues/3101
116 ## No guaranteed tail-call optimization
118 In general, tail-call optimization is not guaranteed: see [here][tml] for a
119 detailed explanation with references. There is a [proposed extension][tce] that
120 would allow tail-call elimination in certain contexts. The compiler is still
121 free to optimize tail-calls [when it pleases][sco], however.
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
129 Functions can serve the same purpose as constructors without adding any
132 ## No copy constructors
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.
142 [copy]: http://doc.rust-lang.org/core/kinds/trait.Copy.html
143 [clone]: http://doc.rust-lang.org/core/clone/trait.Clone.html
145 ## No move constructors
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.
153 ## Macros require balanced delimiters
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.
160 ## `->` for function return type
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.
166 ## `let` is used to introduce variables
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
174 See also [a long thread][alt] on renaming `let mut` to `var`.
176 [alt]: https://mail.mozilla.org/pipermail/rust-dev/2014-January/008319.html