Rust: A Friendly

Introduction
Tim Chevalier
Mozilla Research
June 19, 2013
http://rust-lang.org/
https://github.com/mozilla/rust/

1
Tuesday, June 25, 13

This is a revised version, June 25, 2003, that corrects a few typos and adds additional notes
where needed.

A language design
prelude

We designed Rust to bridge the performance gap

between safe and unsafe languages.

Design choices that seem complicated or

surprising on first glance are mostly choices that
fell out of that requirement.

Rusts compiler and all language tools are opensource (MIT/Apache dual license).
2

CC-BY-NC-SA image, Pamela Rentz

Tuesday, June 25, 13

this is mostly a talk about how to write code, but I couldnt resist putting in some language design content,
because to explain Rust its important to understand the problems we faced designing for a domain where
performance concerns mean you cant just do things like boxing/gcing everything

Systems Programming

Efficient code operating in resourceconstrained environments with direct control

over hardware

C and C++ are dominant; systems

programmers care about very small
performance margins

For most applications we dont care about

the last 10-15% of performance, but for
systems we do
3

CC-BY-NC-SA image, Tom Ryan

Tuesday, June 25, 13

ask for show of hands, how many people are C hackers, how many primarily in Java-ish languages
what is systems programming? (point 1)
theres a good reason why C is dominant;
I argue that the look & feel of the language necessarily follow from designing so as to bring safety to systems
programming

Well, whats wrong with

C, then?
dangling pointers

buffer overflows
array bounds errors format string errors
null pointer dereferences

double frees

memory
leaks But I couldn't resist the temptation to put in a null reference, simply
because it was so easy to implement. This has led to innumerable
errors, vulnerabilities, and system crashes, which have probably

caused a billion dollars of pain and damage in the last forty years. Tony Hoare
4

Tuesday, June 25, 13

Well-typed programs
dont go wrong

Milner, A theory of type

polymorphism in programming,
1978

Whatpointers
would it mean to go
wrong?
dangling
buffer overflows
array bounds
errors
Rusts type
system
is designed
to be
format
string errors
means:
nullsound,
pointerwhich
dereferences
double frees
memory
We can predict program behavior
leaksindependently of language
implementation

(This gives you more confidence that Rust programs will be reliable, not absolute
confidence. Compilers and runtime systems may have bugs. Unsafe code voids the warranty. Offer not valid in
Nebraska.)
5
Tuesday, June 25, 13

Rust: like C, but...

One reason why C persists is that theres a

simple relationship between the meaning of

your code and the behavior of the
underlying machine

This correspondence makes it relatively

easy to write efficient code in C

We want Rust to preserve this relationship

6

CC-BY-NC-SA image, Flickr user Cyberslayer

Tuesday, June 25, 13

Manual code review look at source code/assembly code (machine code?) side-by-side. Hard
to imagine doing that in Java/Haskell/ML..
Rust keeps the same model as C, matching C++ idioms where they matter (esp. WRT
memory allocation)

with memory safety

So what is memory safety?

One definition: programs
dereference only previously
allocated pointers that have not
been freed

7
Tuesday, June 25, 13

CC-BY-NC-SA image, Flickr user sldownard

7

...without runtime cost

In safe languages like Java, Python, and Haskell,

abstractions come with a runtime cost:

boxing everything
garbage-collecting everything
dynamic dispatch

Rust is about zero-cost abstractions

theres a cognitive cost: in Rust we have to think
more about data representation and memory
allocation. But the compiler checks our
assumptions.
CC-BY-NC-SA image, Flickr user Randy Adams
8

Tuesday, June 25, 13

say soundness but not in slide

to add: resource constraints, low overhead, zero-cost abstractions (cite ROC)
(n.b. In some languages, e.g. ML, you can lose boxing everything if you also give up
separate compilation.)

Roadmap:
writing fast and safe code in
Rust
Fun With Types
The one thing I hope you
Types Can Have Traits
remember:
Pointers and Memory THE COMPILER CAN CHECK
THAT YOUR CODE USES SYSTEMS
Bigger Examples
PROGRAMMING PATTERNS SAFELY
Testing, benchmarking...
Questions?
9
Tuesday, June 25, 13

I hope youll leave this talk wanting to learn more about Rust on your own. My goal is to
break down the intimidation factor, not so much to teach you Rust in an an hour and a half.
Hopefully the talk will give you a sense of why you would want to.
note to self: try NOT to assume C++ knowledge as a baseline

Disclaimer
Some code examples have been simplified
in trivial ways for clarity, and wont
necessarily typecheck or compile

When I post slides online Ill document

changes Ive made for presentation
purposes

10
Tuesday, June 25, 13

Changes needed to get code to compile will be in pink bold text in the notes

10

Mutability
Local variables in Rust are immutable by
default
let
let
y =
x =

x = 5;
mut y = 6;
x;
// OK
x + 1;
// Type error

11
Tuesday, June 25, 13

mutability-by-accident is a huge source of bugs

11

Statements and
expressions
Two kinds of statements in Rust:
let var = expr;
expr;
Everything is an expression; everything has a value
Things that only have side effects have the type
Equivalent to let

_ignore

= expr;

() (unit)

12
Tuesday, June 25, 13

no whitespace-sensitivity

12

Functions
fn f(x: int) -> int {
x * x
}
No semicolon

fn f(x: int) -> int {

return(x * x);
}
13
Tuesday, June 25, 13

13

Pointers
stack
let x: int = f();
let y: @int = @x;
assert!(*y == 5);
/* Doesnt typecheck */
// assert!(y == 5);

heap

14
Tuesday, June 25, 13

- Rust has type inference, so you can usually leave off the types. Im leaving them for
pedagogical purposes.
- Rust @-pointers cant be null
For most of the talk to make sense, you have to understand the difference between pointer
and pointed-to

14

Pointers and mutability

let mut x: int = 5;
increment(&mut x);
assert!(x == 6);
// ...
fn increment(r: &mut int) {
*r = *r + 1;
}

15
Tuesday, June 25, 13

15

Enumerations
Rust

enum Color
{
Red,
Green,
Blue
}

typedef enum {
Red,
Green,
Blue
} color;

16
Tuesday, June 25, 13

Relate to fast and trustworthy. Enum types let us write code that we know is exhaustive.
In C: fast because enums are a compile-time thing, they just turn into small integers at
runtime
C has two major problems here:
1. Missing cases
2. Being able to access fields of variants without checking tags

16

Matching on enumerations
Rust

fn f(c: Color) {
match c {
Red => // ...
Green => // ...
Blue => // ...
}
}

void f(color c) {
switch (c) {
case Red: { /* ... */
break;
}
case Green: { /* ... */
break;
}
case Blue: { /* ... */
break;
}
}
}

(omitted return type means () )

17
Tuesday, June 25, 13

show that C lets you add nonsense cases & (more importantly) leave out cases
mention: in Rust, no fall-through; must include a default case (_ => ())
point out again that match is an expression

17

Nonsense cases
Rust

fn f(c: Color) {
match c {
Red => // ...
Green => // ...
Type
17 error
=> // ...
}
}

void f(color c) {
switch (c) {
case Red: { /* ... */
break;
}
case Green: { /* ... */
break;
}
case Blue: { /* ... */
break;
}
case 17: { /* ... */
break;
}
}
}

18
14
Tuesday, June 25, 13

C accepts this because enums are just ints

But it probably indicates a programmer error

18

Non-exhaustive matches
Rust

fn f(c: Color) {
match c {
Red => // ...
Green => // ...

Exhaustiveness error
}
}

void f(color c) {
switch (c) {
case Red: { /* ... */
break;
}
case Green: { /* ... */
break;
}
}
}

19
14
15
Tuesday, June 25, 13

19

the C version is perfectly OK!

* what Rust gives you: checking that you have one case per variant, no missing cases and no
nonsense cases.
This is hugely important in a large code base when you change a data structure. Knowing the
compiler will flag these errors gives you great peace of mind.
Type system tells you that c is one of three possible values, instead of any int-sized value.
Constraining the set of things a given variable could be is very useful, and gives you the
ability to know youre handling all cases.

Enums can have fields

typedef struct IntOption {
bool is_some;
union {
int val;
void nothing;
}
}

enum IntOption {
None,
Some(int)
}

Rust

20
Tuesday, June 25, 13

Option => safe replacement for possibly-null pointers

Showing a specific version here, mention that in general this works on any type
this is nothing new -- Haskell/ML/etc. have had it for decades -- whats newish (but not unique) is having it in a systems language
example on R is a bit contrived since its just making C null pointers explicit. Bear with me!

20

Checking for Null

C

IntOption opt = random_value();

if (opt.is_some) {
printf(%d\n, opt.val);
}

21
Tuesday, June 25, 13

What if you left off the if? (Would dereference a null pointer.)
Rust has a way to protect you from making that mistake.

21

Destructuring in Rust
let opt: IntOption = random_value();
Only way
to access
the i field!

match opt {
None => (), // do nothing
Some(i) => io::println(fmt!(Its %d!, i))
}

22
Tuesday, June 25, 13

22

Theres literally no way to construct code that extracts out the int field without checking the
tag
and again, Rust compiler checks that we covered every case and dont have overlapping cases
summing up: enums create data, pattern matching deconstructs them, and pattern matches
get checked to make sure were using data in a way thats consistent with the invariants
imposed by its type

Pattern-matching and
vectors
Binds tail to [2, 3] in
this case

let x = [1, 2, 3];

match x {
[1, ..tail] => // ...
[_, ..tail] => // ...
[] => // ...
}

23
Tuesday, June 25, 13

one slide to both introduce vectors, and talk about slices?

vectors: constant-time-random-access, dynamically sized sequences of elements of the
same type

23

Structs

Similar to C structs

fields are laid out contiguously in memory, in the order

theyre declared

In C, allocating memory for a struct and initializing the

fields are separate

Rust guarantees that struct fields that can be named are

initialized

24
Tuesday, June 25, 13

emphasize: no uninitialized fields

Buzzwords: records; nominal types

24

Struct example
struct Element {
parent: Node,
tag_name: str,
attrs: [Attr],
}
// ...
let e: Element = mk_paragraph();
assert!(e.tag_name == p);
from Servo src/servo/dom/element.rs

25
Tuesday, June 25, 13

Change str to ~str and [Attr] to ~[Attr]. Change p to ~p

25

Closures
fn apply(i: int, f: fn(int) -> int) -> int {
f(i)
}
// ...
assert!(apply(4, |x| { x * x }) == 16);

A function of one argument x

that returns the square of x

26
Tuesday, June 25, 13

Change fn(int) to &fn(int)

(lambdas/anonymous/higher order functions) => This is a feature that enables better code
reuse.
Also flexible control structures. Rust implements it efficiently.
kind of a boring use of closures, yes. Next slide shows a more interesting one.

26

Loops
for range(0, 10) |i| {
println(fmt!(%u is an integer!, i));
}

A standard library function that applies a closure

to every number between (in this case) 0 and 10

27
Tuesday, June 25, 13

27

Add the line: use std::uint::range; at the top of the file

Rusts more-flexible loop constructs encourage more modular code, fewer tedious loopcounting errors
At the same time, all of this is implemented in the language itself, as libraries. You can write
your own looping constructs. The generated code is just as fast as C code that uses for loops.

(compiler steps)

Loops

for range(0, 10) |i| {

println(fmt!(%u is an integer!, i));
}

expand

range(0, 10, |i| {

println(fmt!(%u is an integer!, i));
})

inline
let mut j = 0;
while j < 10 {
println(fmt!(%u is an integer!, j));
j += 1;
}

28
25
Tuesday, June 25, 13

this is interesting because the code is really very different... top is a (sugared) call to a
higher-order function,
bottom is a direct loop
and theres no magic involved -- just syntactic sugar and simple inlining

28

Methods
struct Pair { first: int, second: int }
impl Pair {
fn product(self) -> int {
self.first * self.second
}
}
fn doubled_product(p: Pair) -> int {
2 * p.product()
}

Method call
29
Tuesday, June 25, 13

29

Generics
Functions can be abstracted over types, not
just over values

Data types can also have type parameters

Generics vs. polymorphism: same concept,
different terms (Ill use generics)

30
Tuesday, June 25, 13

30

Generic types: example

enum Option<T> {
Some(T),
None
}

31
Tuesday, June 25, 13

Yes, it is meant to look like templates

31

Generic functions:
example
fn safe_get<T>(opt: Option<T>, default: T) -> T {
match opt {
Some(contents) => contents,
None
=> default
}
}

32
Tuesday, June 25, 13

32

like Java generics -- types get specified at *compile* time, type parameters have no runtime
meaning
difference between this and templates: its possible to typecheck each function separately
(which means better error messages),
regardless of how its used. the step of expanding stuff out is separate. separate compilation
in cmrs words: Cross-library generics without header files!

Generic functions:
implementation Compiler

generates:

You write:

fn safe_get_int(opt:
Option_int, default: int) ->
int

let x = safe_get(Some(16), 2);

let y = safe_get(Some(true), false);
let z = safe_get(Some(c), a);

fn safe_get_bool(opt:
Option_bool, default: bool) ->
bool
fn safe_get_char(opt:
Option_char, default: char) ->
char
enum Option_int {
Some_int(int),
None_int
}
// same for bool and char

33
Tuesday, June 25, 13

33

bold orange stuff is all compiler-generated

compare to C++ templates or Java generics
compiler expands a template/makes a copy with type variables set to specific types
[anticipate question how is this better than C++ templates? -- one answer is traits (limiting
what types something can expand to)]
Separate typechecking/compilation

Interfaces
fn all_equal_to<T>(ys: [T], x: T) -> bool {
for ys.each |y| {
if y != x {
return false;
}
}
true
}

Doesnt
typecheck!

34
Tuesday, June 25, 13

The problem is that theres no general way to compare two values of an arbitrary type T for
equality
We need a way to be able to say does T implement the Eq interface?, and to be able to
assume -- in a generic function T -- that the function only makes sense on types T that
support the Eq interface

34

Types can have traits

Rust

C++

trait

interface

impl

implementation

35
Tuesday, June 25, 13

35

Trait example
trait Mem {
fn loadb(&mut self, addr: u16) -> u8;
fn storeb(&mut self, addr: u16, val: u8);
}

sprocketnes/mem.rs
36
Tuesday, June 25, 13

36

A trait defines an interface (collection of type signatures).

[Recall that] Trait functions are called methods. Methods differ from functions because they
have a self parameter thats special.
You can think of self -- here -- as having type &mut T: Mem.
This trait defines the interface for types that represent a collection of memory.
In this case, to count as a Mem, a type has to support two operations -- load and store, each
of which take or return a byte
(this is a 16-bit machine). In sprocket, several different types implement Mem: PPU, RAM,
VRAM, ...

Trait bounds
T is bounded
fn store_two_bytes<T: Mem>(addr1:
addr2:
byte1:
byte2:
a_mem:
a_mem.storeb(addr1, byte1);
a_mem.storeb(addr2, byte2);
}

u16,
u16,
u8,
u8,
&mut T) {

37
Tuesday, June 25, 13

made-up example

37

Implementation
example
//
// The NES' paltry 2KB of RAM
//
struct Ram { ram: [u8, ..0x800] }
impl Mem for Ram {
fn loadb(&mut self, addr: u16) -> u8
{ self.ram[addr & 0x7ff] }
fn storeb(&mut self, addr: u16, val: u8)
{ self.ram[addr & 0x7ff] = val }
}

sprocketnes/mem.rs
38
Tuesday, June 25, 13

the impl item is a concrete implementation of the trait Mem for the type Ram
the concrete type Ram here is a fixed-length vector of bytes, but in theory it could be any
type on which you can implement these operations

38

Static vs. dynamic

dispatch

The compiler compiles all the code weve been

talking about (so far) with static dispatch: the
function being called is known at compile time

Static dispatch is more efficient, because call

instructions always go to a known address

You can trade performance for flexibility and use

dynamic dispatch

n.b. In languages like Java, Python, Ruby (...) dynamic

dispatch is all there is. In Rust you have a choice.
39

Tuesday, June 25, 13

39

Dynamic dispatch
a list of objects that may have
different types, so long as all
types are Drawable

trait Drawable { fn draw(&self); }

fn draw_all(shapes: [@Drawable]) {
for shapes.each |shape| { shape.draw(); }
}

from the Rust tutorial,

http://static.rust-lang.org/doc/tutorial.html
40

Tuesday, June 25, 13

Change [@Drawable] to ~[@Drawable]

* another for loop...
* we need the @ sigil to show where a Drawable object is stored, and to make it clear its a
pointer
* by itself, Drawable is not a type. But @Drawable / ~Drawable / ~T are types

40

Static vs. dynamic

fn draw<T: Drawable>(shapes: &[T]) {
for shapes.each |shape|{
shape.draw();
}
}

fn draw(shapes: &[@Drawable]) {
for shapes.each |shape|
{
shape.draw();
}
}

compiler
fn draw_circles(shapes: &[Circle]) { ...
fn draw_rectangles(shapes: &[Rectangle])
{ ...

fn draw(shapes: ...) {
for shapes.each |shape| {
let vtable = shape.vtable;
call vtable.draw(shape);
}
}

(pseudocode)

41
Tuesday, June 25, 13

On the right, the generated code is doing work *at runtime* to look up the draw method for
each object.
On the left, the compiler generates a copy at *compile time* of the draw function for each
shape type that draw gets used with.
as with templates, the compiler generates a copy of every parameterized fn and ty)

41

Traits: summing up

Traits provide us with code reuse for no

runtime cost, when using static dispatch

Can use dynamic dispatch for greater

flexibility, when youre willing to pay the cost

In Rust, you can use either style depending on

context; the language doesnt impose a
preference on you

(Traits are inspired by Haskell type classes, but dont worry if you dont
know about those)
42

Tuesday, June 25, 13

Unifying static/dynamic dispatch is a new thing

emphasize code reuse = safety, because less duplication = less bugs

42

Changing gears
(questions so far?)

43
Tuesday, June 25, 13

CC-BY-NC-SA image, Flickr user Tom Magliery

43

Memory in Rust

Existing languages tend to either not support

explicit pointers (e.g. Java, Haskell) or
support them without detecting obvious
errors (e.g. C/C++). Theres another way!

Rusts performance goals dont admit

garbage-collecting everything as a solution

At the same time, want to avoid the hazards

of manual memory management
44

CC-BY-NC-SA image, Flickr user Dennis van Zuijlekom

Tuesday, June 25, 13

memory in Rust; using pointers safely.

Brian said pointerless vs. pointerful comparison is good
point 2 = fast, point 3 = safe

44

Pointers and memory

45
Tuesday, June 25, 13
Crucial point is that pointerless languages (Java, Haskell, ML, dynamic langs...) have to box everything; they lack the ability to talk about non-pointer-sized things in the language
(1, 2) in Haskell always [*] means a pointer to a heap-allocated record with two data fields
(the compiler can optimize this sometimes, but the language gives no guarantees)
makes it simpler to compile polymorphism, b/c the compiler knows the size of everything. But thats not the only way!
** cant rely on this optimization if *predictable* (consistent) performance is important

45

Boxed vs. unboxed

fn f(p: @(int, int)) { }

fn f(p: (int, int)) { }

Stack

Heap
46
Tuesday, June 25, 13

46

in some languages, you wouldnt be able to express this distinction -- compound data would
always live on the heap.
In Rust, you can choose whether it lives on the stack or in the heap.
Difference is that stack-allocated data has a natural lifetime corresponding to lexical scope
-- no need for GC/etc.
(Same caveat as in slide 8: (n.b. In some languages, e.g. ML, you can lose boxing everything
if you also give up separate compilation.))

Rust has three kinds

of pointers?

Actually, Rust has four kinds of pointers

But the secret is, C++ does too

In C++, *T can mean many different things; the

particular meaning in a given context lives in the
programmers head

In Rust, the pattern is explicit in the syntax;

therefore checkable by the compiler

47
Tuesday, June 25, 13

The difference is, Rust helps you remember which kind youre using at any given moment

47

Different Patterns
Managed pointer to T
Owned pointer to T
Borrowed pointer to T
Unsafe pointer to T

Rust

C++

@T

*T

~T

*T

&T

*T

*T

*T

The Rust compiler checks that code uses

each pointer type consistently with its
meaning.
48
Tuesday, June 25, 13

Graydon points out also, compiler can prove its safe

and yes, C++ has references/smart pointers/etc., but the treatment of these in Rust is
better-integrated,
more uniform, more easily checkable...
the C++ compiler *cant* check it since it doesnt know what type you meant!

48

Managed Pointers
fn remember(s: &mut Set, foo: @(int, int)) {

Local
Heap

// ... add to set ...

}

foo is a pointer into the local heap

The local heap is called managed because...

the caller need not manually free pointers into it; the compiler/runtime
frees it when its no longer needed, either using garbage collection or by
generating automatic reference-counting code

49
Tuesday, June 25, 13

(which one it uses is an implementation detail)

49

Owned pointers

Conceptually, there are actually several heaps:

No GC

Global Heap
Local
Heap

Local
Heap

Local
Heap

Local
Heap

GC

An allocation in the global heap has a single owner

(a block scope or parent data structure thats
responsible for freeing that allocation).

50
Tuesday, June 25, 13

Different tasks, different heaps

Could mention as an aside that the managed heap is also per-task and the exchange heap
can be used to move data between tasks
pointers can point from one heap to the other

50

Preventing copies
This says pass the
...
}
argument
by value

fn h(b: ~[int]) {
fn g(a: ~[int]) { ... }

fn f(n: uint) {
let v: ~[int] = vec::from_elem(n, 2);
h(v);
Typechecker
g(v);
}
rejects this call

51
Tuesday, June 25, 13

Before I talk about the last kind of pointer (borrowed) I want to talk about move semantics
the location of v gets zeroed out when we call h. So the call to g wouldnt be sound -- g
would
get a dangling pointer. Rusts typechecker prevents that. In addition, we dont interpret the
call as a copy
because v is a big value. Calling h transfers ownership of v to h

51

Borrowed pointers
fn f(a_big_number: uint) -> uint {
let mut big_vector = ~[];
for range(0, a_big_number) |n| {
big_vector += [n];
}
sum(big_vector)
}
fn sum(v: &[int]) -> int { ... }
The type tells us that sum
borrows v -- it cant return it as a result
52
Tuesday, June 25, 13

52

I explained that we cant just go wantonly copying big data structures. There has to be a
single pointer
to them.
Borrowed pointers let us have multiple pointers to the same data structure, as long as its
obvious who the
owner is -- the owner is responsible for freeing it/cleaning it up.
this is a bit misleading since &[]... is not just a reference to a vector...
No refcounting/etc. needed for managing v -- it gets deallocated automatically on exit from f
Typechecker checks that v is valid for the whole time sum uses it

A bad example
struct Cat { }
struct WebCam {
target: &Cat
}

Field thats a
reference to a Cat

fn make_a_cat() {
let cat = Cat::new();
let webcam = WebCam::new(&cat);
send_cat_to_moon(cat);
take_photograph(&webcam);
}

The typechecker will reject

this code

The pointer to cat inside

webcam is now dangling

fn take_photograph(webcam: &WebCam) {
webcam.target.focus();
webcam.snap();
}

53
Tuesday, June 25, 13

53

This slide omits the definition for the static methods Cat::new and WebCam::new (since I
didnt mention static methods in the talk). Also, I omitted field definitions for the Cat
struct. Finally, the reference to Cat inside WebCam actually needs lifetime variables,
which I didnt talk about.
assume Cat is not copyable...
This would crash in C++. Rust catches it at compile time. A different solution is to use GC
(which would mean cat gets kept alive) but we dont want to force everything to use it. So in
Rust,
code like this runs full speed. No GC overhead.

Borrowed pointers
(summary)

Its perfectly safe to borrow a pointer to data in a stack

frame that will outlive your own

Its also efficient: the compiler proves statically that lifetimes

nest properly, so borrowed pointers need no automatic
memory management

Rust accomplishes both of these goals without making the

programmer responsible for reasoning about pointer
lifetimes (the compiler checks your assumptions)

54
Tuesday, June 25, 13

54

Why bother?

Rust makes you think a lot about borrowed pointers and

ownership. What do you get in return?

The ability to write common patterns (interior pointers that

can be returned from functions, lexically nested chains of
borrows) and know that no dangling pointers or memory
leaks will occur at runtime

You would also have to do the same reasoning if you were

writing systems code in C++. Rust gives you to the tools to
make that reasoning explicit and to help the compiler help you
check it.

Rusts type system also helps avoid expensive copy operations

that you didnt intend to do
55

Tuesday, June 25, 13

PROBABLY SKIP NEXT BIT

55

Traits and pointers: an

extended example
privacy
annotation

doc comment

pub trait Container {

/// Return the number of elements in the
container
fn len(&self) -> uint;
/// Return true if the container contains no
elements
fn is_empty(&const self) -> bool;
}

A container, by definition, supports the len and

is_empty operations
56
Tuesday, June 25, 13

I didnt use these remaining slides in the talk. They probably wont compile.
Read at your own risk!

56

Trait inheritance
this method must be called on a
mutable reference to a T that has
the Mutable trait
pub trait Mutable: Container {
/// Clear the container, removing all values.
fn clear(&mut self);
}

A mutable container, by definition, is a

container that supports the additional clear
operation
57
Tuesday, June 25, 13

57

Concrete type:
HashMap
pub struct HashMap<K,V> {
priv k0: u64,
priv k1: u64,
priv resize_at: uint,
priv size: uint,
priv buckets: ~[Option<Bucket<K, V>>],
}
struct Bucket<K,V> {
hash: uint,
key: K,
value: V
}
}

(details arent too important, I just wanted to

show you the type that were implementing
Container on)
58
Tuesday, June 25, 13

58

Traits and pointers: an

extended example

K is any type that has the Hash

and Eq traits

impl<K:Hash + Eq,V> Container for HashMap<K, V> {

/// Return the number of elements in the map
fn len(&const self) -> uint {
self.size
}
/// Return true if the map contains no elements
fn is_empty(&const self) -> bool {
self.len() == 0
}
}

59
Tuesday, June 25, 13

pretty straightforward, just note the Hash + Eq syntax for multiple bounds
HashMap also has to implement Mutable, and then theres the whole Map trait, but no room
for that...

59

The Map trait: more with

borrowed pointers
pub trait Map<K, V>: Mutable {
/// Return true if the map contains a value for the specified key
fn contains_key(&self, key: &K) -> bool;

Change this to each

/// Visit all keys

fn each_key(&self, f: &fn(&K) -> bool) -> bool;
/// Return a reference to the value corresponding to the key
fn find<'a>(&'a self, key: &K) -> Option<&'a V>;
/// Insert a key-value pair into the map. An existing value for a
/// key is replaced by the new value. Return true if the key did
/// not already exist in the map.
fn insert(&mut self, key: K, value: V) -> bool;
/// Removes a key from the map, returning the value at the key if the key
/// was previously in the map.
fn pop(&mut self, k: &K) -> Option<V>;
}

60
Tuesday, June 25, 13

removed some methods for clarity

Notice that if you implement this trait, you *can* implement a hash map with C-style,
no-overhead pointers (you *could* use automatic GC in the implementation but it doesnt
force you to)
Graydon says font is too small

60

Borrowed pointers: an
extended example
impl<K:Hash + Eq,V> Mutable for HashMap<K, V> {
/// Clear the map, removing all key-value pairs.
fn clear(&mut self) {
for uint::range(0, self.buckets.len()) |idx| {
self.buckets[idx] = None;
}
self.size = 0;
}
}

61
Tuesday, June 25, 13

Talk about for loops and closures more (and how they compile into actual loops)

61

Borrowed pointers: an
extended example
impl<K:Hash + Eq,V> Map<K, V> for HashMap<K, V> {
/// Return true if the map contains a value for
the specified key
fn contains_key(&self, k: &K) -> bool {
match self.bucket_for_key(k) {
FoundEntry(_) => true,
TableFull | FoundHole(_) => false
}
}

62
Tuesday, June 25, 13

Talk about or-patterns. Otherwise, does this really need to be here?

62

Borrowed pointers
example
impl<K:Hash + Eq,V> Map<K, V> for HashMap<K, V> {
/// Visit all key-value pairs
fn each<'a>(&'a self,
blk: &fn(&K, &'a V) -> bool) -> bool {
for self.buckets.each |bucket| {
for bucket.each |pair| {
if !blk(&pair.key, &pair.value) {
return false;
}
}
}
return true;
}

63
Tuesday, June 25, 13

talk about for-loop protocol more

talk about early-return and return-out-of-closures
Graydon says avoid explaining the for loop protocol

63

Borrowed pointers
example
impl<K:Hash + Eq,V> Map<K, V> for HashMap<K, V> {
/// Return a reference to the value corresponding
to the key
fn find<'a>(&'a self, k: &K) -> Option<&'a V> {
match self.bucket_for_key(k) {
FoundEntry(idx) =>
Some(self.value_for_bucket(idx)),
TableFull | FoundHole(_) => None,
}
}
}

64
Tuesday, June 25, 13

This is not too different from contains_key

64

Borrowed pointer
example
impl<K:Hash + Eq,V> Map<K, V> for HashMap<K, V> {
/// Removes a key from the map, returning the value at the key if
the key
/// was previously in the map.
fn pop(&mut self, k: &K) -> Option<V> {
let hash = k.hash_keyed(self.k0, self.k1) as uint;
self.pop_internal(hash, k)
}

65
Tuesday, June 25, 13

the interesting part is that we return the value by-move... but how to get this across without
going into too many tedious details about pop_internal?

65

Miscellaneous Fun Stuff

Lightweight unit testing (heavily used in Rust
libraries):
#[test]
fn test_find() {
let mut m = HashMap::new();
assert!(m.find(&1).is_none());
m.insert(1, 2);
match m.find(&1) {
None => fail!(),
Some(v) => assert!(*v == 2)
}
}

rustc map.rs --test -o maptest generates an executable maptest plus code that runs
tests and prints out neatly-formatted results

66
Tuesday, June 25, 13

This is skippable

66

Benchmarking
#[bench]
fn bench_uint_small(b: &mut BenchHarness) {
let mut r = rng();
let mut bitv = 0 as uint;
do b.iter {
bitv |= (1 << ((r.next() as uint) % uint::bits));
}
}

rustc --bench -o bitv_bench bitv.rs generates a bitv_bench

executable that runs this benchmark fn repeatedly and averages the results

67
Tuesday, June 25, 13

this feature is still nascent

67

Macros
Weve seen a few macros already,

assert!

and

fail!

Macros allow you to extend Rusts syntax without

burdening the compiler
macro_rules! fail(
() => (
fail!("explicit failure")
);
($msg:expr) => (
standard_fail_function($msg, file!(), line!())
);

68
Tuesday, June 25, 13

This code wont compile (I elided the gory details of how Rust implements fail)
macros also allow for static checking of printf arguments
fail! and assert! were once baked into the language, and now theyre modular

68

Deriving
Some traits can be automatically derived (the
compiler writes the implementations for
you)
/// The option type
#[deriving(Clone, Eq)]
pub enum Option<T> {
None,
Some(T),
}

69
Tuesday, June 25, 13

Talk about clone?

Similar to deriving in Haskell

69

Any questions?
Thanks to:
The Rust Team: Graydon Hoare, Patrick

Walton, Brian Anderson, Niko Matsakis,

John Clements, Jack Moffitt, Dave
Herman

All of the Rust contributors: https://

github.com/mozilla/rust/blob/master/
AUTHORS.txt
70

Tuesday, June 25, 13

List URLs for Rust, Servo, any projects that I drew on

if you had fun, organize something during the unconference time

70