`enum`s are also used, for most use cases. The attribute can also be applied
to `struct`s to get the same layout as a C struct would.
-[repr]: http://doc.rust-lang.org/rust.html#miscellaneous-attributes
+[repr]: reference.html#miscellaneous-attributes
## There is no GC
references to them are used concurrently. Types which are not `Sync` are not
thread-safe, and thus when used in a global require unsafe code to use.
-[sync]: http://doc.rust-lang.org/core/kinds/trait.Sync.html
+[sync]: core/kinds/trait.Sync.html
### If mutable static items that implement `Sync` are safe, why is taking &mut SHARABLE unsafe?
`match` being exhaustive has some useful properties. First, if every
possibility is covered by the `match`, adding further variants to the `enum`
-in the future will prompt a compilation failure, rather than runtime failure.
-Second, it makes cost explicit. In general, only safe way to have a
-non-exhaustive match would be to fail the task if nothing is matched, though
+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 task if nothing is matched, though
it could fall through if the type of the `match` 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 `_` wildcard:
explicit surfaces the underlying complexity, forcing the developer to opt-in
to potentially expensive operations.
-[copy]: http://doc.rust-lang.org/core/kinds/trait.Copy.html
-[clone]: http://doc.rust-lang.org/core/clone/trait.Clone.html
+[copy]: core/kinds/trait.Copy.html
+[clone]: core/clone/trait.Clone.html
## No move constructors