This document describes decisions that were arrived at after lengthy discussion and experimenting with alternatives. Please do not propose reversing them unless you have a new, extremely compelling argument. Note that this document specifically talks about the language and not any library or implementation.
A few general guidelines define the philosophy:
In the general case, enum`enumand` and struct`structlayout is undefined. This allows the compiler to potentially do optimizations like re-using padding for the discriminant, compacting variants of nested enums, reordering fields to remove padding, etc.` layout is undefined. This allows the
compiler to potentially do optimizations like re-using padding for the
discriminant, compacting variants of nested enums, reordering fields to remove
padding, etc. enum`enums which carry no data ("C-like") are eligible to have a defined representation. Such`s which carry no data ("C-like") are eligible to have a
defined representation. Such enum`enum`s are easily distinguished in that they are
simply a list of names that carry no data:
enum CLike { A, B = 32, C = 34, D }
The repr attribute can be applied to such enum`enums to give them the same representation as a primitive. This allows using Rust`s to give them the same
representation as a primitive. This allows using Rust enum`enums in FFI where C`s in FFI where C
enum`enums are also used, for most use cases. The attribute can also be applied to`s are also used, for most use cases. The attribute can also be applied
to struct`struct`s to get the same layout as a C struct would.
A language that requires a GC is a language that opts into a larger, more complex runtime than Rust cares for. Rust is usable on bare metal with no extra runtime. Additionally, garbage collection is frequently a source of non-deterministic behavior. Rust provides the tools to make using a GC possible and even pleasant, but it should not be a requirement for implementing the language.
Sync`Sync` static mut`static mut` is unsafeTypes which are Sync`Sync` are thread-safe when multiple shared
references to them are used concurrently. Types which are not Sync`Sync` are not
thread-safe, and thus when used in a global require unsafe code to use.
Sync`Sync` are safe, why is taking &mut SHARABLE unsafe?Having multiple aliasing &mut T`&mut T`s is never allowed. Due to the nature of
globals, the borrow checker cannot possibly ensure that a static obeys the
borrowing rules, so taking a mutable reference to a static is always unsafe.
Globals can not have a non-constant-expression constructor and cannot have a destructor at all. This is an opinion of the language. Static constructors are undesirable because they can slow down program startup. Life before main is often considered a misfeature, never to be used. Rust helps this along by just not having the feature.
See the C++ FQA about the "static initialization order fiasco", and Eric Lippert's blog for the challenges in C#, which also has this feature.
A nice replacement is the lazy constructor macro by Marvin Löbel.
See the above entry on GC. Requiring a runtime limits the utility of the language, and makes it undeserving of the title "systems language". All Rust code should need to run is a stack.
match`match` must be exhaustivematch`matchbeing exhaustive has some useful properties. First, if every possibility is covered by the` being exhaustive has some useful properties. First, if every
possibility is covered by the match`match, adding further variants to the`, adding further variants to the enum`enumin the future will prompt a compilation failure, rather than runtime panic. Second, it makes cost explicit. In general, the only safe way to have a non-exhaustive match would be to panic the thread if nothing is matched, though it could fall through if the type of the`
in the future will prompt a compilation failure, rather than runtime panic.
Second, it makes cost explicit. In general, the only safe way to have a
non-exhaustive match would be to panic the thread if nothing is matched, though
it could fall through if the type of the match`matchexpression is` expression is ()`(). This sort of hidden cost and special casing is against the language's philosophy. It's easy to ignore certain cases by using the`. This sort
of hidden cost and special casing is against the language's philosophy. It's
easy to ignore certain cases by using the _`_` wildcard:
match val.do_something() { Cat(a) => { /* ... */ } _ => { /* ... */ } }
#3101 is the issue that proposed making this the only behavior, with rationale and discussion.
In general, tail-call optimization is not guaranteed: see here for a detailed explanation with references. There is a proposed extension that would allow tail-call elimination in certain contexts. The compiler is still free to optimize tail-calls when it pleases, however.
Functions can serve the same purpose as constructors without adding any language complexity.
Types which implement Copy`Copy`, will do a standard C-like "shallow copy"
with no extra work (similar to "plain old data" in C++). It is impossible to
implement Copy`Copytypes that require custom copy behavior. Instead, in Rust "copy constructors" are created by implementing the [` types that require custom copy behavior. Instead, in Rust
"copy constructors" are created by implementing the Clone`Clone` trait,
and explicitly calling the clone`clone` method. Making user-defined copy operators
explicit surfaces the underlying complexity, forcing the developer to opt-in
to potentially expensive operations.
Values of all types are moved via memcpy`memcpy`. This makes writing generic unsafe
code much simpler since assignment, passing and returning are known to never
have a side effect like unwinding.
This is to make the language easier to parse for machines. Since the body of a macro can contain arbitrary tokens, some restriction is needed to allow simple non-macro-expanding lexers and parsers. This comes in the form of requiring that all delimiters be balanced.
->`->` for function return typeThis is to make the language easier to parse for humans, especially in the face
of higher-order functions. fn foo<T>(f: fn(int): int, fn(T): U): U`fn foo
let`let` used to introduce variables?Instead of the term "variable", we use "variable bindings". The
simplest way for creating a binding is by using the let`letsyntax. Other ways include` syntax.
Other ways include if let`if let,`, while let`while let, and`, and match`match`. Bindings also
exist in function argument positions.
Bindings always happen in pattern matching positions, and it's also Rust's way
to declare mutability. One can also re-declare mutability of a binding in
pattern matching. This is useful to avoid unnecessary mut`mutannotations. An interesting historical note is that Rust comes, syntactically, most closely from ML, which also uses` annotations. An
interesting historical note is that Rust comes, syntactically, most closely
from ML, which also uses let`let` to introduce bindings.
See also a long thread on renaming let mut`let mutto` to var`var`.
--x`--xor` or x++`x++`?Preincrement and postincrement, while convenient, are also fairly complex. They
require knowledge of evaluation order, and often lead to subtle bugs and
undefined behavior in C and C++. x = x + 1`x = x + 1or` or x += 1`x += 1` is only slightly
longer, but unambiguous.