Introduction

On Monday, we were discussing the Rust language.
Before that we were taking about memory allocation and scoping in programming languages.
We said one reason Rust is interesting is that it takes a different approach to heap allocation than C (malloc/free), C++ (new/delete), Objective-C (retain/release), Java (garbage collection).
We are going to explore this more today.
We have already seen that Rust introduces a new scope with each let expression, already a somewhat novel scoping feature.
So far we've introduced the basic Rust lexicon, discussed how by default variables are immutable, but can be declared mutable.
We've looked at the primitive types in Rust (i8,i16,..., u8,u16,... float32, float64, str, char, bool, !), we've looked at expressions in Rust, and at control structures (if, match, loop, while, for) in Rust. Finally, we've discussed how to declare functions in Rust.
Today, we begin by looking at strings and compound types in Rust, and use this to segue in to how Rust handles memory management of mutable objects.

More on str

The str primitive type we introduced last day supports a variety of methods:

fn main() {
    let s = "hello world";
    println!("{}", s.len()); // 11
    let s2 = "";
    println!("{}", s.is_empty()); // false
    println!("{}", s2.is_empty()); // true
    //other useful boolean methods: starts_with, ends_with, contains
    //similar to contains, find(some_string) can be used to find position
    let s2 = "!!!";
    //faking concatenation
    let s3 = format!("{}{}", s, s2); //hello world!!!
    println!("{}", s3);
    let s4 = "  yoyoyo  ";
    println!("{}", s4.trim());//yoyoyo (no spaces)
    //also has trim_left, trim_right, strip_prefix(some_string),
        // strip_suffix(some_string)
    //a u8 bytes string slices can be extracted
        // from a string using get(lo..hi)
    let s = s.replace("hello", "howdy");
    println!("{}", s); //howdy world
    // also has repeat, to_lowercase, to_uppercase
    let v = s.split("w");
    // also has lines() to split based on end of lines
    for elt in v { //notice Rust support for in loops
        print!("{} ", elt); //ho dy orld
    }
    let i:u8 = "17".parse().unwrap();
    //alternatively, let i = "17".parse::<u8>();.unwrap();
       // ::<some_type> called a turbo fish
    let i = i + 1;
    println!("{}", i);//18
}

Compound Types: Arrays and Tuples

Arrays in Rust can be declared with a syntax like:

let /* mut */ some_var : [some_type; some_size] = ... ;
   //[initial members] or [initial_value; some_size]

For example,

let arr:[i32; 5] = [0,1,2,3,4];
let mut arr2:[u8; 100] = [0; 100]; //100 u8's all with initial value 0
let b = [[1, 0, 1], [0, 1, 0]]; //type inference +2D array

Setting/getting values of an array is like in C/C++/Java:

println!("arr[3] = {} b[1][1]={}", arr[3], b[1][1]);
arr2[7] = 128;
for elt in arr2 {
   println!("{}", elt);
}
println!("{:?}", arr);//[0, 1, 2, 3, 4]
//{:?} is debug output format
//{:#?} is pretty print debug output format
println!("The length of arr2 is: {}", arr2.len());

Arrays group together objects all of the same type, you can also group together objects of different types using tuples:

fn main() {
    let tup1: (i8, f64, u8) = (-25, 6.2, 1);
    let tup2 = (100, -1.2, 9); // works by type inference;
    let (a, b, c) = tup1; //one way to get elements out
    //if don't want all components, could do expressions like (_, b, _) =
    println!("{} {} {}", a, b, c);
    println!("{}", tup2.2); // 9
}

String Type

The str type is also called a string slice. The assignments we've seen so far are all immutable. In fact, an assignment like:
```
let hi = "Hi there!";
```
could be annotated with types as:
```
let hi: &'static str = "Hello, world!";
```
The 'static indicates that it is directly stored in the binary file and persists for the lifetime of the program.

To create mutable strings, we will use the String type:

let mut s = String::from("hello");
s.push_str(" world");
println!("{}", s);

We now discuss how Rust handles the memory management of mutable strings, composite objects, etc.

Ownership, Memory Allocation, etc

Rust uses the concept of ownership to determine who can access and manipulate a value and for how long.
There are three over-arching ownership rules:
1. Each value in Rust has a variable that's called its owner.
2. There can be only one owner at a time.
3. When the owner goes out of scope, the value will be dropped.

For example,

{  // s, s2 not valid
   let s = "hi there"; // s is valid from here to the end of the block
       //s2 not valid here
   let mut s2 = String::from("hello"); //s2 valid here to end of block
   //... more code where s, s2 are valid
} // s, s2 no longer valid

The String type, in order to support a mutable, growable piece of text, though, needs to allocate memory from the heap at runtime.
In the above, this memory is automatically returned to the OS when the variable owning the String goes out of scope.

Move, Copy, Clone

When we do an assignment of primitive types in Rust such as:
```
let x = 20;
let y = x;
```
Rust makes new space for the second variable `y` on the stack and copies the value 20 into this space. This is called a copy operation, and it is valid for all integer, Boolean, char types and tuples made from them.

Consider the analogous code for String's:

let s1 = String::from("hi there");
let s2 = s1;

Internally, for the first assignment, Rust creates on the stack a name whose value is a triple: (a ptr to where the string "hi there" is on the heap, a length for this string, and a capacity or amount of contiguous heap space pointed to by ptr).
A push_str that exceeds the capacity in the above triple, would cause the run time to allocate a larger block of memory, copy the old data, free the old space, and update ptr.
The second line above does two things: First, it allocates memory for a second triple on the stack for s2, then it copies the (ptr, len, and size info), so the copied ptr points at the same heap memory. Finally, it marks s1's triple on the stack as invalid.
Marking s1's triple as invalid (i.e., you won't be able to use s1 from that point on in the block), prevents the heap memory from being freed twice when s1 and s2 go out of scope.
The above operation is called a move.

If you want to have two copies of the same string (i.e., a deep copy of the string), you can use the clone operation:

let s1 = String::from("hi there");
let s2 = s1.clone(); // if had let s2 = s1; instead, next line would not work
println!("s1 = {}, s2 = {}", s1, s2);

In-Class Exercise

Make a small Rust program containing the last example. Show it compiles, run it, and capture the output.
Switch s2 = s1.clone(); to s2 = s1; and show the result doesn't compile and copy the error message.
Post your two programs and the copied output to the Oct 6 In-Class Exercise Thread.

Functions and Ownership

When a variable is passed to a function in Rust, if its value is copy-able, then its value will be copied to the new stack frame.
On the other hand, if its value is movable, then info about the value is copied into the new stack frame's variable, and the calling variable is invalidated.

I.e.,

fn main() {
   let x = 5;
   makes_copy(x);
   println!("x is {}", x); //okay since x wasn't invalidated
   let s = String::from("hi there");
   takes_ownership(s);
   println!("s is {}", s); //not okay since s was invalidated
}

On the other hand, if a function returns a variable, it can give ownership of its value to a receiving variable:

fn main() {
   let s = String::from("hi there");
   let s2 = takes_ownership_and_gives_back(s);
   println!("s2 is {}", s2); / okay as s2 get ownership back from function
}
fn takes_ownership_and_gives_back(a_string:String) -> String {
   a_string;
}

References and Borrowing

Rust has a notion of pointer called a reference. For a variable x, we write &x for a reference/pointer to x.
Just like with pointers in C, if z is a reference then *z is what it points to.
If we want to still use a variable after a function call completes, we can pass a reference rather than a value.
Passing references to a function is called borrowing and does not involve a change of ownership.
This works as when the function using the reference finishes, the value referenced won't be freed.

For example,

fn main() {
   let s = String::from("hi there");
   let len= compute_len(&s);
   println!("'{}' has length {}", s, len);
}
fn compute_len(s: &String) -> usize {
   s.len()
}

Mutable References

References are by default immutable, so we cannot change what a reference refers to:

fn main() {
   let s = String::from("hi");
   change(&s);
}
fn change(a_string: &String) {
   a_string.push_str(" there"); // will give compile error
}

You are allowed to create mutable references under one caveat, there can be at most one mutable reference to a mutable object in a scope.

So the following works...

fn main() {
   let mut s = String::from("hi");
   change(&mut s);
}
fn change(a_string: &mut String) {
   a_string.push_str(" there"); // works!
}

But the following does not...

fn main() {
   let mut s = String::from("hi");
   let r1 = &mut s;
   let r2 = &mut s; // second active mutable ref to s
}

Slices

A slice is a reference to a contiguous sequence of elements in a collection rather than the whole collection.
As it is a kind of reference, it does not have ownership of the object it refers to.
Given a string or an array x, a slice is declared with the notation: &x[start_index..end_index].
It is okay to leave off either or both of start_index and end_index.

Here are some examples:

let s = String::from("hello world");
let hello = &s[0..5]; //refers to the first five u8 bytes of s
// could have written &s[..5]; which refers to the start through 5 byte
let world = &s[6..11]; //refers to the last five u8 bytes of s
// could have written &s[6..]; which refers to position 6 to end
// &s[..] corresponds to a slice of the whole string
let a = [1,2,3,4,5];
let two_three = &a[1..2]; // [2,3]
let elts_from_pos_three_on = &a[3..]; // [4,5]

We can use slices in functions. For example, the function below returns a slice corresponding to the first word in a string:

fn first_word(s: &String) -> &str {
   let bytes = s.as_bytes();
   for (i, &item) in bytes.iter().enumerate() {
      if item == b' ' { //b' ' is a u8 literal for ASCII space
          return &s[0..i];
      }
   } 
}

Enums

Like C, Rust supports enums.

These can be declared with a syntax like:

enum MyEnumsName {
   LABEL1, 
   LABEL2,
   ...
}

Labels can be either identifiers, or identifiers(some_type). For example,

#[allow(dead_code)] //Rust attribute (like C pragma) 
    //so don't get warning below for paths don't use
    //general format is: #[attribute(some_value)]

enum MyEvent {
    JUMP,
    SQUAT,
    KEY(char),
}
fn main() {
    let _x = MyEvent::JUMP; //putting _ in front of var name 
                            //suppresses unused warning
    let y = MyEvent::KEY('a');
    let z = match y {
        MyEvent::KEY(x) => x,
        _ => ' ', //catch all case
    };
    println!("{}", z); // 'a'
}

Note we can use the use statement to bring the MyEvent values into scope:

use MyEvent::*;
fn main() {
    let _x = JUMP; //putting _ in front of var name 
                            //suppresses unused warning
    let y = KEY('a');
    let z = match y {
        KEY(x) => x,
        _ => ' ',
    };
    println!("{}", z); // 'a'
}

The Option enum versus nulls

Rust does not have a null value.
It does have a means to encode the concept of a value being present or absent using the Option<T> enum.
This enum is defined in the standard library as:
```
enum Option<T> {
    Some(T),
    None
}
```
It is also included automatically, so we don't have to bring it into scope.

An as example,

fn main() {
    let a = [Some(4), Some(6), None, Some(6)];
    for elt in a {
        match elt {
            Some(x) => println!("{}", x),
            None => println!("No Value"),
        }
    }
}

This outputs:
```
4
6
No Value
6
```

Structs

Just like C, Rust supports a notion of struct.
Unlike C, Rust structs can have methods.

The rough syntax for declaring a struct is:

// struct definition
struct struct_name {

    property_name1: data_type1,
    property_name2: data_type2,
    //...
}
// struct specific functions
impl struct_name {
    fn method_name1() {
        // method body
    }
    fn method_name2() {
        // method body
    }
    //...
}

Here is a simple example showing this, creating an instance of a struct, and using a method:

fn main() {
    // init structs
    let person_1 = Person {
        name: String::from("Bob"),
        age: 5, //notice okay to have a comma even if no more members
    };
    let person_2 = Person {
        name: String::from("Sally"),
        age: 2,
    };
    // use method
    person_1.print_name();
    person_2.print_name();
    println!("Person 2 age:{}", person_2.age);
    println!("Person 2 is_old:{}", person_2.is_old());
}
// define struct
struct Person {
    name: String,
    age: u8,
}
// Person specific methods
impl Person {
    fn print_name(&self) {
        println!("Name: {}", self.name);
    }
    fn is_old(&self) -> bool {
        self.age > 3
    }
}

More on Structs

It is totally legal to have multiple implementation blocks:

impl Person {
    fn print_name(&self) {
        println!("Name: {}", self.name);
    }
}
impl Person {
    fn is_old(&self) -> bool {
        self.age > 3
    }
}

Just like items of any type, items of a struct type can be passed to and returned from functions.
By default a variable of type some_struct is immutable unless declared mutable.
By default fields and methods are private, visible only within the current module and descendents.

To make it visible to other modules the keyword pub can be used:

pub struct MyStruct { //MyStruct would be visible outside of the module
   pub field1: field_type1, // field1 also visible, 
        //but only because both it and MyStruct are pub
   field2: field_type1, //field2 not visible ouside of module
}

Traits

Rust does not use a notion of sub-struct to allow for shared behavior across multiple struct types.
Instead, it uses traits which are a little like Java interfaces.

To define a trait we can use a syntax like:

pub trait MyTraitName {
   fn traitMethod1(&self, /* other params*/) -> return_type1;
   fn traitMethod2(&self, /* other params*/) -> return_type2;
   //... 
}

Although in the above, we are only giving method prototypes, unlike Java interfaces, it is legal to give implementations for some of these functions.
Such an implementation would be the default implementation of that method.

We can use a trait with a syntax like:

pub struct MyStruct {
   pub field1: type1,
   pub field2: type2,
   //...
}
impl MyTraitName for MyStruct {
   fn traitMethod1(&self, /* other params*/) -> return_type1 {
      //code for traitMethod1
   }
   fn traitMethod2(&self, /* other params*/) -> return_type2 {
      //code for traitMethod2
   }
   //...
}

It is legal for a struct to implement more than one trait.

Workspaces

When we use cargo to create a project, we are creating a package.
As a developer, you might be working on several such projects at the same time for a company, cargo 's largest unit of scope is a workspace, a folder with Cargo.toml and Cargo.lock files and a collection of sub-folders corresponding to packages managed in the workspace by the Cargo.toml.

A workspace's Cargo.toml might look like:

[workspace]

members = [
    "name_of_package1", #lists which subfolder of workspace are managed packages
    "name_of_package2",
    //..
]

[dependencies] //could list common dependencies across packages.

Adding a project to a workspace amounts to switching into the workspace folder in a shell, editing the Cargo.toml to add the name of the new package, and then typing in a shell:
```
cargo new name_of_package
```
From a workspace folder, the command cargo build, builds all the packages in the workspace. To build a particular package we could use the -p package_name flag. To run a particular package we can type:
```
cargo run -p package_name
```
All projects in a workspace build to the same target subfolder of the workspace.
If you want to delete the build artifacts (such as executables), you can use the commands:
```
cargo clean
```
or
```
cargo clean -p project_name
```

Package Dependencies

Given a Cargo.toml for a package, we can say it depends on a different project in a workspace, by adding to the [dependencies], a package path pair:
```
[dependencies]
my_other_package = {path = "../my_other_package"}
```
To add a dependency to a package from https://crates.io/, we could add the name of the dependency = version:
```
my_remote_package = "0.2.71"
```

To use pub items from my_other_package or my_remote_package in a file in your package, a use statement should be in your code:

use my_other_package;
use my_remote_package;

fn main()
{
   //code that uses items from my_other_package and my_remote_package
}

Packages and Crates

A package is a collection of source files together with a Cargo.toml manifest file which describes the package.

The folder layout of a package typically looks:

+ .
  - Cargo.lock (non human edited) - tracks dependency packages 
                  downloaded and installed and what versions
  - Cargo.toml (human-editable) list name of package, version,
                 external package dependencies, etc
                 cargo update can be used to update dependencies
  + src
      - main.rs // if default crate is a binary this file is the main entry point
      - lib.rs // if default crate is a library this file is the base file
      + bin
          - single_file_executable.rs //name of additional crate
          + multi_files_executable //name of additional crate
              - main.rs
              - module_in_multi_files_executable.rs
  + benches // benchmark crate
  + examples // examples code crate
  + tests // unit tests and integration test crate
  + targets // only created if project not in a workspace, contains build artefacts

Some packages might not have bin, benches, examples, tests folders.
A group of files in a package which compiles to its own binary or library is called a crate.
A package consists of at least one crate and is allowed to have 0 more binary crates and at most one library crate.
To create a new crate in a package, navigate to/create a bin subfolder of src and type:
```
cargo new my_crate_name
```

By default, cargo build/cargo run builds/runs all crates in a project. To build/run a particular crate you need to add the appropriate options (if in a workspace might need to add -p package_name below):

cargo build --lib build packages library crate
cargo build --bins name_of_crate_in_bin_folder 
cargo run --bin name_of_crate_in_bin_folder
cargo build --benches
cargo build --bench name_of_particular_bench
// run versions of above
cargo build --examples
cargo build --example name_of_particular_bench
// run version of above
cargo build --tests
cargo build --test name_of_particular_bench
// run version of above

Modules

A crate is further subdivided into one or more modules, collections of related structs, traits, unions, enums, functions, etc.
By default, each file in a Rust project is its own module.
So the contents of a file foo.rs would be a module some_module_path::foo module.

Within a file, we can also create sub-modules with syntax like:

//as this module not pub, not visible outside of enclosing module
mod submodule1 {
   //code of name_of_submodule1
   fn not_visible_function() {
      //this function is not pub so not visible outside of submodule1
   }
}
// module public so visible outside enclosing module
pub mod submodule2 {
   pub fn some_function() {
   }
   pub mod subsubmodule {
       pub fn some_function() {
         println!("Hello from subsubmodule");
       }
   }
   //rest of code of name_of_submodule2
}
//Can refer to objects in modules by giving the nesting path separated by ::
submodule2::some_function();
submodule2::subsubmodel::some_function;

Compiling Projects with Multiple Files

Suppose in my cargo project's src/main.rs file, I want to use functions from a file src/goo.rs and from a file src/sub/foo.rs.
From main.rs, items in goo.rs live in the goo module.
From main.rs, the folder sub is also a module, so main.rs should only be able to see sub's public submodules.
To tell cargo which files in a folder are public modules, we can use a mod.rs file (the default file for a subfolder).
For the current situation, we could put in mod.rs:
```
pub mod foo;
```

To make our set-up concrete, we put the following in foo.rs:

pub fn foo() {
    println!("lots of foo!!");
}

and the following in goo.rs:

pub fn gooey() {
    println!("very gooey!!");
}

To tell cargo that we want to use these files/modules in our src/main.rs file we use the mod statement:

mod goo; //make available the goo module to the contents of the current module
pub mod sub; //make available the sub as pub module 
use sub::foo::*; //the keyword 'use' and the * here
                 //allows us to write foo() for sub::foo::foo() below
fn main() {
    println!("Hello, world!");
    println!("yo");
    foo();
    goo::gooey();
}

The above code could then be built and run by using cargo run.

I/O

For the homework you need to be able to read a file in from disk to a string.

Below is an example of how to do this:

use std::env;
use std::fs;

fn main() {
    let args: Vec<_> = env::args().collect();
    if args.len() > 1 {
        let filename = &args[1];
        let contents = fs::read_to_string(filename)
            .expect("Something went wrong reading the file");
        println!("Here is the file:\n{}", contents);
    } else {
        println!("Need more arguments");
    }
}

Notice the expect() is used to output to stderr if something didn't go right.

We could write a string to a file with code like:

use std::fs;

fn main() {
    fs::write("bar.txt", "yummy chocolate bar")
        .expect("OOPS! Write didn't work");
}

We have already seen we can print to standard output with println!, we can print to standard error using eprintln!.

Below is an example of reading from the standard input:

use std::io;

fn main() {
    println!("Enter a your name:");
    let mut name = String::new();
    io::stdin().read_line(&mut name).
        expect("Couldn't read line");
    println!("Your name was: {}", name);
}

Common Collections

We've already seen some data structures like String that come with Rust.
Rust's std::collections library contains several efficient implementations of common data structures.
It has four main categories of struct's:
- Sequences: Vec, VecDeque, LinkedList - behaves like resizeable arrays
- Maps: HashMap, BTreeMap - used to store key value pairs
- Sets: HashSet, BTreeSet - behaves like a set of elements. You can add/remove an elt, and check memebership (contains).
- Misc: BinaryHeap - used for a priority queue

Below are some small examples of using a Vec and HashMap:

fn main() {
    let mut v: Vec<i32> = Vec::new();
    v.push(1);
    v.push(4);
    v.push(8);
    v.push(14);
    for elt in &v {
        //&v not v to avoid move
        print!("{} ", elt); // 1 4 8 14
    }
    let x: &i32 = &v[2];
    println!("\n{}", x); // 8
    v[1] = 6;
    println!("{}", &v[1]);
    let w = vec![7, 8, 9]; //can also create vector this way
    match w.get(2) {
        Some(num) => println!("{}", num), //9
        None => println!("Third elment does not exist"),
    }
    let mut months_days: HashMap = HashMap::new();
    months_days.insert("January".to_string(), 31);
    months_days.insert("February".to_string(), 28);
    if months_days.contains_key("February") {
        println!("Has February");
    }
    match months_days.get("March") {
        Some(days) => println!("March has: {}", days),
        None => println!("March is not in month_days"),
    }
    for (month, days) in &months_days {
        println!("Month {} has {} days", month, days);
    }
}

Vec has other methods like: keys, is_empty, remove, values, etc.
HashMap has other methods like: append, pop, is_empty, len, remove, splice, etc.
More information can be found on the Rust Std Collections Page.

Writing Tests for Rust Programs

As you write code for a project, you should be writing tests to make sure it is working the way you expect.
Two common kinds of tests are:
1. Unit Tests - test one module in isolation, can test both public and private functions.
2. Integration Tests - are external to a module's crate and test the module through its public interface to see how the module will behave with other parts of your package or with other packages.
Tests using Cargo are written for library, not binary targets.
Since any Cargo package is allowed to have a src/lib.rs, if you want to do testing and your main product is a binary produced from src/main.rs, you should move as much code as possible out of this file and into src/lib.rs and other modules files where it can be tested.
Tests in Cargo can be written as part of a Rust function's documentation, as part of a tests submodule of the current module, or from a file in the package's tests subfolder.

You can run tests using the Cargo commands:

cargo tests //-p package_name (if using a workspace)
cargo tests name_of_test_function

The next slide illustrates a project with each of the three kinds of tests.

Example Tests in a Rust Project

src/main.rs

use unit_experiment::return_one;

fn main() {
    println!("This is what return_one() returns:{}", return_one());
}

src/lib.rs

/// Returns 1, but does it well
///
/// Below is a unit test in a comment
/// ```
/// let x = unit_experiment::return_one();
/// assert_eq!(x, 1);
/// ```
pub fn return_one() -> u32 {
    return_two() / 2
}
/// Returns 2, twice as well
/// Notice this function is private
///
fn return_two() -> u32 {
    2
}
#[cfg(test)]
mod tests {
    use super::*; //to access enclosing module
    #[test]
    fn one_is_less_eq_two() {
        assert!(return_one() <= return_two());
    }
    #[test]
    fn one_not_eq_two() {
        assert_ne!(return_one(), return_two());
    }
}

tests/return_tests.rs

use unit_experiment::return_one;

#[test]
fn got_one() {
    assert_eq!(return_one(), 1);
}

Rust Style Guide

Most programming languages are quite flexible on the format of the code, names of variables, functions, etc.
That said, most languages/companies, etc. have conventions for formatting, naming, etc. to facilitate quickly understanding larger projects. I.e., if I know only constants are supposed to be defined using SCREAMING_SNAKE_CASE, and I see an identifier in SCREAMING_SNAKE_CASE, I can assume its a constant.
Here are some conventions often used with Rust:
Spacing
1. Lines should not be more than 100 characters.
2. Indentation should be 4 whitespace characters, not tabs.
3. Make sure lines ending don't have trailing whitespace (can screw up patches).
4. Use single whitespace characters around binary operators like +, *, -, =, ==, etc
```
let x = 10 + 7;
```
5. Semicolons and colons should not be preceded by whitespace. If there is more on the same line as a semicolon or colon, it should have one space afterwards. I.e.,
```
let x = 10 + 7; //good
let x = 10 + 7 ; //bad
let x: &str = "hi there"; // good
```
6. Ampersands for references should not be separated by whitespace from the reference or mut:
```
x: & str //bad
x: &str //good
x: &mut str //good
```
7. Avoid fragile alignments using whitespace:
```
pub struct Wrong {
    pub x  : i32,
    pub foo: i64 
}
pub struct Right {
    pub x: i32,
    pub foo: i64
}
```
8. Multi-line function signatures should be aligned with the ( that starts signature:
```
fn my_fun(param_1: type1, param_2: type3, //.. full line
          param_n: typen, /* another long line */)  //these might be indented more than four spaces
          -> return_type {
    //code - note four spaces for indent of code
}
```
9. Use one true brace for aligning braces:
```
fn bad()
{
    println!("This is incorrect.");
}

struct Good {
    example: i32
}

struct AlsoBad {
    example: i32 }
```
Naming
1. Structs, traits, enums names should use CamelCase.
2. Function, methods, modules, variables, field names should use snake_case.
3. Static variables and constants should use SCREAMING_SNAKE_CASE.

Yet More Rust

Outline

Introduction

More on str

Compound Types: Arrays and Tuples

String Type

Ownership, Memory Allocation, etc

Move, Copy, Clone

In-Class Exercise

Functions and Ownership

References and Borrowing

Mutable References

Slices

Enums

The Option enum versus nulls

Structs

More on Structs

Traits

Workspaces

Package Dependencies

Packages and Crates

Modules

Compiling Projects with Multiple Files

I/O

Common Collections

Writing Tests for Rust Programs

Example Tests in a Rust Project

Rust Style Guide

Spacing

Naming